This note’s for you

Today I discovered to my surprise, that the X peers of OpenJDK also use Swing as painting backend for its widgets (as opposed to the Motif peers that use Motif or Lesstif or whatever). Unfortunately, this doesn’t seem to be done in a very reusable way (==hardcoded in the X peers), as I did with my own Swing peers in GNU Classpath. I mean, it is really nice to have this reusable, because then, implementing a new backend for AWT is basically only implementing the top level components and graphics stack. I wonder, if these could be merged somehow, i.e. the reusability of my Swing peers with the completeness of OpenJDKs X peers. Hmmm, this would have been another nice proposal for the OpenJDK Innovators Challenge….

Yesterday I did the antialiasing, which is needed especially for TrueType font rendering to look nice. Today I fought a little with window manager hints. I found it a little surprising that there’s apparently no standard way to open undecorated windows. Most toolkits seem to rely on Motif proprietary hints. There’s the other two options to make a Window ‘override-redirect’, which creates a Window without decorations, but also one that sticks in front of all other windows, or you can use one of the logical hints in the Extended Window Manager Hints spec, in this case I declare the window as TOOLBAR, which isn’t semantically correct, but does the job, at least under GNOME’s window manager.

Anyway, all this makes Swing apps look much better now (except for icons):

And it’s even quite snappy, considering that almost everything is done in Java.

BTW, I consider to attend the X developer summit 2007, and probably do a presentation about Escher. Not sure if I can make it though.

I don’t want to quarrel about the pros and cons of each desktop. I think both are fine and we should stop whining at each other. However what I find a little disturbing is that applications typically are written for one or the other, but don’t work smooth on both. Evolution looks outlandish in KDE as does Konqueror in Gnome. That might not be a biggie for us techies, but a first time non-techie user would certainly be quite confused about the inconsistencies. So, can Java help us here and if so, then how?

(more…)

While diving into Xebece hacking I got an interesting idea for Swing. One major complaint against Swing apps is that they look very alien on most desktops. With newer JDK releases you can improve the situation a lot by using the native L&F of your platform, at least on Windows, GTK and MacOS X. The L&Fs are pretty good overall, by far not perfect but OK-ish. Except for the icons…
(more…)

Sun compiled two very interesting articles about New and updated desktop features in JDK6 (part1 and part2). Very interesting reading and quite exciting that Swing and Java2D finally receive more polish with respect to better desktop integration. I’m quite a fan of Swing (naturally), but in the past it has been annoying that Swing applications never seemed to really fit into the desktop. This is greatly improved in JDK6.

The GTK L&F needs more love though. It looks much better than in JDK5, but there are still many remaining issues. It still looks like a mix of GTK and Metal. For example the toolbars are clearly metal-ish, as is the file chooser. Tabs are something completely different, but definitely not GTK. Then there are lots of 1 pixel errors and a general feeling of slowness. I do however understand the difficulty in implementing such a L&F. GTK still does not provide any kind of API, at least not documented, to access the theme engine ‘from the outside’, e.g. from Swing. That is one of the biggest obstacles why I never got around to start such a L&F for GNU Classpath (besides the general lack of time).

On a different note, today I finished off (well sortof), the WindML BufferedImage/VolatileImage overhaul in the JamaicaVM. It now supports RGB565 and ARGB1555 images accelerated (for VolatileImage possibly even in the Video RAM when the driver supports this, grmbl) and ARGB8888 at least natively buffered, thus minimizing the overhead of getting the image on the screen. That’s pretty much as good as it can get on that platform. That makes up for a pretty nice performance improvement, as well as a much better memory handling (not speaking of the cleanup effect…). Many thanks go to Dmitri Trembovetski for patiently answering questions and cleaning up some misconceptions of mine!

On an even different note, my cat is going crazy for some days now. I wonder if she has hormone problems with the spring coming up here. Strange to see all those spring flowers bloom already in the mid of february though.

Go replace Firefox with The Real Browser! Here’s why:

• It’s cool.
• It’s fresh.
• It’s Free.
• Every kid around the block uses it.
• It supports Web 4.0 right out of the box (no I won’t tell you what that is, you gotta try it out yourself)

Here’s the obligatory screenshot:

Today I implemented frames and form-submit support for GNU Classpath’s HTML renderer package. This completes (API-wise) this package against JDK5. Of course it’s sill full of bugs and doesn’t support every HTML/CSS feature out there, and not even what is supported by the reference implementation. Ah and coincidentally this also API-completes Swing up to JDK1.3 and almost (one method to go) from JDK1.4.
OTOH, the new frame support implements yet another feature that the reference impl can’t render correctly, which is frames in a grid layout. So we’re getting into a situation where we support CSS or HTML features that the reference doesn’t and vice versa. I am really looking forward to a possible merge in half a year. Let’s see what we can improve until then

Look and decide for yourself. The one important Intarweb page how it is rendered on IE7 (left) vs GNU Classpath (right):

Thanks Dalibor for finding that and Stuart for sending me this little screenshot.

I would like to add that I am not happy with the name rkennkezilla as suggested by Mario. The HTML widget stuff pulls together the work of many GNU Classpath developers, maybe more than any other package in GNU Classpath.

And yes, this post is completely serious, no kidding folks!

I’m finally closing bug #23505 (the HTML RFE) now. The HTML implemenation in GNU Classpath is by far not complete (can it really? Even Firefox doesn’t pass the ACID2 test yet). But we have a fairly reasonable and complete HTML renderer now, which should be enough for most uses of HTML, which is some formatting on buttons, labels, etc, plus (hopefully) simple help pages and similar stuff. The biggest gaping hole is frame support, which isn’t exactly hard to implement, but which I simply haven’t done so far and which I don’t consider super important right now. Another thing is the lack support for actually submitting forms. I will address both issues (and other remaining stuff) at some point. But right now I’m focussing on completing my font work.

Update: Mario was so kind and hacked a logo for the upcoming jgecko browser (lets seed out some rumours ):

Some more significant improvement in the HTML rendering engine of GNU Classpath:

And in case some of you wonder why I’m doing this, now that the JDK will be open:

• It isn’t open right now.
• It’s a heck of fun to do this
• Classpath might actually improve here over JDK (already doing so for some CSS stuff like borders and padding)
• Did I already mention the fun thing?

And as soon as it becomes open, I think I’d even offer my improvements to the OpenJDK project.