[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-swt-dev] MacOS X port status?
|
Maurice,
It seems, at the end of the week I no longer have to use
'Project Builder' for MacOS Java programming :-)
Wow, that would be cool...
Are you talking about the WidgetTable stuff?
Yes
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.
Sure, but we have to change lots SWT code.
I'm somewhat reluctant to throw out too much stuff that really
defines the runtime behavior of SWT. Since I am using (and loving)
SWT from its inception, I know that lots of our (that is JFace and
JDT) code relies on runtime behavior that is not defined as API or as
JavaDoc. If for example the order of events (calls to SWT Listeners)
changes in the Cocoa implementation, some things may no longer work.
Another issue is how to keep track with SWT updates, extensions,
fixes etc. If our implementation differs too much, it will become
very difficult to track changes.
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.
Yes, I have that too, but remember to get the order of how the
associated DisposeListeners are called, right too. Mine doesn't
behave correct yet.
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.
Yes, and because we had these issues, the API and the runtime
behavior is as it is, and clients are relying on it. The fact that
Cocoa makes things easier does not necessarily mean that the MacOS
port becomes easier (unless however we change SWT to more closely
resemble the API and runtime behavior of Cocoa).
--andre
