Input-Handling

[Mario Torre]

Il giorno sab, 05/03/2011 alle 19.14 +0100, Clemens Eisserer ha scritto:
> Hi Mario,
> 
> > We need to fix up things so that they work on current JDK though...
> 
> I had success getting cacio to work with openjdk head, changes
> required were using AWTAccessor instead of ComponentAccessor.
> Unfourtunatly font-support is more broken, I had to implement my own
> Font-Manager (simply took X11FontManager and messed arround) and make
> a cast conditional somewhere in the Motif-Peers.
> All in all it works quite well:
> http://linuxhippy.blogspot.com/2011/03/caciocavallo-goes-web.html

Wowowow!

This is so cool! ;)

We would love to merge those changes in if possible.

> > Anyway, for a managed window component, things are really easy,  search
> > for  SDLScreen and in particular, search for the native implementation,
> > it's very basic in the sdl peer, but it dispatches mouse events:
> > Java_net_java_openjdk_awt_peer_sdl_SDLScreen_nativeGetEvent
> 
> Thanks for the pointer - I now can pass simple events, although it
> doesn't work completly (e.g. a mouse-click only selects a JCheckBox
> but does not change its state), I guess I'll have to learn a bit more
> about AWT's event handling and when which events should be fired.

Maybe the SDL backend is really limited, I think we don't dispatch
events at all, other than a very small subset fo them (long time I wrote
this). I believe there's an X11 one that is a little more complete, this
was our first example and we showcased it at J1 two years ago.

> There's one big (huge) problem left - on the server there should me
> many apps running side-by-side without disturbing each other.
> I thought about running it under different ClassLoaders, however the
> native libraries can only be loaded once, so no luck.

> Do you think this can be solved with multiple AWT-Screens which are
> mapped to multiple PlatformScreens? How would you start, is it
> feasable at all?

Mmmm...

You could create different instances of the Screen, although we never
really did this, so I'm not sure it work out of the box (but I don't see
why it shouldn't to be honest).

Or you could use non managed windows (Screens are for quick
prototyping). I think it's not a problem to share the same library,
unless you internally share resources. Maybe SDL is not the perfect
library for this though.

> Would it be enough to extend makeScreenDevice/getNumScreens in
> SDLGraphicsEnvironment, extend the CacioEventPumps a bit and somehow
> glue that together with multiple SDLScreens or should I expect serious
> trouble?

This should not really be needed, this guy works the same as any other
AWT code, so maybe it's enough to use different AppContex (maybe we need
to make Cacio AppContex aware, but I think it's easier than hacking
complicated workarounds).


> - Clemens
> 
> PS: Thanks for all the hard work on Caciocavallo! It was amazing how
> quick that prototyp was implemented thanks to Cacio:)

Thanks!

I still think Oracle should invest in this a little, fix the bugs, and
use Cacio for the OSX version of Java.

If you have more questions ask us, it's nice to see you working on the
project! :)

I'll make sure to give you commit access (it's a little bit tricky, but
for you this shouldn't be an issue).

Cheers,
Mario
-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

IcedRobot: www.icedrobot.org
Proud GNU Classpath developer: http://www.classpath.org/
Read About us at: http://planet.classpath.org
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/