Xfce Developers’ Weblog
The little mouse told me...

From the moment I started developing ristretto, I mentioned that it was a simple lightweight image viewer. This is a statement which is bound to be disputed by some, and here is the reason why: ‘There is no such thing as a lightweight image viewer‘. And they are right, decompressing an image requires a lot of CPU-power, and a fully decompressed image requires the presence of enough RAM memory in order to do anything usefull with it at any acceptable speed. No image viewer has been able to surpass this limitation, ristretto is no exception to that rule.

So, why do I say ristretto is lightweight? — Because there is more to an image viewer then the two constants I mentioned before, a basic image viewer should:

• Navigate between images in an entire folder
• Display image thumbnails
• Run a slideshow
• Flip / Rotate images
• Read (and interpret) EXIF meta-data, for jpeg images taken by digital camera’s.
• Have well-documented comprehensible code

At this moment, a rudimentary implementation of these features have found their way inside ristretto. Rudimentary, because each component is being looked after if it needs refactoring. The goal is to improve these features until ristretto is a stable and fast image viewer using as little memory as possible (making it relatively lightweight), considering it’s purpose.

I’ve just summed up the first priority of ristretto development; to write a simple and fast image viewer, which does just that: show images.

Any additional features, like importing images from a digital camera (using libgphoto2) or printing images to paper could probably be added through a plugin interface or something. Keeping the basic application simple while allowing individual users to add features they like. If, when and how this is going to be implemented is still a question though ;).

I´m very proud to present to you my daughter:

Cute photograph

Her name is Leonie and she was born on Sunday, January 6, 21:06 CET. She is undoubtedly the most beautiful baby in the world. You´re thinking all fathers say that, but I´m sure this time it is true ;-)

Brian writes about ObjC being much nicer to work with than plain old C for GUI work. I just came across an interesting project that tries to improve the situation: Vala.

It’s a new language with C#-like syntax with a compiler that generates C code. Could be interesting. Although, generally speaking, code generators suck, you shouldn’t have to deal with the generated code at all in this case. The code is written in Vala, which is compiled to native code, but if you create a library it will have (or generate?) an API that is compatible with C.

I am going to have to try this some time (because, you know, I have lots of free time to spend on playing around with obscure programming languages, oh wait, I don’t ;-) So, has anyone else tried this?

I just came back from my CeBIT marathon (i mean my one day trip to CeBIT). The first word that comes into my mind after visiting CeBIT is “_HUGE_”. This event takes place into around 23 showrooms, each of them big enough to host an entire commercial aircraft. I have been walking all day long (including a 6km long walk just for the trip to the nearest Burger King) and i’m exhausted now.

I dropped by the GNOME and KDE booth and was a bit deceived. In comparison with the other booths, these ones were pretty small and without any attractive posters, sport car :p or whatever. But I took some pictures of the suggestion board that had some interesting notes :D.

Unfortunately, I couldn’t meet with Jens because he was working today. May be next time.

Very interesting mockup of a simplified user interface by Nigel Tao: check out the UI mockup.

It may not be directly obvious, but that sure looks like Xfce to me ;-)

Not being able to set my mind to doing anything useful, I played a little with rgba windows. For a future version of Xfce that can depend on cairo-based versions of Gtk, it should be possible to only make the panel background transparent, while keeping text and icons fully opaque.

Just changing the panel window and the base plugin classes, I got the following result:

Not too bad. All widgets that have their own X window, or that do some custome drawing are not transparent, but the others are. I had to choose a theme with white foreground text to make labels somewhat readable. That will require special attention to get right. Shadows or outlines maybe…

The biggest gripe I’ve had with emacs — alright, besides the finger-breaking key combo’s ;-) — is that it is just plain ugly. It just doesn’t fit with my beautiful gtk desktop with anti-aliased truetype fonts. Gvim got this right a long time ago.

But, no longer does this have to be true:

I already knew about the gtk interface, but I never heard of the xft support. I got the instructions from EmacsWiki:

$ cvs -z3 -d:pserver:anonymous@cvs.savannah.gnu.org:/cvsroot/emacs co -remacs-unicode-2 emacs
$ cd emacs
$ ./configure --with-gtk --enable-font-backend --with-xft
$ make bootstrap && make && sudo make install
$ emacs --enable-font-backend --font "Bitstream Vera Sans Mono-10"

In this blog entry Aaron Seigo talks about Plasma, the panel/desktop framework for KDE4. The ideas about data engines and data visualizations are really interesting.

I have been thinking about this for Xfce as well: it would be really cool if we could provide plugin writers with data sources and display widgets to easily write status monitors for the panel.

The idea I had is that the display widgets could be in-process, so it would be an internal plugin, but the data to display would be obtained and processed by an external process, through a DBUS protocol or whatever. This has the shared advantage of in-process widgets, which are a lot easier to handle (no more XEMBED, yay), and out-of-process data handling (no GUI blocking or crashing of the panel).

Of course we really should get Xfce 4.4 out before even considering the possibilities for 4.6…

Here’s a post by Ryan Lortie, who has been working on a (possible) new API for GNOME applets. The work was done as part of the Google Summer of Code and it looks very interesting.

It would be kinda cool if we could support the same API for Xfce 4.6. Most of the GNOME dependencies seem to have been dropped… or maybe, by the time we release 4.6, we simply switch to using the GNOME panel, who knows?

Or maybe I should be nice to our plugin writers and not change the panel API every major release :-)