Swing-based AWT peers

[Roman Kennke]

Hi there,

I have been asked on IRC about the possibility of Swing-based AWT peers.
I have started something like this some weeks ago and hope to continue
this soon. I want to outline how I think this would work and provide
some code snippets.

The idea is that we only need two native 'interfaces' to the outside
world: a working Graphics implementation and a working top-level peer
implementation (WindowPeer). All other widgets can then theoretically be
drawn by Swing. I will demonstrate this using some code from my
SwingButtonPeer. The important point is maybe that the Swing stuff is
kept mostly separated from the AWT stuff, like, the actual Swing
components are not directly added to the AWT component hierarchy, events
are not delivered directly, but over a 'bridge' etc.

So, in SwingButtonPeer constructor, I create an instance of JButton
(actually, it is an inner class of SwingButtonPeer that overrides some
stuff, I'll explain this later) and store it in a field. The painting is
triggered by ComponentPeer.handleEvent() when a PAINT or UPDATE event is
received (after Component.update() or Component.paint() has been
triggered):


        case PaintEvent.UPDATE:
        case PaintEvent.PAINT:
          Graphics g = getComponent().getGraphics();
          Rectangle clip = ((PaintEvent)e).getUpdateRect();
          g.clipRect(clip.x, clip.y, clip.width, clip.height);
          if (e.getID() == PaintEvent.UPDATE)
            getComponent().update(g);
          else
            getComponent().paint(g);

          // We paint the 'heavyweights' at last, so that they appear on
top of
          // everything else.
          peerPaint(g);

peerPaint() is a protected empty method in SwingComponentPeer.

In SwingButtonPeer.peerPaint() I then simply call paint() on the Swing
button (which triggers all the UI drawing stuff etc):

  protected void peerPaint(Graphics g)
  {
    button.paint(g);
  }


Also, in order to avoid trouble, the Swing components have to get
modified. The problem is, that our Swing component is never really
showing, and thus doesn't have a peer which could provide e.g. a
Graphics instance. I use an inner class of SwingButtonPeer called
SwingButton for that, that extends JButton and overrides some methods.
The affected methods are: getLocationOnScreen(), isShowing(),
createImage(), and getGraphics(). All of them call directly into the
peer like this: SwingButtonPeer.this.callMethod(), which basically end
up in ComponentPeer, which does the real work in this area.

Another point is, how are all the events handled? I did this similar to
painting: Everytime I receive a MouseEvent in SwingComponentPeer, I call
a (protected empty) hook method handleMouseEvent(), that is then
overidden by the SwingButtonPeer to forward it to the actual Swing
button (calling processMouseEvent, which also has to be overridden to
allow public access). Then, the usual Swing/UI stuff is triggered and
what comes out of the button is an ActionEvent, which I catch in a
separate listener and trigger another ActionEvent that goes off the AWT
button.

All the other details are straightforward, like setting/getting the
label of the button etc. This directly follows from the peer interface
somehow. This is only a very basic outline how Swing-based peers could
be implemented, I would think that in a complete implementation, loads
of new issues will come up that I haven't thought of yet. However, I
have been able to test this particular button peer against the Classpath
AWT demo:

http://kennke.org/~roman/swing-based-awt.png



I am thinking about making this (==complete Swing-based AWT peers) my
diploma thesis, this will probably start in the middle of the next year
and then I want to provide a generic and free implementation of this
stuff. (the current impl is somewhat bound to the specific AWT-peers
around it). However, this is only an idea I still don't know how all
this is going to work out.

Cheers, Roman

signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil