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

[Maurice Parker <maurice@xxxxxxxxxxxxxxxxxxxxxx>]

Andre,

On 11/25/01 12:26 PM, "Andre Weinand" <weinand@xxxxxxx> wrote:

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

Ya, I really like the info on EventTrackingRunLoopMode:  "Description
forthcoming." :-)

> 
> 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.

I also started to port the Widget hierarchy this weekend.  It sounds like
you just blew right by me.  :-)  I busy going to the school of hardknocks
for SWT programming.
 
> 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.

I have no idea what your talking about (yet).  I'll spend some time looking
at it later today.
 
> - 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.

Are you talking about the WidgetTable stuff?  I definitively want to chuck
that.  If we extend the Cocoa objects as local inner classes inside of the
SWT objects, we can always get references to the SWT objects using the Cocoa
references.  Of course the opposite is true as well.

I should have a working example by the end of the day that will, for
example, call dispose() on a Shell and all the children and decedents of the
Shell will have their dispose() called.

SWT has had to address a lot of issues with the Win32 port that aren't
problems when working with Cocoa.  I think we should try to avoid bringing
any of that code over to a Cocoa port when possible.

-Maurice