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
_______________________________________________ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath