Re: Patch: Moving AWT files and lightweight dispatching

["Rolf W. Rasmussen" <rolfwr at ii dot uib dot no>]

On Mon, Oct 30, 2000 at 11:25:18AM +1300, Bryce McKinlay wrote:
> "Rolf W. Rasmussen" wrote:
> 
> > This patch contains the changes suggested by Bryce: moving files away
> > from gnu/gcj/awt, and moving the lightweight dispatching mechanism
> > inside the java.awt package.
> 
> Thanks Rolf. I was intending to get on to that over the weekend, but I got
> distracted onto the collections stuff.
> 
> Do we need the "G" in "GLightweightPeer"? It might create confusion with Gtk
> etc.

No, the "G" is not necessary. I just needed something to differentiate 
it from the interface java.awt.peer.LightweightPeer. We could for 
instance call it "LightweightPeerImpl" instead.

> Why instantiate the dispatcher in Toolkit? Note that it is private, and can't
> be manipulated by toolkit subclasses. I think we should put
> LightweightDispatcher in Container.java, to emphasise that only Container
> should ever use it.

To properly track dragging of mouse, etc., we need exactly one 
dispatcher instance for each graphics device that has a mouse pointer. 
So, if the application opens windows on multiple displays (something 
that this JDK1.3 API allows using GraphicsDevice and 
GraphicsConfiguration), we need one dispatcher instance for each 
display. So the most correct thing to do is actually to store the 
dispatcher instance in the GraphicsDevice class that we haven't 
implemented yet.

We could ignore the multiple pointer issue and simply use one 
dispatcher instance for all components. The easiest way to do so would 
be to have declare a static dispatcher in Container. However the 
dispatcher field from the Sun spec is not declared static. It actually 
seems like they're creating a separate dispatcher for each container.

We could also make a separate dispatcher instance for each container, 
if we make the state data of LightweightDispatcher static. But then we 
might as well make all the methods in LightweightDispatcher static, and 
refrain from making any instance of the class at all.

> > One LightweightDispatcher instance is created for each toolkit. Since
> > getToolkit() can be costly in deep component trees, a reference to the
> > LightweightDispatcher instance is cached in the field dispatcher in
> > Container.
> 
> Oh, I see. I have to admit that I'm rather dubious about the
> multiple-toolkits-at-the-same-time idea. It seems like one of those cool
> sounding but not really so useful features to me.

I agree that multiple-toolkits-at-the-same-time might not be 
particularly useful, but windows on multiple screens/displays/graphics-devices 
definitely is. And the APIs for doing so is already in place in the 1.3 
API in form of the GraphicsDevice and GraphicsConfiguration classes.

That said, I think we can get away with using a single 
LightweightDispatcher instance. It will only be an issue if someone is 
clicking and dragging the mouse on more that one display at the same 
time.

-- 
Rolf W. Rasmussen