[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-swt-dev] MacOS X port status?
|
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
