MacOS X

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
104 messages Options
1234 ... 6
Reply | Threaded
Open this post in threaded view
|

MacOS X

Andre Schnoor
Hi,

there are a few things that probably every Mac user would like to see in VW, which are not yet supported. I assume some of us have already attempted to implement them, but, for whatever reason, not finished or published their approaches. If we joined our forces in a collaborative effort ("MacOS X Task Force"), this could be of great benefit for the community and bring the VW Mac platform a good step forward.

Below I attempted to list the most urgent issues required to make a Mac user accept a product implemented in VW (feel free to add to the list):

Look:

Interface: Lacking native widgets, the emulated MacOS X L&F will never be the real thing, and a Mac user will instantly recognize that. One way to cope with this is to not pretend being a Mac at all, but rather introduce a minimalistic custom look. This is what I did with the cross-platform "CGN Chimera Look", which is available from the public repository. I have not yet tested acceptance with real life (hostile) customers, but insiders found it quite ok. So, if you think the emulated Mac look doesn't work out for you, you may want to check out Chimera (which is also easy to modify or clone, as everything needed to run a full L&F is included with the package).

Feel:

Keyboard: The use of the Mac command keys (e.g. copy, cut, paste, save, open, close, new) should be fully "standard" throughout all Mac applications. This is especially mandatory when interacting with other Mac apps through the system clipboard (switching between Ctrl- and Command- is really odd). I'm sure this is not a problem, although I have not yet figured out how the keys are routed.

Native Cursors: (a tiny thing, making a huge difference) The use of non-standard cursors for standard actions makes an application feel "fragile" or even "broken". Although native cursors are supported by VM primitives, these are not yet implemented.

Menu Bar: IHMO, using local menu bars for each window is acceptable, as long as the global menu bar offers common standard items related to the current document. I digged for menu bar interfaces in the public repository and the goodies, but couldn't seem to find anything. I'm going to put some effort into this and would like to know, if there are rudimentary approaches available to start from.

Window Relationships: A child window should stay on top of its parent window. Related windows should be iconized and remapped together. It is almost impossible to create a real life product that can do without this behavior. This works fine on Windows already (if anybody is interested, I'll publish my code). I assume this should also be no problem on OSX.

Drag & Drop: Dragging documents from the Finder to a VW view should post an appropriate event.


If anyone knows of a (partial, rudimentary) solution for any of the above issues, please chime in. If there is enough interest, we could start a "MacOS X Task Force" hosted by the public repository and see how far we can get. Please prefix all package names with "OSX " to make them easier to browse.

Cheers,
Andre

Reply | Threaded
Open this post in threaded view
|

Re: MacOS X

Alexander Lazarevic'
Hi Andre,

just a short comment to support your initiative: I think that on all
platforms VW could benefit from a more pleasing GUI look, even if it is
foreign to the OS look.
Do you know how applications using Java Swing are perceived by Mac OS X
Users?

Alex

Andre Schnoor schrieb:

> Hi,
>
> there are a few things that probably every Mac user would like to see in
> VW, which are not yet supported. I assume some of us have already
> attempted to implement them, but, for whatever reason, not finished or
> published their approaches. If we joined our forces in a collaborative
> effort ("MacOS X Task Force"), this could be of great benefit for the
> community and bring the VW Mac platform a good step forward.
>
> Below I attempted to list the most urgent issues required to make a Mac
> user accept a product implemented in VW (feel free to add to the list):
>
> *Look: *
>
> _Interface:_ Lacking native widgets, the emulated MacOS X L&F will never
> be the real thing, and a Mac user will instantly recognize that. One way
> to cope with this is to not pretend being a Mac at all, but rather
> introduce a minimalistic custom look. This is what I did with the
> cross-platform "CGN Chimera Look", which is available from the public
> repository. I have not yet tested acceptance with real life (hostile)
> customers, but insiders found it quite ok. So, if you think the emulated
> Mac look doesn't work out for you, you may want to check out Chimera
> (which is also easy to modify or clone, as everything needed to run a
> full L&F is included with the package).
>
> *Feel:*
>
> _Keyboard:_ The use of the Mac command keys (e.g. copy, cut, paste,
> save, open, close, new) should be fully "standard" throughout all Mac
> applications. This is especially mandatory when interacting with other
> Mac apps through the system clipboard (switching between Ctrl- and
> Command- is really odd). I'm sure this is not a problem, although I have
> not yet figured out how the keys are routed.
>
> _Native Cursors:_ (a tiny thing, making a huge difference) The use of
> non-standard cursors for standard actions makes an application feel
> "fragile" or even "broken". Although native cursors are supported by VM
> primitives, these are not yet implemented.
>
> _Menu Bar:_ IHMO, using local menu bars for each window is acceptable,
> as long as the global menu bar offers common standard items related to
> the current document. I digged for menu bar interfaces in the public
> repository and the goodies, but couldn't seem to find anything. I'm
> going to put some effort into this and would like to know, if there are
> rudimentary approaches available to start from.
>
> _Window Relationships:_ A child window should stay on top of its parent
> window. Related windows should be iconized and remapped together. It is
> almost impossible to create a real life product that can do without this
> behavior. This works fine on Windows already (if anybody is interested,
> I'll publish my code). I assume this should also be no problem on OSX.
>
> _Drag & Drop:_ Dragging documents from the Finder to a VW view should
> post an appropriate event.
>
>
> If anyone knows of a (partial, rudimentary) solution for any of the
> above issues, please chime in. If there is enough interest, we could
> start a "MacOS X Task Force" hosted by the public repository and see how
> far we can get. Please prefix all package names with "OSX " to make them
> easier to browse.
>
> Cheers,
> Andre
>

Reply | Threaded
Open this post in threaded view
|

Re: MacOS X

Andre Schnoor
Alexander Lazarevic' wrote:
> Do you know how applications using Java Swing are perceived by Mac OS X
> Users?
Most likely they are perceived as "Java" applications, because Swing is
widely associated with Java. I have no idea however, what expectations
regarding Java apps are common among Mac users. It's probably the same
as with Java apps for Windows users.

Andre

Reply | Threaded
Open this post in threaded view
|

Re: MacOS X

Mark Pirogovsky-3
In reply to this post by Andre Schnoor
Hello All,

Andre Schnoor wrote:
> Hi,
>
<Some removed >
<
>
> Window Relationships: A child window should stay on top of its parent
> window. Related windows should be iconized and remapped together. It is
> almost impossible to create a real life product that can do without this
> behavior. This works fine on Windows already (if anybody is interested,
> I'll publish my code). I assume this should also be no problem on OSX.
>
Generally speaking there is a way to establish parent/child relationship
between different windows - it is usually done in the postBuild or
postOpen code like the following fragment:

makeSlaveWinFor: aBuilder
        aBuilder window ifNotNil:
                        [:aWin |
                        aWin application ifNil:
                                        [aWin application: self myOtherApp;
                                                beSlave]]
       

ApplicationWindow understands #beSlave, #beMaster, #bePartners.  Which
assigns various events to be sent to the related application windows.

That will address closing, minimizing, maximizing, but I am not sure if
it will keep the Child window in front of the parent.

> Drag & Drop: Dragging documents from the Finder to a VW view should post
> an appropriate event.
>

You can have drag/drop files working on Win32 OS via loading "Windows
goodies" parcel, it does connect to the Explorer via DLLCC, I would
imagine that there is something similar available for the MAC

<Removed ....>

> Cheers,
> Andre
>
HTH

--Mark

Reply | Threaded
Open this post in threaded view
|

Re: MacOS X

Andre Schnoor
Mark Pirogovsky wrote:

> Andre Schnoor wrote:
>> [...]
>> Window Relationships: A child window should stay on top of its parent
>> window. Related windows should be iconized and remapped together. It
>> is almost impossible to create a real life product that can do
>> without this behavior. This works fine on Windows already (if anybody
>> is interested, I'll publish my code). I assume this should also be no
>> problem on OSX.
>>
> Generally speaking there is a way to establish parent/child
> relationship between different windows - it is usually done in the
> postBuild or postOpen code like the following fragment:
>
> makeSlaveWinFor: aBuilder
>     aBuilder window ifNotNil:
>             [:aWin |
>             aWin application ifNil:
>                     [aWin                        application: self
> myOtherApp;
>                         beSlave]]
>    
>
> ApplicationWindow understands #beSlave, #beMaster, #bePartners.  Which
> assigns various events to be sent to the related application windows.
>
> That will address closing, minimizing, maximizing, but I am not sure
> if it will keep the Child window in front of the parent.

This works fine on Windows (and yes, children are kept on top of their
parents, which is great). It however doesn't seem to work on MacOS X
currently.


>
>> Drag & Drop: Dragging documents from the Finder to a VW view should
>> post an appropriate event.
>
> You can have drag/drop files working on Win32 OS via loading "Windows
> goodies" parcel, it does connect to the Explorer via DLLCC, I would
> imagine that there is something similar available for the MAC
>
If an event is sent to the window (and passed over by the VM), the this
should be no problem. I'll check it out.

Andre

Reply | Threaded
Open this post in threaded view
|

Re: MacOS X

Karsten Kusche
In reply to this post by Andre Schnoor
Hi,

> *Look: *
>
> _Interface:_ Lacking native widgets, the emulated MacOS X L&F will
> never be the real thing, and a Mac user will instantly recognize that.
> One way to cope with this is to not pretend being a Mac at all, but
> rather introduce a minimalistic custom look. This is what I did with
> the cross-platform "CGN Chimera Look", which is available from the
> public repository. I have not yet tested acceptance with real life
> (hostile) customers, but insiders found it quite ok. So, if you think
> the emulated Mac look doesn't work out for you, you may want to check
> out Chimera (which is also easy to modify or clone, as everything
> needed to run a full L&F is included with the package).

indeed, I think it's almost impossible to add the real mac look to
VisualWorks. Even if you use the original graphics it will not work (the
graphics can be found in the "layo" or "pxm#" resources of
/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/Resources/Extras.rsrc).
Mac OS X has too many subtle UI features that are not easy to adobt in
VisualWorks. For example take a simple dialog that asks if a document
that has changes should be closed. There's the "don't save" button, the
"cancel" button and the "save" button. As save is the default, it is a
blue  and animated. If another button is pressed, the save button is not
blue anymore. Instead the pressed button is blue but not animated. If
the mouse moves out of this button where it is pressed, this button
looses the blue color again. And last but not least, there're shortcuts
in this window: cmd-d for D_on't save, enter for save and ESC for cancel.

This is a very simple example and I'd really love to have such a
behavior in VisualWorks, too. But I think it's not very easy to
implement, if not almost impossible.

Another problem should be the different versions of OS X. 10.3 looks
different than 10.4 and 10.5 will change the look again, especially with
the resolution independence.

so i think a general "replacement look" for OS X would be the best
solution. I didn't try the Chimera look yet, but from the pictures that
I saw, it looked fine.

>
> *Feel:*
>
> _Keyboard:_ The use of the Mac command keys (e.g. copy, cut, paste,
> save, open, close, new) should be fully "standard" throughout all Mac
> applications. This is especially mandatory when interacting with other
> Mac apps through the system clipboard (switching between Ctrl- and
> Command- is really odd). I'm sure this is not a problem, although I
> have not yet figured out how the keys are routed.
I hear you. Keyboard navigation in a ParagraphEditor also feels quite
different than in a cocoa-text field.
> _Native Cursors:_ (a tiny thing, making a huge difference) The use of
> non-standard cursors for standard actions makes an application feel
> "fragile" or even "broken". Although native cursors are supported by
> VM primitives, these are not yet implemented.
I'm so looking for a way to hide the cursor, while text is entered.
Having native cursors would be extremely great too... the standard
cursor has a shadow, while the VisualWorks cursor doesn't. This may
sound a bit exaggerated, but seeing the white border around the black
cursor even if the mouse is on top of a white text-field is something I
really can get used to ;-) The cursor just feels smaller without the shadow.
>
> _Menu Bar:_ IHMO, using local menu bars for each window is acceptable,
> as long as the global menu bar offers common standard items related to
> the current document. I digged for menu bar interfaces in the public
> repository and the goodies, but couldn't seem to find anything. I'm
> going to put some effort into this and would like to know, if there
> are rudimentary approaches available to start from.
Another thing that really bugs me, but that probably won't change at
all, is the toolbar: the toolbar in the RefactoringBrowser is too
Windows-like. There's an icon for all the things that are usually done
with shortcuts or that should be done with the context menu, like
copy/paste, find, etc. Instead it should provide the functions that are
currently only available in the context menu and in the window's menu,
like "add package" or "add class"...things like this.
> _Drag & Drop:_ Dragging documents from the Finder to a VW view should
> post an appropriate event.
that would be cool.... or general support the the NSPasteboard things
like drag and drop of text
> If anyone knows of a (partial, rudimentary) solution for any of the
> above issues, please chime in. If there is enough interest, we could
> start a "MacOS X Task Force" hosted by the public repository and see
> how far we can get. Please prefix all package names with "OSX " to
> make them easier to browse.
the package 'wordSelection' should improve the keyboard navigation in
ParagraphEditors a bit, it should be on the public repository.


Kind Regards
Karsten

--
Karsten Kusche - Student - [hidden email]
Georg Heeg eK - Köthen
Handelsregister: Amtsgericht Dortmund A 12812

Reply | Threaded
Open this post in threaded view
|

Re: MacOS X

Andre Schnoor
Karsten wrote:

>
>> *Look: *
>>
>> _Interface:_ Lacking native widgets, the emulated MacOS X L&F will
>> never be the real thing, and a Mac user will instantly recognize
>> that. One way to cope with this is to not pretend being a Mac at all,
>> but rather introduce a minimalistic custom look. This is what I did
>> with the cross-platform "CGN Chimera Look", which is available from
>> the public repository. I have not yet tested acceptance with real
>> life (hostile) customers, but insiders found it quite ok. So, if you
>> think the emulated Mac look doesn't work out for you, you may want to
>> check out Chimera (which is also easy to modify or clone, as
>> everything needed to run a full L&F is included with the package).
>
> indeed, I think it's almost impossible to add the real mac look to
> VisualWorks. Even if you use the original graphics it will not work
> [...]

Well, I believe it is possible, but the question is if it's worth the
effort. The more VW looks like native Aqua, the higher the user's
expectations will rise. I consider this more dangerous than presenting a
custom look.

Mac users got used to the fact that many niche software was ported from
other platforms. As long as you are selling something special and unique
(as opposed to word processing and spreadsheets), this should be not a
serious problem, provided the overall performance does well (which is
not yet the case, unfortunately, but I have some hope this will change
with the next release).

> (the graphics can be found in the "layo" or "pxm#" resources of
> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/Resources/Extras.rsrc).

Cool. Anyway, unless VW supports alpha channels, they are of little use.

> Another thing that really bugs me, but that probably won't change at
> all, is the toolbar: the toolbar in the RefactoringBrowser is too
> Windows-like. There's an icon for all the things that are usually done
> with shortcuts or that should be done with the context menu, like
> copy/paste, find, etc. Instead it should provide the functions that
> are currently only available in the context menu and in the window's
> menu, like "add package" or "add class"...things like this.

In a deployed commercial application, you can turn off the tool bar. I
for one don't use toolbars at all.

What I am looking for is to dynamically add/remove items to the *global*
menu bar. This should be possible somehow. I could think of adding items
to the Mac bar through DLLCC/Framework and mapping their IDs to
particular internal menu items temporarily:

    Menu>>linkToGlobalMenuBar
    Menu>>updateGlobalMenuBar
    Menu>>unlinkFromGlobalMenuBar

I'm going to experiment in this direction.

Andre

Reply | Threaded
Open this post in threaded view
|

RE: MacOS X

Boris Popov, DeepCove Labs (SNN)
Not to hijack this thread or anything, but I'm about to purchase a new
MacBook and would like to check up on the latest state of the VMs with
those in the know. I haven't been following bug reports (and fix
reports) too much, but I do recall seeing a few popping up with a native
VM lately. So, which VM should I be using? X11 or the new one? Any
gotchas to look out for?

Thanks!

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

Reply | Threaded
Open this post in threaded view
|

Re: MacOS X

Karsten Kusche
In reply to this post by Andre Schnoor


Andre Schnoor wrote:

> Well, I believe it is possible, but the question is if it's worth the
> effort. The more VW looks like native Aqua, the higher the user's
> expectations will rise. I consider this more dangerous than presenting
> a custom look.
>
> Mac users got used to the fact that many niche software was ported
> from other platforms. As long as you are selling something special and
> unique (as opposed to word processing and spreadsheets), this should
> be not a serious problem, provided the overall performance does well
> (which is not yet the case, unfortunately, but I have some hope this
> will change with the next release).
exactly, like I said: a replacement UI would be much better...
especially if you consider, that the current UI is also really slow
compared to the Win98/2000 L&F that I use all the time.

> In a deployed commercial application, you can turn off the tool bar. I
> for one don't use toolbars at all.
>
> What I am looking for is to dynamically add/remove items to the
> *global* menu bar. This should be possible somehow. I could think of
> adding items to the Mac bar through DLLCC/Framework and mapping their
> IDs to particular internal menu items temporarily:
>
>    Menu>>linkToGlobalMenuBar
>    Menu>>updateGlobalMenuBar
>    Menu>>unlinkFromGlobalMenuBar
>
> I'm going to experiment in this direction.
there's the package MacOSXExtras in the parcel manager, but I think it's
only working for the native vm, not for X11.

Best Regards
Karsten

--
Karsten Kusche - Student - [hidden email]
Georg Heeg eK - Köthen
Handelsregister: Amtsgericht Dortmund A 12812

Reply | Threaded
Open this post in threaded view
|

Re: MacOS X

Mike Hales
In reply to this post by Boris Popov, DeepCove Labs (SNN)
I'm still using the X vm.  The aqua one looks much nicer (fonts and menus), but doesn't have drag and drop.  It also sometimes does wierd things when running Opentalk (rather than try to debug or even determine a simple case to reproduce I have just used X) , and also when running multiple versions of the same image (in my case headless worker processes) it is much easier to make the X version behave than the aqua.  To run multiple images you must have multiple copies of the vm and image.

On the X vm, many times the menus behave badly.  Sometimes the cursor and the selection don't line up, (usually when the menu would open trailing off screen, so it gets shifted up).  Many times I get a pop up and there is no selection, and I have to click off the menu, then open again to get it to work.

Many times I find myself just using parallels instead.  I good option is to run a parallels vm on your boot camp partition, that way you use OSX and Windows at the same time, but don't have the performance hit of the disk image.

Mike

On 5/23/07, Boris Popov <[hidden email]> wrote:
Not to hijack this thread or anything, but I'm about to purchase a new
MacBook and would like to check up on the latest state of the VMs with
those in the know. I haven't been following bug reports (and fix
reports) too much, but I do recall seeing a few popping up with a native
VM lately. So, which VM should I be using? X11 or the new one? Any
gotchas to look out for?

Thanks!

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.




--
Mike Hales
Engineering Manager
KnowledgeScape
www.kscape.com
Reply | Threaded
Open this post in threaded view
|

RE: MacOS X

Boris Popov, DeepCove Labs (SNN)
Ah, cool, thanks for the tips. I'm assuming that known issues are being
addressed as we speak, but you never know ;)

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On
Behalf
> Of Mike Hales
> Sent: Wednesday, May 23, 2007 9:27 AM
> To: Boris Popov; [hidden email]
> Subject: Re: MacOS X
>
> I'm still using the X vm.  The aqua one looks much nicer (fonts and
> menus), but doesn't have drag and drop.  It also sometimes does wierd
> things when running Opentalk (rather than try to debug or even
determine a
> simple case to reproduce I have just used X) , and also when running
> multiple versions of the same image (in my case headless worker
processes)
> it is much easier to make the X version behave than the aqua.  To run
> multiple images you must have multiple copies of the vm and image.
>
> On the X vm, many times the menus behave badly.  Sometimes the cursor
and
> the selection don't line up, (usually when the menu would open
trailing
> off screen, so it gets shifted up).  Many times I get a pop up and
there
> is no selection, and I have to click off the menu, then open again to
get
> it to work.
>
> Many times I find myself just using parallels instead.  I good option
is
> to run a parallels vm on your boot camp partition, that way you use
OSX
> and Windows at the same time, but don't have the performance hit of
the
> disk image.
>
> Mike
>
>
> On 5/23/07, Boris Popov <[hidden email]> wrote:
>
> Not to hijack this thread or anything, but I'm about to purchase
a
> new
> MacBook and would like to check up on the latest state of the
VMs
> with
> those in the know. I haven't been following bug reports (and fix
> reports) too much, but I do recall seeing a few popping up with
a
> native
> VM lately. So, which VM should I be using? X11 or the new one?
Any

> gotchas to look out for?
>
> Thanks!
>
> -Boris
>
> --
> +1.604.689.0322
> DeepCove Labs Ltd.
> 4th floor 595 Howe Street
> Vancouver, Canada V6C 2T5
> http://tinyurl.com/r7uw4
>
> [hidden email]
>
> CONFIDENTIALITY NOTICE
>
> This email is intended only for the persons named in the message
> header. Unless otherwise indicated, it contains information that
is
> private and confidential. If you have received it in error,
please

> notify the sender and delete the entire message including any
> attachments.
>
> Thank you.
>
>
>
>
>
>
> --
> Mike Hales
> Engineering Manager
> KnowledgeScape
> www.kscape.com <http://www.kscape.com>

Reply | Threaded
Open this post in threaded view
|

Re: MacOS X

Mike Hales
In reply to this post by Andre Schnoor
I'm probably going to end up working on a custom LookPolicy for Widgetry.  I am planning on using Cairo, so I will probably end up with a CairoArtist of some sort, and a bunch of Artists for the different Widgetry controls that subclass it.  Using Cairo will enable the use of alpha channels so we can use professionally created icons, translucency and nice anti-aliased drawing throughout the look.  We'll see how it goes, it will probably take a while.

I wholly agree that trying to look native and failing is much worse than having your own unique look.



Cool. Anyway, unless VW supports alpha channels, they are of little use.





--
Mike Hales
Engineering Manager
KnowledgeScape
www.kscape.com
Reply | Threaded
Open this post in threaded view
|

Re: MacOS X

Karsten Kusche
In reply to this post by Mike Hales
Hi,

> On the X vm, many times the menus behave badly.  Sometimes the cursor
> and the selection don't line up, (usually when the menu would open
> trailing off screen, so it gets shifted up).  Many times I get a pop
> up and there is no selection, and I have to click off the menu, then
> open again to get it to work.
>

yeah, I experience the same problem here with the X vm. I figured that
the windows are sometimes moved to the top left corner of the
screen...but they're not drawn there. if you open the debugger when the
  menu is shown (ctrl-y), you'll see the menu at the position where it
receives the mouse events.... it's a really strange and highy annoying
bug...i hope it's fixed soon :-)

another thing is that the x vm sometimes crashes while collecting garbage.

As for the aqua vm I noticed that the RBCodeHighlighting has some flaws
in underlining...somehow the text and its underlines are not "in sync",
iirc the underlines are about 20px shifted to the right


Kind Regards
Karsten


---

Karsten Kusche - Student - [hidden email]
Georg Heeg eK - Köthen
Handelsregister: Amtsgericht Dortmund A 12812


Reply | Threaded
Open this post in threaded view
|

Re: MacOS X

Andre Schnoor
In reply to this post by Boris Popov, DeepCove Labs (SNN)
Boris Popov wrote:
> Not to hijack this thread or anything, but I'm about to purchase a new
> MacBook and would like to check up on the latest state of the VMs with
> those in the know. I haven't been following bug reports (and fix
> reports) too much, but I do recall seeing a few popping up with a native
> VM lately. So, which VM should I be using? X11 or the new one? Any
> gotchas to look out for

I'm using the Aqua VM with Chimera L&F, because my customers would
*never* accept the additional hassle and extra load required for running
X11, let alone the non-standard behavior. Apart from that, the X11 VM
looks extremely dated and "academic" (i.e. is not perceived as a prime
time product, regardless of what the software actually does).

I have strong hopes the Aqua VM will improve performance with the next
release (actually my business depends on it)

If you want to run headless servers or apps with low user interaction
and extensive "backend" functionality, the X11 VM is probably a good choice.

Andre

Reply | Threaded
Open this post in threaded view
|

Re: MacOS X

Andre Schnoor
In reply to this post by Karsten Kusche

Karsten wrote:
> there's the package MacOSXExtras in the parcel manager, but I think
> it's only working for the native vm, not for X11.

Thank you, Karsten. I knew this one already. Unfortunately it doesn't
allow for dynamic menu bar construction/deconstruction.

Does anybody already have a DLLCC interface to the Carbon framework
handy? The need to parse all headers really scares me ;-)

Andre

Reply | Threaded
Open this post in threaded view
|

RE: MacOS X

Boris Popov, DeepCove Labs (SNN)
Take a look at Travis' "ObjectiveCRuntime" package in public repository.
Here's the comment:

"ObjectiveCRuntime is a very simple interface to the objective-c runtime
library. It was inspired by the ObcConnect package built by Heeg when
they did the first OSX port. That package aspired to be much more than I
needed, and had issues with some of its aspirations. So I harvested and
simplified this very simple interface. It probably needs to grow a
little. But it was simple enough for my immediate needs. I know it can
do this for example:

| nsWindow window |
window := UI.ApplicationWindow allInstances detect: [:each | each
controller notNil and: ['VisualWorks*' match: each label asString]].
nsWindow := window windowHandle.
ObjectiveCRuntime object: nsWindow perform: 'center'

That will place the launcher in the middle of the screen."

Hope this helps,

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

> -----Original Message-----
> From: Andre Schnoor [mailto:[hidden email]]
> Sent: Wednesday, May 23, 2007 12:32 PM
> To: Karsten
> Cc: vwnc-list
> Subject: Re: MacOS X
>
>
> Karsten wrote:
> > there's the package MacOSXExtras in the parcel manager, but I think
> > it's only working for the native vm, not for X11.
>
> Thank you, Karsten. I knew this one already. Unfortunately it doesn't
> allow for dynamic menu bar construction/deconstruction.
>
> Does anybody already have a DLLCC interface to the Carbon framework
> handy? The need to parse all headers really scares me ;-)
>
> Andre

Reply | Threaded
Open this post in threaded view
|

Re: MacOS X

Andre Schnoor

Boris Popov wrote:

> Take a look at Travis' "ObjectiveCRuntime" package in public repository.
> Here's the comment:
>
> "ObjectiveCRuntime is a very simple interface to the objective-c runtime
> library. It was inspired by the ObcConnect package built by Heeg when
> they did the first OSX port. That package aspired to be much more than I
> needed, and had issues with some of its aspirations. So I harvested and
> simplified this very simple interface. It probably needs to grow a
> little. But it was simple enough for my immediate needs. I know it can
> do this for example:
>
> | nsWindow window |
> window := UI.ApplicationWindow allInstances detect: [:each | each
> controller notNil and: ['VisualWorks*' match: each label asString]].
> nsWindow := window windowHandle.
> ObjectiveCRuntime object: nsWindow perform: 'center'
>
> That will place the launcher in the middle of the screen."
>
> Hope this helps,
>  

Wow. This even scares me more! This interface is only a hand full of
methods. How can it work? I am impressed. It usually looks much
different when interfacing to frameworks (dynamic libraries). It seems I
have too little understanding of the Objective-C interface here.

Will it be generally possible to manipulate the global menu bar through
this interface?

Andre

Reply | Threaded
Open this post in threaded view
|

RE: MacOS X

Boris Popov, DeepCove Labs (SNN)
I'd start with User Experience over at,

http://developer.apple.com/reference/Cocoa/index.html

Travis' example comes from,

http://tinyurl.com/2kxx93

Cheers,

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

> -----Original Message-----
> From: Andre Schnoor [mailto:[hidden email]]
> Sent: Wednesday, May 23, 2007 1:26 PM
> To: Boris Popov
> Cc: vwnc-list
> Subject: Re: MacOS X
>
>
> Boris Popov wrote:
> > Take a look at Travis' "ObjectiveCRuntime" package in public
repository.
> > Here's the comment:
> >
> > "ObjectiveCRuntime is a very simple interface to the objective-c
runtime
> > library. It was inspired by the ObcConnect package built by Heeg
when
> > they did the first OSX port. That package aspired to be much more
than I
> > needed, and had issues with some of its aspirations. So I harvested
and
> > simplified this very simple interface. It probably needs to grow a
> > little. But it was simple enough for my immediate needs. I know it
can

> > do this for example:
> >
> > | nsWindow window |
> > window := UI.ApplicationWindow allInstances detect: [:each | each
> > controller notNil and: ['VisualWorks*' match: each label asString]].
> > nsWindow := window windowHandle.
> > ObjectiveCRuntime object: nsWindow perform: 'center'
> >
> > That will place the launcher in the middle of the screen."
> >
> > Hope this helps,
> >
>
> Wow. This even scares me more! This interface is only a hand full of
> methods. How can it work? I am impressed. It usually looks much
> different when interfacing to frameworks (dynamic libraries). It seems
I
> have too little understanding of the Objective-C interface here.
>
> Will it be generally possible to manipulate the global menu bar
through
> this interface?
>
> Andre

Reply | Threaded
Open this post in threaded view
|

Re: MacOS X

stefano-franchi
In reply to this post by Andre Schnoor

On 24 May, 2007, at 7:04 AM, Andre Schnoor wrote:

> Boris Popov wrote:
>> Not to hijack this thread or anything, but I'm about to purchase a new
>> MacBook and would like to check up on the latest state of the VMs with
>> those in the know. I haven't been following bug reports (and fix
>> reports) too much, but I do recall seeing a few popping up with a
>> native
>> VM lately. So, which VM should I be using? X11 or the new one? Any
>> gotchas to look out for

Although it  will probably not be a problem on a new MacBook running
the latest version of MacOs, I am having a of of troubles with VW 7.5's
  Aqua VM  running on top of MacOs 10.3.9.  I reported on the problem
before, but basically, the paragraphEditor mangles up the text. Given
the ubiquity of ParagraphEditor, that basically means VW 7.5 is
unusable for me, and I had to switch to X11. I am not the only one
experiencing this problem either., but it seems limited to MacOs 10.3.


Cheers,

S.
__________________________________________________
Stefano Franchi
Department of Philosophy                  Ph:  (64)  9 373-7599 x83940
University Of Auckland Fax: (64) 9 373-8768
Private Bag 92019 [hidden email]
Auckland
New Zealand

Reply | Threaded
Open this post in threaded view
|

Re: MacOS X

Andre Schnoor
In reply to this post by Boris Popov, DeepCove Labs (SNN)
Boris Popov wrote:
> I'd start with User Experience over at,
>
> http://developer.apple.com/reference/Cocoa/index.html
>
> Travis' example comes from,
>
> http://tinyurl.com/2kxx93
>  

Thanks. I am well aware it's the Cocoa interface that uses Objective-C,
but Travis' package doesn't seem to work, which is why I wonder if it is
complete. VW complains about a library that can not be found. Looks like
the #linkedIn library name is not handled as intended.

Andre

1234 ... 6