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

[Andre Weinand <weinand@xxxxxxx>]

Mike,
Good idea.
Here are some items which I couldn't find in the documentation and 
where I had to look into the code or had to write a snippet to find 
an answer.

- a dispose listener is called on a Composite after its children have 
been disposed (and their dispose listeners have been called). This 
raises an interesting issue: addDisposeListener is introduced on 
Widget but Widget doesn't know anything about children, so the 
JavaDoc is perfectly OK. However in class Composite (where children 
are introduced) there is no need to reimplement addDisposeListener 
and hence no place to put a JavaDoc...

- if I call setSize on a Control while handling a resize request, a 
call to getSize on the same Control does not return the new value 
(I'm not sure whether this functionality must be ported).

- if layout management of a Composite is not handled by a Layout 
object but by a ControlListener.controlResized method, a call to 
Composite.layout(...) does not trigger a call to the ControlListener. 
This is in line with the SWT rule not to call Listeners as a side 
effect of calling the API. However clients must be careful not to 
call layout() if the layout is implemented in a ControlListener. I'm 
not sure whether a port should implement this behavior.

- the order of how Listeners are called is not specified, however the 
order is deterministic and clients try to install their Listeners 
before or after other Listeners are called (e.g. PaintListeners). If 
a port changes the implementation of Listeners to a hashing scheme, 
some clients might break.

- the class GC can be called from any thread. I'm not sure whether 
this must be true on all platforms.

- GC.fillPolygon doesn't specify whether polygons are drawn half-open 
(so that polygons drawn side-by-side overlap or not; this is 
important for drawing in X-Or mode).

--andre



> Andre,
>
> It would be great if we could write down the "runtime behavior that 
> is not defined as API or as JavaDoc" which you know about. That's 
> exactly the kind of thing which belongs in a "porting guide", which 
> is something that I think would be very useful.
>
> McQ.
>
>
>
> Andre Weinand <weinand@xxxxxxx>
> Sent by: platform-swt-dev-admin@xxxxxxxxxxx
>
> 11/25/2001 04:34 PM
> Please respond to platform-swt-dev
>        
>         To:        platform-swt-dev@xxxxxxxxxxx
>         cc:        
>         Subject:        Re: [platform-swt-dev] MacOS X port status?
>
>
>
> <snip>
> 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.
> <snip>