The State Of The GTK+ File Selector

Anonymous BillyGoat writes "The next stable release of GTK+ (from the 2.4x series) will have a new file selector, and of recent, a lot of activity has been going on around that. One of the GNOME artmasters, Tigert, has released a mockup of the new file selector and the GTK developers are busy working towards that. Meanwhile the people from OSNews have some other ideas, while an OSNews reader has made even better mockups."

Comments

I really liked the original version better

[Anonymous Coward]

here

(first post)

Re:I really liked the original version better

[Anonymous Coward]

At least it was standard across the majority of Windows 3.1 applications, instead of 1/2 of the GNOME/KDE applications.

Re:I really liked the original version better

[ethx1]

I think it is funny how a lot of Linux programmers really depise Microsoft and its products yet we keep seen all these gui "improvements" that borrow from Windows. The mockup by tigert with the commmonly used folders on the left pane is from is from XP (maybe 2000). I am not a Bill Gates fanboy or anything, just something that I noticed.

Re:I really liked the original version better

[0x0d0a]

Really, almost the entire GUI paradigm has been copied around by all parties involved. Some of this is because it works pretty well, and some of it because people get familiar with working a particular way and don't want to change. Ever since the original Mac, the desktop user interface hasn't changed all that much.

I think this is a good thing. It'd be terribly annoying if UI ideas were patented and we had to have a bunch of half-assed environments.

Re:I really liked the original version better

[eswierk]

This is the true original version.

Re:I really liked the original version better

[haystor]

To be fair, MS is playing catch-up in a lot of areas too. Ever try following a shortcut to a directory in a dialog box? This only recently worked the way you expect it instead of just selecting the shortcut file itself. A subtle difference but one that trained me never to bury directories too deep on windows because I may have to work to get to them.

Multiple desktops anyone? I don't know who's responsible for this but it sure as hell isn't MS.

There are quite a few cool things that have come from open source, but you generally have to be the kind of person that can try *and* use options.

Being happy about a decent file selector for GTK is similar to being happy that an MS operating system can finally muster something similar to kill -9...oh wait, we're not there yet. It's still stuck in the mentality that "End Task" merely requests the task to shut itself down. The Kernel Power Toys from MS don't do the trick either.

MS is trialing in development in a lot of areas. It's just that after they finally steal something it's considered standard and nobody notices it.

Re:I really liked the original version better

[Frymaster]

Uh except that MS got it from Mac!

dare to compare this screenshot of the panther selector to the gtk+ one.

very similar - with the exception that the mac seperates devices and directories with a horizontal line. probably a good idea.

I need to ask

[Xpilot]

Why is it everyone gets the hang-ups over a freakin' FILE SELECTOR? GNOME critics will always say "GNOME is the worst DE in the universe! It sucks! Why? Because... it has...uh... a lousy...FILESELECTOR! Yeah, thay's it".

Now that the fileselector is improved, what will you bitch about now?

Re:I need to ask

[thebatlab]

Maybe people get hung up on it b/c file selection is used all the time and the old one was an eyesore. Sorry, it was. This one is much improved though it still has a 1980's feel to it.

>> Now that the fileselector is improved, what
>> will you bitch about now?

Well, since bitching about it has gotten it improved a bit, maybe people will still bitch about it and get it improved more. If nobody said anything it would have stayed as it was.

Reminds me of an old joke:

A new couple just had their first child, a baby boy, and were extremely excited to go through all the parenting ordeals. Diaper changes, late night feedings aside, these things would lead to wonderful moments like the first time he crawled. The first time he walked. The first time he spoke. The days went on and as the baby aged he went through all the usual stages of baby-hood. He crawled like no other and once he started walking it was all they could do to keep up with him. A year passed and he hadn't said a word. The parents asked the doctor and he said it was normal for some children not to begin speaking until they were 1 1/2 and possibly 2. The terrible 2's hit with not even a whimper. The doctor continued to reassure them that there was nothing wrong with their child but they grew worried. The years rolled on and still not a peep. Then on his sixth birthday he looked down at his chocolate cake and said "I don't like chocolate cake. I prefer vanilla". The parents were flabbergasted. "Why haven't you spoken before?!?!", they asked. "Everything was fine up until now", he replied.

Re:I need to ask

[be-fan]

- GTK's poor resize performance compared to Qt.
- GTK's poor expose handling compared to Qt.
- For practical purposes, lack of component technology. Bonobo is there, but almost no apps use it. Meanwhile, tons of KDE apps use KParts.
- For practical purposes, lack of a network-transparent filesystem. gnome-vfs is there, but not many apps use it, and its not supported through the standard file dialog. Meanwhile, every KDE app uses KIO.
- Nothing comparable to DCOP (until D-BUS comes out).
- Lower-level UI framework, compared to KDE's higher-level framework. GNOME's button Ok/Cancel button order is dictated by the HIG, while in KDE, its dictated by the framework, and would take a single line of code in kdelibs to change for all KDE apps.
- Lack of UI integration at the technology level. KDE apps use XML-GUI to define their layout. GUI layout can be change without touching a single line of code. KDE apps support customizable toolbars at the framework level, so all apps get it for free. The HIG is great, and GNOME's UI is very polished compared to KDE, but it would be nice if GNOME did like KDE and enforced a lot of those things in the code framework level.

Let's look at some of the upcoming GTK+ 2.4's features that Qt/KDE already has.

File selector (#29087)
------
KDE has it.

Combo widget (#50554)
------
Qt has it.

New action-based menu API (#55393)
-------
KDE has it.

Toolbar improvements (#55393)
--------
If you click on the feature request number and look at the proposed features, you'll see that Qt/KDE has a lot of these already, like customizable toolbars.

Autocompletion and history for GtkEntry (#69613)
--------
KDE already has this.

XCursor support for GDK. (#69436)
---------
Yep, this too. And they even mention Qt right in the first post of the feature-request thread, how nice!

Re:I need to ask

[0x0d0a]

As it happens, I like to GPL my code.

However, I'm not married to the GPL. There are some things that I want to be able to put in the public domain or BSD license, and some that should be LGPL. Furthermore, there are people (very prominent open source folks) who do not like using the GPL and do not use it.

TrollTech's licensing scheme does not allow that.

For a random minor library, this would not produce much of a stir. However, TrollTech is trying to maintain license control over what it tried to push as the standard widget set for Unix. To me, this is the next closest thing to trying to use libc as a lever (since this is fundamental for any standard GUI app). We already went through far too much pain with Motif to want to do it all over again. It just isn't worth hassling with.

Furthermore, TrollTech no longer produces a GPLed Windows Qt version. You want to make cross-platform software (which is free using GTK+ or Swing or whathaveyou), you need to purchase a license. Again, many folks don't care, but some do.

A lot of folks take a moralistic stance -- "look, TrollTech has a right to make money *somehow*. What do you propose they do, just give everything away?" I simply can't accept one organization being able to use such a fundamental thing as the standard widget set on a platform as a club. If that means that we can't have a corporate-provided widget set and need to use a volunteer-produced (actually, a number of companies fund GTK+ development, so this isn't entirely true), then so be it. It's been done many times on Linux, and can be done with a widget set as well.

The sad thing is that many folks that intensely dislike Qt have no problem with KDE. KDE gets a lot of crap that really derives from the choice of Qt as a widget set. However, if you use KDE, you're stuck with Qt, so there isn't much choice.

The C vs. C++ thing is also tough. I suspect a lot of people feel some sort of strange allegiance to the "traditional" Unix way, and believe C solves all problems equally well as C++ because hey, that's what Unix (and Linux, and so forth) uses. This just isn't true, of course, especially when it comes to reusability.

At one point, I would have agreed with you. However, with C++, I simply have not seen the code reuse benefits. The C++ code reuse model (and to some extent, OO in general) requires a huge amount of work, essentially doing a complete and highly detailed design before beginning any coding. If, at some point, you realize that you've made a small error and need some additional data, your changes may need to be vast and far-reaching. This was a popular design style ten years ago, but currently trendy stuff, like extreme programming involves more iteration.

Secondly, the STL is not a convincing argument with Qt, because Qt does not make any effective use of the STL, unlike, for instance, gtkmm.

Finally, while C *is* a specialized language not designed for general application development, that does not mean that C++ is particularly better. I agree that C has a number of flaws as an application language, but C++ does not fix the significant problems.

Re:I need to ask

[IamTheRealMike]

Very, very nice work. But the obvious technical merits of KDE aren't enough to convince those who feel irrational and emotional about two things: Qt's "corporate" status, and a visceral hatred for C++.

What, so the reason people don't use Qt is because they are irrational and emotional? Let me remind you that C++ users can always use GTKmm which is arguably more "C++" than Qt will ever be.

Let me explain to you why the autopackage project has a very nice GTK2 based front end, and no KDE or Qt frontend. NB: plenty of people have offered to work on one, including core KDE hackers. We never saw any code. Make of that what you will.

We chose to use GTK from C because:

- C is a simple language that both me and Hongli (the other principle author of it) knew well. I've done plenty of OO programming in Delphi and Java before but only a little C++. The greater featureset of C++, in this case simply wasn't worth the hassle of ensuring we both knew it well, and weren't churning out constructs that the other couldn't understand.

It also increased dramatically the number of people that could work on it. Surprising though it may be, not everybody (especially in the unix world) knows C++.

- C has a stable ABI. For a program that is supposed to work anywhere without recompilation this is a big deal. That won't be an issue in a few years when gcc 2.95 is but a distant memory, but at the moment it is.

- It required no bindings. You can, of course, use C++ with GTK by using the rather spiffy GTKmm which gives you STL and a C++ish API so that other than a few minor oddies you'd never know the underlying toolkit was written in C, but this is an extra dependency, the cost of which was simply not worth it.

I look at the Gnome source code and shudder. It just reminds me so much of writing GUI code for Windows 3.1 and 95 (yes, I've done that).

If you're going to compare modern GTK to Win32 then all I can say is that you either haven't actually done any GTK programming or you haven't done any Win32 programming. I've done plenty of both and I can tell you that GTK is about a million light years away from Win32. The API is sane, consistant, and the toolkit is a powerful one.

Now let me tell you what I don't get.

I see people bitching (mostly ignorantly) about GTK, Gnome, C, whatever and praising the shining pearls of light that is KDE and Qt, yet the fact is that GTK is way more popular.

No, really, it is. I have no Qt or KDE apps on my desktop at any point these days. That's not because I don't like Qt or KDE - I do - but the fact is that I don't choose apps based on what toolkit they use but on merit. I use Firebird (XUL), emacs CVS (a mixture of raw Xlib and gtk2 these days), irssi (ncurses), Pan (raw GTK) and so on.

Yet, I once read a KDE developer claim that Yes! It's true! He had spent a whole month without glib installed on his system - he wanted to prove it was possible to do it, and well done he did. But if people have to do macho time trials to prove they can do without something - isn't this a hint?

I could be cynical and say that GTK is more popular because the people using it are busy getting shit done in whatever language lets them work most effectively (c, python, c++, whatever) instead of trolling about the superiority of Qt and C++ on Slashdot, but I won't. I'll let readers make up their own minds. I use what works for me.

Looks a lot like the Mac OS X file selector

[putaro]

Only not quite as functional. The pathname entry is good, but it looks like it doesn't have the quick drill down. If you're going to copy, why not copy the good parts?

Ummmm, Who Is Eugenia?

[nuintari]

Maybe I should read into this more, but who is Eugenia, and what does sending him/her love have to do with saving my files?

Re:Ummmm, Who Is Eugenia?

[}{avoc]

The love-sending widget will not be present in the final release of the new file selector, and is included in mockups to demonstrate how developers can add in special-purpose widgets into the window. For example, The GIMP may insert a quality slider in that place for saving JPEG images.

Early mockups used the phrase " Frobnicate the file ," which was changed to " Lart whoever asks about this button " after countless questions as to the use of frobnicating files.

These screenshots are linked from Federico Mena-Quintero's Activity Log, which is really rather fun to read. You may also be interested in Planet Gnome, which aggregates the weblogs of many interesting Gnome and Open Source personalities.

Tab completion?

[Anonymous Coward]

One thing I really like about the current file selector is that I can start typing a name and press tab, and it will show only entries starting with what I typed. It even supports wildcards. Does anyone know if that will still be there? As long as I have that, I really don't care what it looks like - I'll still be able to find stuff efficiently.

It's about time!!

[MongooseCN]

It looks like sending love to Eugenia is on by default in the file selector. I always hated having to goto a bash shell after opening a file and doing an "echo love > /home/eugenia/warm_fuzzies".

shell prompt

[brer_rabbit]

I still don't see how this is going to help my shell prompt.

Re:One possible feature I'd like to see

[ultrapenguin]

Left-side shortcuts on common file open/save dialog boxes can be easily configurable by using
a) group policy editor
b) tweakui from microsoft.
(both of these assume you are running Windows2000/XP/2003)

In either cases, you have a choice of setting the shortcut to a namespace clsid (my computer, my docs, etc) or to a full pathname to anywhere you want.

For example, my file/open dialog on my windows machine has desktop,mycomputer,2 direct links to company file shares, and a path link to a temp directory on my machine.

But, of course, you couldn't be bothered to know this, since its easier to just complain.

too complex

[POds]

The problem with those mockups is that they seem specificaly tailord to GNOME. Ie it uses icons for HOME, Desktop, Most recent files etc but all of these are classic things that are integrated within gnome and no use to someone that uses blackbox or other light window managers as they're primary window manager.

Why cant we just get rid of the icons and by doing so cut down the size of the selector and simplly have a listbox of pre-defined locations to save files?

Also it would be good if that list could be changed by editing a configuration file, maybe an XML file?

KISS

Re:One possible feature I'd like to see

[ron_ivi]

Agreed. It's the features more than the look that matters to me.

I'd like:

• to be able to type "../../whatever.txt" in the "filename" textarea and have it work reasonable,
• the complete path to be a gui-widget that I can copy&paste from
• to be able to type D*31.GIF and have it work reasonably (glob like a shell)
• by extention, have "/u*/l*/b*/mozilla" typed into the text area find /usr/local/bin/mozilla if that's the only match.

Typing is so much easier than mousing sometimes, I'd really really like to have those wildcards work.

Re: Gnome is lookin' good!

[Black Parrot]

> But a buddy was showing me some of his favorite GTK themes on his Gnome desktop, and I have to admit that I was impressed. Unfortunately, when I checked to see how many packages I'd have to install for Gnome, there were over 30 -- Mozilla was one of the dependencies!

> So, can any /.ers recommend a... svelt window manager that supports some of this wonderful eye candy?

The eyecandy comes from different places. Applications that use the GTK+ widgets will render with your choice of GTK+ theme, regardles of what window manager you use. The window manager eyecandy will only effect the "decorations" around the windows, though some of them will allow nice customizations for that. The panel and panel applets are provided by GNOME itself.

I use GNOME, but mostly for the panel these days; most of my favorite applications have been cast aside by current GNOME management. However, by using GARNOME I can comment out the builds for crap that I don't want, and almost trivially add back in a cast-aside GTK+ application that I do want.

I use the Sawfish window manager (another cast-aside), customized to look like the old ShinyFusion theme I used to use under Enlightenment, with many virtual desktops to organize my work (I typically stay logged in for six months at a time), and with lots of nifty buttons in the "decorations" to allow things like maximize-vertically, maximize-horizontally, maximize-both, etc.

BTW, you can window shop for eyecandy at themes.org. It is organized according to what component supports a theme (window manager, toolkit, etc.).

Re:One possible feature I'd like to see

[whereiswaldo]

An annoyance with Mozilla is when it prompts you for the application with which to open a file. If I type "kwrite", it complains. I have to enter the full path to the app, even though it is on my path.

Note to flamers

[arvindn]

Everyone please read this before you start flaming.

The last /. article about the new file selector was filled with "this is totally stupid", "this is worse than the old file selector", "this is the last chance they have to fix it, and they've royally screwed it up", "usability experts, bah! This is why gnome will never catch up with kde" etc.

Now listen. The change that's happenning in the new file selector is primarily that they're creating a new API. Got it? The programming API. That's why the screenshots looked the same. The screenshots tell you nothing. As long as the API doesn't suck the front end can be freely changed without breaking anything, and everyone can do their own mockups and various ideas can be tried and the experts can weigh in with their opinions and so on. This can go on for a long time, and the front end will stabilize when it has reached (near) perfection.

I can't agree

[0x0d0a]

So a next-generation save/open box should include comprehensive network protocol support.

With all due respect, I think that this is a really, really awful idea. Unfortunately, Microsoft has traditionally taken this approach (for political, not engineering reasons). The KDE project, which takes a very Windows-like approach to a number of architecture decisions, copied their approach, and GNOME has come uncomfortably close.

The reason why I'm not a fan of implementing network transparency at the KIOSlave or GNOME-VFS or whatnot layers is that this sort of functionality is *not* KDE or GNOME or whathaveyou specific. It just isn't part of the desktop environment. It should be implemented at a lower level, so that *all* programs running on the machine can take advantage of the functionality. There are a couple of projects that do this -- take a look at LUFS for a proper (IMHO, of course) implementation of what you're asking for.

Where is the pathname?

[spitzak]

Why can't they put in ONE text field with the entire pathname, so it can be cut & pasted, and it can be easily examined and compared to another file in an email or other source, and it is obvious how to type in a pathname?

This can't be that hard, really. I did it ten years ago in a NeXT file chooser I wrote.

Have a SINGLE text field. Anything before the last '/' is the "current directory" and anything after is the "current file". Then add all the buttons and tab completion and scrolling list. As the user edits the text, update the display to match. As the user hits the buttons, re-edit the text.

I consider this obvious and I am dumbfounded that nobody seems to be doing this even today.

I don't care if Grandma is confused by pathnames. Grandma is also confused by insertion-editing of text fields but nobody seems to be trying to make it overwrite.

Show a little incentive, and do this right!

File selectors are crippled directory browsers

[AReilly]

Acorn got this aspect of GUI design right. You don't need a file selector. Opening or reading things is best done by clicking or dragging from an existing directory browser. Saving or outputting is easily done by dragging an icon that represents your file into an existing directory browser. Need to open a directory browser to do that? How is that different from needing to open a file selection dialog?

File selectors? How modal. How quaint. Just say no.

Re:More like KDE

[G27 Radio]

It's a freakin' file selector, what did YOU want done with it?

I personally would like to see it be multi-thread safe and written in assembly for maximum file selection performance.

all I want

[XO]

Is a damn file selector box, where if I enter a DIRECTORY NAME into the box, and then press ENTER, it will SWITCH to that DIRECTORY, rather than giving me an error, or showing me an empty selector box that isn't pointed to anything.

That's what irks me the most. I don't care how PRETTY the damn thing is.
I can't even make out what the hell half the controls on those mockups ARE...

Not enough alphablending

[MisterFancypants]

Seriously, these file dialogs don't have enough alphablending. While they're at it, they should throw in some lens flare too.

Hall of Shame

[cryptoluddite]

I wish gnome developers would study the UI Hall of Shame and fix the many glaring UI problems -- then gnome would be a really nice desktop.

Consider:

• The main point of a file selector is to choose a file. In the mock-up, only 22% of the dialog's space actually shows files compared to XP where 60% of the space is used for files. And honestly, a lot of the 22% is wasted in the GTK mockup. Defaulting to 'list' instead of 'small icons' doesn't help.
• There is lots of empty space next to the cancel/open buttons and 'send to' checkbox that is just wasted (see XP for how to do it right and still look appealing).
• Having 'Show All Files' button next to the filename field means there is less space to see the filename or type in a path into that field.
• the 'up' button is located about as far away from the files as possible, ensuring lots of extra mouse movement. There is no 'back' button.
• The 'shortcuts' list takes up lots of space and looks terrible when shortcuts with short and longs names are mixed, like in the example. Please tell me it doesn't resize with the window!

I use gnome instead of kde (on gentoo) but the lack of any UI sense is frustrating. Another example: the gnome-panel buttons grow to be unbelievably large if there are only a few windows open. This just looks terrible and combined with the layout problems make it nearly impossible to have a vertical or expanding bar that doesn't just look disgusting.

I really think linux is set to take off on the desktop this year, but these usability/aesthetic details can really have a large negative impact.

Who needs innovation?

[Paul d'Aoust]

You know, I have no problem with 'innovation' being touted as an absolute virtue. Yes, innovation is good, and it's always nice to develop new, more efficient ways of doing things, but... what if something already works fine? Why not copy from someone else if their idea is great? I sorely wish the GTK+ file selector has shortcuts, and I was ecstatic when I installed KDE 3.0 a year ago and found out they had added them in.

Innovation isn't the important thing. Usefulness is. Innovation is only one of the many tools used to create something useful.

'New Folder'???

[MyFourthAccount]

It's pretty funny that the 'even better' mockups have a 'New Folder' button on a 'Open File' dialog box.

Surely the intention of this button is to make absolutely 100% sure that the user can select a file that doesn't exist. I mean, what other file could a user possibly want to open?

There is simply no better file to open then the one that remains in a directory that doesn't exist yet.

Fileselectors are obsolete!

[Florian]

File selector boxes are a legacy of the early MacOS until version 6.x, which was single-tasking and didn't allow to switch between several applications running parallel. In fact, a file selector box is nothing but a miniature replica of a graphical file manager (like the MacOS finder, the Windows Explorer, konqueror, nautilus, rox etc.). The more "functional" file selectors got, the more bloated and redundant vis-a-vis the file manager they became.

It would make more sense IMHO to abolish file selectors altogether and instead throw users into their preferred file manager for opening files. All it would need is a freedesktop.org standard protocol for file manager/application interaction and perhaps a $FILEMANAGER environment variable. (Theoretically, $FILEMANAGER could then also be a shell in a terminal.)

-F

Re:Fileselectors are obsolete!

[master_p]

What you are saying is quite an interesting idea. Another version of it is to use a window of the selected $FILEMANAGER as the dialog for opening a file. For example, when I open a file in KWord, a Kongueror file window comes up in modal form, allows me to select one or more files, and then is closed. In this way, the look & feel (as well as other extras that the current environment puts into my filemanager) will be easily replicated.

Another idea is to use the simplest possible list (a simple dialog with a file list box and a text box with the path) and have a big red button which says "file manager". By pressing this button, a file manager window will come up in the current directory of the file dialog box, and let the user continue do file management from there.

You could say...

[Gordonjcp]

... that *no* industry is about innovation, but playing catch-up. GM/Vauxhall/Opel are touting headlights that swivel as you turn corners as a great new thing, but that's just playing catch-up to Citroen who had those on the DS nearly 40 years ago. Likewise varipower steering - ancient French technology. Or what about BMW, with paddle-change gearboxes where you select the gear with the paddles, then press a button to engage it? That's just playing catch-up to the Wilson Preselector gearbox, found in 1930s Wolsley and Frazer-Nash cars.