RAW files with ristretto – (GtkPixbufLoader mimetype recognition bug)

• March 5, 2012
• Stephan Arts

In the release-notes for ristretto 0.3.5 last weekend, I mentioned the following:

Most problems with ristretto are actually caused by incorrect mime-type recognition
of the operating-system, identifying raw files (like canon’s CR2 format) as TIFF files.
This will result in an error from the tiff loader, these errors are now displayed in the UI,
making it possible to identify the source of the problem.

Since I could not understand why this happened, I started investigating the problem a bit further.

So, I executed the following commands on my system:

$ mimtype IMG_6635.CR2
IMG_6635.CR2: image/x-canon-cr2
$ file IMG_6635.CR2
IMG_6635.CR2: Canon CR2 raw image data, version 2.0

In my defense, I have seen it return image/tiff in the past, but clearly that was not the case right now. Both commands returned image/x-canon-cr2 just fine.

But opening the raw-files with ristretto (with the libopenraw-gnome backend installed), still gave me TIFF image-loading errors.

So something else must be causing the problems. Apparently, the OS determines the mimetype just fine, but something inside ristretto does not. Checking the source I discovered I was using gdk_pixbuf_loader_new(), which creates a pixbufloader that automagically determines the mimetype based on the stream of data you feed it.

So, I replaced that with a call to gdk_pixbuf_loader_new_with_mime_type (mime_type, NULL) and retrieved the mimetype using GFileInfo.

The commit that fixes this problem is 8dd741057f7b935d8e7c327017d850388ba77767, you can cherry-pick it and install libopenraw-gnome to support the rendering of raw files  inside ristretto.

NOTE:
Libopenraw-gnome is still under active development and rendering-bugs can occur. – When the image looks bad, this is not a bug in ristretto, it is probably some terrible photography ;-), or maybe something is not yet fully implemented in libopenraw-gnome.
Using git-master this weekend did not result in any usable whitebalance or exposure compensation for me.

Xfce 4010 – (release-schedule and versioning)

• January 17, 2012
• Stephan Arts

Hi all,

There has been a lengthy discussion about the xfce version-number.
Is it OK to call the next version of xfce 4.10?

Some package maintainers have a problem with 4.10 being a later version then 4.8, since they see 4.10 as 4.1 with an extra decimal for precision.

Since it could cause upgrade-problems for several distributions, we should find a way to solve that problem.

Why not go for 5.0?

If the ‘.’ is a decimal-separator, a 0.2 upgrade from 4.8 would end up at Xfce 5.0. But we already discussed that . We are not going for 5.0, it would only create confusion, and people start thinking we pulled a ‘gnome-3’ on them. So that one was out pretty quick.

But, the confusion remains. Olivier Fourdan argued that we could think of it as a hexadecimal value, so 0x4.8 would be followed by 0x4.A. Though this sounds funny, and it solves our problem for a few versions (0x4.C, 0x4.E) but we’d end up with 0x5.0 eventually… resulting in the same problem.

And nobody uses the hexadecimal system for version-numbers, that is silly.

So? Now what?

It took a while before we realized, that the ‘.’ could be seen as a separator for thousands (it’s used like this in most of Europe). So you’d have Xfce 4,008 and Xfce 4,010. This not only solves our problem for the next version. At the rate of one release every 2 years we stay away from the whole 5.0 discussion for another 990 years. (Unless another reason appears to introduce a 41xx series of 50xx series of Xfce somewhere this century).

So, here’s the conclusion:
The next version of Xfce will be Xfce 4010 (four-thousand-and-ten)!

But that’s ridiculous!?

Well, it used to be. But these days anything is possible with version-numbers really, except for going backwards.

Which is precisely what we are avoiding here.

Just look at Mozilla Firefox (moving from 4 to 9 at the same pace as they went from 0.7 to 1.0) or Google chrome (what version-number are they using anyway?), or the linux-kernel, going from 2.6.0 to 2.6.39 with entire subsystems being rewritten from scratch, and then moving from 2.6.39 to 3.0 without any radical change whatsoever.

Really, moving from 4.8 to 4010 is not really that big a deal, if it serves the right purpose.

That’s nice and all, but when will we get it?

Ah, more good good news :)

We have a new schedule. (it is not published to the wiki yet though)

Essentially, the development-phase is pro-longed until the weekend after FOSDEM, giving us time to do some hacking there and get it in master the week after.

We hope you are as happy as we are with the new release schedule.

Update: There was some confusion about the date notation, updated it to get rid of the month-numbers.

Update-2 [18-01-2012 13:37 CET]: For more background information about this decision, check this link

Ristretto 0.1.x — Getting rid of anoyances…

• October 10, 2011
• Stephan Arts

Over the past few years, the top 2 complaints about ristretto have been ‘it leaks memory!‘ and ‘it crashes in this <obscure> way when I press this button‘.
And you know… these people were right. During the past 6 months, my main focus was fixing these problems. After a lot of code-simplification and refactoring, I finally managed to fix all the reported crashes and memory-leaks. (Yes, I know this took  a while…)

In my opinion, this made ristretto 0.1.0 the most stable release so far.

But there are still quite some improvements to be made by removing nuisances in the user-experience. Some of these have already been addressed in 0.1.0, including:

• Support for using arrow-keys to navigate through the images
• Additional accelerator for the ‘f’ key for switching to full-screen-mode
• Additional accelerator for the ‘q’ key for quitting ristretto
• Modify scroll-zoom so the mouse-cursor stays above the same region of the image when zooming in or out
• Re-introduce the file-properties dialog.

There are still some things that can be improved with regards to usability, I will work closely with the Xfce Design SIG to identify and improve problems with the ristretto UI. One of the things I will finally start on improving is the sorting-algorithm used for sorting the images on their filenames  (Bug #6866), so the images are sorted in a similar order as they are in Thunar.

The main focus during the 0.1.x release-cycles is getting existing functionality to work better, so expect a faster release-schedule featuring smaller changes for the coming months.

Event sounds in Xfce 4.4 / 4.6

• October 15, 2008
• Stephan Arts

The release-process took a little longer then expected, but its getting better. I’ve just send the announcement that Xfce 4.6 Beta1 is ready for download.

Some people have been reporting that they suddenly had event-sounds in their xfce. This is the result of using a distro that upgraded their gtk to 2.14 and installed libcanberra. With this release of xfce (xfce 4.6 beta1), the event-sounds XSETTINGS are managed, and as a result it is now possible to enable / disable these sounds.

It is important to mention that this feature is NOT present in 4.4. As a result you will experience in the default behaviour for gtk when the XSETTINGS are missing. You get event-sounds when you use Xfce 4.4.x with gtk 2.14 + libcanberra. To remove event-sounds you can do 1 of the following 3 things:

• Remove libcanberra
• Downgrade gtk to 2.12
• Upgrade xfce to 4.6

The first option is obviously the least intrusive one ;-)

Ristretto, a ‘lightweight’ image viewer

• March 4, 2008
• Stephan Arts

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 ;).