AWT peers (Was: [PATCH] More List fixes)
Wed Dec 17 08:38:00 GMT 2003
S. Meslin-Weber wrote:
>>> Compatibility would be difficult given that there is no published
>>> 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
>>> 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
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.
More information about the Java