Re: AWT peers (Was: [PATCH] More List fixes)

[Bryce McKinlay <bryce at mckinlay dot net dot nz>]

S. Meslin-Weber wrote:

> > > Compatibility would be difficult given that there is no published 
> > > spec,
> > > also the interface is no doubt quite complex. The benefits would be
> > > questionable - it would let us run our peers on Sun's JDK for 
> > > debugging
> > > purposes, but I don't think that advantage is worth the effort that
> > > would be involved.
>
> I disagree, although undocumented by Sun, Sun's Peer interface is 
> reasonably well structured and intuitive to implement (if somewhat 
> painstaking to understand without docs). And as Dalibor just found, 
> there *is* published documentation for AWT peers, see my footnotes 
> [1.1] and [1.2].

> As GNU Classpath already implements big chunks according to this spec 
> there wouldn't be a great deal more 'effort' involved. Any effort 
> required is to keep GNU-isms segregated as much as possible outside of 
> the java* packages (yes, I know that's not feasible for java.awt.Font 
> yet).

OK, your arguments make sense. There certainly does seem to be more 
third-party peers out there than I had thought. But we still need a 
spec to write to. Note that [1.2] you mentioned doesn't look anything 
like being complete!

As someone who has implemented their own AWT peers that work with the 
Sun JRE, you seem to be in a good position to write a specification (to 
the JRE 1.4.2 level) that we can use for our clean-room implementation. 
This could perhaps be in the form of java/awt/peer/*.java files with 
Javadoc comments. Once we have a sufficiently complete spec, we would 
be in a much better position to implement it faithfully. Would you be 
interested in doing this?


Tom Tromey wrote:

> > > I disagree, although undocumented by Sun, Sun's Peer interface is
> > > reasonably well structured and intuitive to implement
>
> One problem we've run into has to do with List.  With the Gtk peers,
> and the replace operation implemented as "remove + add", we get
> flickering.  So Fernando's first solution -- entirely reasonable IMO
> -- was to add a new "replace" method to ListPeer.
>
> What would you suggest for a case like this?
>
> One idea is to somehow suppress Gtk redisplay while some java-side
> lock is held.  We're pretty reluctant to do this, though.

Well, this is basically how GUI toolkits generally work, and no extra 
lock should be needed. In the case of a "lightweight" java toolkit, 
what would happen is the updates to the internal state of the GUI are 
made but the actual drawing does not take place synchronously. Once 
control is returned to the event dispatch mechanism, any pending 
paint/refresh events are combined and the repainting takes place 
without any flicker. "heavyweight" peers may well work differently in 
the AWT, however, and currently I don't have enough knowledge of GTK to 
say whether we have sufficient control over GTK's internal refresh 
mechanism to do that.

Regards

Bryce.