Re: [platform-swt-dev] MacOS X port status?

[Andre Weinand <weinand@xxxxxxx>]

Maurice,

Cool, NSApplication.nextEventMatchingMask does the trick
(but I couldn't find it in the Cocoa documentation).

I started to port Widget, Control, and Composite to get a deeper
understanding of the issues of a Cocoa port. Along the way I was able to add
lots of SWT classes which are OS independent (events, internal/image, 
many of the
graphics classes) and work under Cocoa without porting.

One new issue showed up:

- The use of NSView.lock/unlock. Any drawing code must be bracketed 
by invocations of these
methods to set up the clipping and other graphics state information. 
For SWT this is not a problem
if the drawing code is executed in a PaintListener callback. However, 
in SWT you can always create a GC and perform direct drawing on a SWT 
control. This code cannot be easily bracketed without an API change. 
The only solution I see is to invoke NSView.lock/unlock in the 
constructor/dispose methods of the GC class.

- Another interesting question is whether to support the 'handle 
approach' or whether to directly
reference Cocoa objects from SWT objects. The former approach would 
keep the MacOS port of SWT more in sync with the other ports, but 
would result in one additional indirection between SWT and objects 
and Cocoa objects. The latter approach would be more direct and 
somewhat more efficient but it would
deviate from the original SWT code.

What do you think?

--andre


> Andre,
>
> On 11/23/01 9:24 AM, "Andre Weinand" <weinand@xxxxxxx> wrote:
>
> >  I'll try whether I can get some of
> >  Eclipse's special uses of readAndDispatch() to work.
>
> I have posted a new version of the code at:
>
> http://www.vineyardenterprise.com/BlackMoon.tar.gz
>
> I think you'll like how readAndDispatch works now.  :-)
>
> -Maurice
>
> _______________________________________________
> platform-swt-dev mailing list
> platform-swt-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/platform-swt-dev