<AWT Dev> Ideas about improved architecture of the generic Swing peers

[Roman Kennke]

Hi Andrei,

> tried this version and in contrast to previous one this looks much more 
> functional. :)
> I decided that it's only reasonable to check pure-AWT scenarios so just 
> picked a simple "Button-in-a-Frame" thing up and seem it does work.

Yeah, I implemented Buttons and Labels yesterday :-)

> Haven't looked on how it deals with events... this is an issue for some 
> near future.

MouseEvents and some other things like PaintEvent, ComponentEvent should
work, at least good enough for getting basic painting and mouse
handling, resizing, etc to work. Today I looked a little in
KeyboardEvent and FocusEvent handling, this is a little weird, because
the KeyboardFocusManager must not expose the backing Swing components as
focus owner, but yet the Swing component should 'think' it is focused.
But I already have some ideas that I try this evening.

>  I spent some time walking around the new code and found 
> this pretty much similar to a prototype which existed by this moment for 
> a - week or something. :)

Cool. So maybe it's a good idea to decide for one of the two prototypes,
either you push out your stuff in the open and we work together on that,
or we continue together on the Cacio peers. What do you think? It
doesn't seem to make sense to develop two implementations in parallel...

> You did inherited from the SunToolkit class and left Runnable aside. 
> Perhaps this could save some more lines of code.

Surely. I'm not sure yet what SunToolkit has to do with Runnable, but I
guess I'll study the code and learn :-)


> As a matter of fact I also tried some more complicated AWT test which I 
> believe covers all components and failed on TextArea peer 
> initialization.

Yeha! I only implemented Window, Frame, Canvas, Button and Label so far.
The other toplevels and Panel seem to be some more low hanging fruits.
The text components shouldn't be so bad - I already had these working to
some degree in the old Swing peers of GNU Classpath. What I'm really
scared about are the compound components like Scrollpane and Choice and
the Menu related stuff.

>  The good thing is we actually have semi-lightweight peer 
> for text components in X11 code so we probably may be kept from part of 
> this work. Just in case you haven't realized that yet. :)

Yeah, I've seen that. Very cool. Infact, my inspiration for all this is
both the XAWT peers of OpenJDK and my old work on GNU Classpath, and to
me, this new code is a merge of ideas from both.

> Thanks,
>    Andrei

Thank you!

/Roman

-- 
http://kennke.org/blog/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://mail.openjdk.java.net/pipermail/caciocavallo-dev/attachments/20080903/96d5a498/attachment.bin