Cacio and the TCK

Andrei gets things rolling.

Cacio Menus

Today I added support for menus to Cacio:

This was the last missing widget. The remaining tasks for Cacio are now:

• Finetuning (event handling, painting, etc)
• Performance (yeah yeah)
• Get TCK and see if it’s compatible
• Profit! (Ooops)

.. ah and of course go to JavaOne and have a great time 🙂

I’m happy

Today the flights and hotels have finally been booked. Man, that was an oddysee. Seems like nothing that I do is easy and straightforward. Except maybe Java2D pipelines. (If you think Java2D pipelines are NOT easy and straightforward, you should see the other things that I do.. ;-).) Thanks to everybody involved! Have been quite a lot of people. Probably half of Sun knows me by now. 😉 I will arrive in San Francisco on May, 31st, and stay in Whitcomb hotel until saturday, so if anybody wants to meet me there, just ping somehow or come to our Cacio BOF on tuesday. Man, I am so excited! This is my first trip to the US, and actually, is my first flight ever! I guess San Francisco is a nice destination for a first-US and first-flight!

In other news, Mario has implemented an SDL backend for Cacio, in more or less one day, YAY! This is so cool. The best thing is, it should work on Linux, Windows, and a couple of other targets as well. And of course, it will be included in Cacio, next to my shiny new X11 backend. Cacio FTW!

And in even other news (<- now that was pretty smart, eh??), I did a basic implementation of the CacioScrollPanePeer, something I always thought impossible. But thanks to our latest tricks, it was fairly easy instead.

Cacio vs. default AWT

Today is screenshot day. So here comes the first signs of life of Mario’s AWT demo:

Compare to how the default Linux AWT looks like:

Cacio with Nimbus screenies

Here are two more screenshots of Cacio with Nimbus. The screenshots are from a (not yet opened) AWT test that Andrei sent me, so no source code, but screenshots. (Mario is working on a much cooler and free AWT demo…) The first one is an AWT TextArea with scrollers (yay) showing the instructions:

The second one are some AWT Checkboxes, that can also act as radio buttons, and an AWT List with scroller:

Who said that AWT is ugly??

Cacio + Nimbus = Love

So today we made nice progress:

This is an AWT TextArea, shown using the (Swing) Nimbus L&F. Yay. Ok, granted, it has glitches, but I wanted to get the screenie out before going to bed. Will fix this tomorrow. Ah, and I solved my performance problems too. Actually, before solving them, there were no glitches, so: performance++, appearance–. 🙂

Twitter

I just created an account on twitter: http://twitter.com/rkennke, let’s see if it’s cool or not. Seems to be all the rage these days…

Cacio on X11

The last couple of ours I quickly hacked together a small xlib based backend for Caciocavallo. It’s only purpose is to have a real example of a working Cacio backend (so far we only had the Escher example, but I guess it’s been broken now for a long time, and it was never really easy to work with). This can be compiled and used with plain OpenJDK7.

Cacio can now actually do much more than this simple button list, but I don’t have an appropriate demo at hands, except some closed stuff that I’m not allowed to show…

Ah, and right now it’s ungodly slow, doesn’t handle any events etc. It’s just the first signs of life from this implementation.

Found the missing piece of the Cacio puzzle

The last couple of weeks, we’ve been quite stuck with Caciocavallo progress, especially with the complex components as TextArea, Choice, ScrollPane, etc. The problem was in the way the Swing components (those that back the AWT widgets) were connected into the peers. Let me explain how we used to do this.

So far, we had one specially modified Swing component for each peer. For example, the CacioButtonPeer used a subclass of JButton. In this subclass we overrode a couple of methods to make the JButton think it is actually part of some component hierarchy (remember that lightweight components cannot do anything by themselves, they need a heavyweight ancestor). For example, we needed to override getGraphics() to provide it a graphics to draw with, getParent() to make it think it has a parent etc. Those overridden method then hooked directly into the peer or the backing AWT component. getGraphics() would call getGraphics() of the peer, getParent() would return the parent of the backing AWT component, etc. As you can imagine, this can become quite aweful. In the case of button it’s still fairly easy, but for complex components it’s totally ridiculous. Stuff like ScrollPane and Choice are practically impossible to implement, or at least awefully complex. Event handling is also a pain. AWT events coming from the peer need to be forwarded somehow to the Swing component. In the case of the button it’s easy, just take the event, retarget and dispatch to the button. But for complex widgets it’s a bit more, well, complex. Since the swing component doesn’t really have a heavyweight parent, all the event handling and dispatching doesn’t quite work as usual, and events don’t get dispatched correctly down the hierarchy (complex Swing components like JComboBox actually have their own hierarchy!). And last but not least, the code is ugly, because it needs duplication all over the place. The problem boils down to the fact that the Swing components don’t have a heavyweight parent and need a lot of faking to make it think it has one.

Yesterday, after some talking with Mario and James (my still-boss) we had a light going on in our heads. What if we actually DO provide the Swing component a real heavyweight ancestor? Why not let it live inside its own Window? The idea is this: for each peer Swing component, we create a proxy Window object (a special subclass of Window, called ProxyWindow), and put in the actual Swing component as (the only) child component. Then, when creating the peer for the ProxyWindow, we don’t create the usual CacioWindowPeer, but instead a ProxyWindowPeer. This guy is then responsible for providing the ProxyWindow with things like Graphics objects and all the infrastructure it needs for serving the ProxyWindow and thus the Swing component. It does so by simply forwarding the requests to the underlying CacioComponentPeer. Event o handling is similarily easy: all events that show up in the CacioComponentPeer are now simply dispatched to the ProxyWindow, and there the usual lightweight dispatching takes place. From the point of view of the Swing component, it now lives in a real heavyweight window. No more hacks required to get anything to work, even the complex widgets now become fairly straightforward. We can use plain Swing components now, instead of custom subclasses. We don’t need to duplicate lots of code anymore (I guess I just shrinked Cacio code size by 50%).

A quick test shows that TextArea now works mostly as expected, with Scrollbars and everything. For comparison, before it took us _weeks_ (really) to get anything remotely useful with TextArea, now it took just a couple of _minutes_ (really, no kidding here!). I suppose we can show some cool stuff @JavaOne 🙂

In other news, Mario implemented multihead support in Cacio, yay! But I let him blog about this himself.

Into the Sun

I just signed the contract. Start on June, 1st. Yippie! There was a lot of magic involved in the process and I’d like to thank Andrea Simon, the nice recruiting lady who worked so hard to make this happen, Gustavo Galimberti, my future boss who called me countless times to keep me updated, Mario, Dalibor and Mark for talking and giving advice and of course everybody else who worked behind the curtains (I heard quite a lot of people were involved in this).

Hope to see you at JavaOne, our Cacio BOF is on monday, 8:30pm.