This week at Cafe Culture a geeky article from a contributing author that calls out to the Open Source geeky community to take a look at the consistency of the Linux User’s experience. As much as Linux Users love the Free Linux, the need for a “Universal File Chooser” is a big need. Mac ppl won’t understand this because you have a universal file chooser on your OS, but Linux has a different file chooser on almost every app that you use, so if you are opening a picture file into GIMP for ex. or uploading pictures to your blog with Firefox. Linux gives you a different layout view of the files on your computer for every different app that you’re using (see screenshots), instead of the smoother universal look that Mac offers it’s users–which gives the user a smoother workflow and it’s just more aesthetically pleasing. So here goes a geeky breakdown about this need that was picked up from the StraightEdge Linux blog, a great site for those interested in going (free) Linux…

User experience is important, and every OS is always striving to make it better. One thing that Linux has in its favour, in the terms of The Big Picture, is modularity. Modularity is great but sometimes we let it get out of hand, such as in the concept of File Choosers.

A “file chooser” is what I’m calling that dialogue window that appears whenever you Open or Save a file in any given application. On Linux, I can count, so far, a staggering eight or nine different file choosers that a user might encounter on any given day. Sometimes it confuses me and I’ve been using Linux for a long time. Imagine what it does to a new user’s brain.

There is the standard GTK file chooser that a user sees in GIMP and GPodder and other such applications:

file chooser in GIMP

And then there’s the fairly standard KDE file chooser that you’ll see in Krita and Kate and Kwrite and so on:

KDE file chooser that you’ll see in Krita and Kate and Kwrite

Except, of course, when it’s not so standard:

KDE exception file chooser

Similarly, there is the file chooser that comes along with the Qt toolkit without the KDE special sauce:

Qt toolkit without the KDE special sauce:

And the presumably Java-based file chooser that ships with Libre and Open Offices:

Qt toolkit without the KDE special sauce:

And then there are any number of random file choosers from other toolkits. Here is one I saw when using Fluidsynth-DSSI:

random file choosers from other toolkits

An interesting one that I saw with geeqie:

geeqie

No, wait, that’s not all. There’s an old one from XMMS:

XMMS

And one from xpdf:

xpdf

I’d just like to reïterate here that all of the above screenshots are all from one computer. That’s not me going around to different Linux distributions and taking screenshots, that’s from one install. How many of these do I actually see on a daily basis? Well, I use Scribus a lot, so that’s one, and GIMP/Firefox, various KDE apps, XMMS, Qtractor, and fluidsynth. So that’s literally six different file choosers that I get to deal with every day. On a good day, I might only see three (actually that would be a bad day because it would mean I’m apparently being less productive, but I do digress.).

The other OS I have experience with, a commercial one from California, has one file chooser. No matter what application you’re using, if you open or save a file, you have to learn one file chooser. The disadvantage to that approach is that if you hate the file chooser, you’ve got no recourse. But the advantage is that you only have to learn one file chooser, it feels more integrated and “polished”, and it’s just plain less confusing. It makes your interactions with your computer more transparent, and that’s a good thing.

But we can have both! Modularity provides the solution if we abstract the file chooser variable. We can make it such that when an application calls for a FILECHOOSER function, the user’s preferences are pinged, and the appropriate file chooser from the user’s favourite toolkit is displayed. Simple as that. At least, in theory. I imagine this would best be done via the Free Desktop specification, such that there is some universally-respected variable deciding what file chooser skin the user prefers to see on their system. I don’t know enough about the low-level stuff to know for sure how easy an application’s call to its native toolkit’s file chooser can be over-ridden, but I’m fairly certain it would be a trivial change.

And even if it’s not a trivial change, it CAN be done; it’s all free software, after all, and we as a Linux community did conquer the old issue of unified-notifications, which is another thing that myself and others had blogged about in years past.

So please, Linux community and developers, let’s find a way to abstract these file choosers away from the applications and unify our desktop experience. Because 3 file choosers is too many, and 9 is just plain offensive. So that’s the breakdown, let’s fire up the solution Open Source Community! Thanks, Peace!