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 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

[Denver_80203]

The goal is *NOT* to kill Microsoft Windows

It's not? I dunno.. I have become more and more jaded against slashdot as of late. Most of my posts get modded down or I get bitched at for actually prefering MS. It's not really MS for me.. it's the applications and, well, I know it. I can identify with the tweaking coolness that linux is... for me that was once DOS. Granted Linux offers 10 times the coolness NOW but back then it was the best I had. Now I'm familiar and I feel like I'm on the freakin dark side. for me it's about getting it all to work togther. the most vocal part of the linux community seems out for blood. That attitude I get spooks me off and it's a crappy thing to do. I understand the goofing around but these guys are boarderline violent about it. I could be wrong but... I imagine its the same feeling the MS gave off back in the late 80s to mid 90s. i'm just rambling now...

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?

Gnome is lookin' good!

[rm -rf $HOME]

I've stayed far away from the KDE/Gnome debate for the past couple years, choosing instead to stick with simple, stripped-down window managers like fluxbox and FVWM.

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?

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.

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.

Re:Tab completion?

[caseih]

Exactly. Having tab completion has become essential for me. I can drill down to a file or folder far faster with tab completion than any other scheme (although ms's dropdown completions aren't bad). The OS X file selector certainly is simple and usable and hard to mess up, but it's significantly slower to use than the current gtk file dialog box. The fun thing is that tab-completion currently allows the current gtk dialog box to have the equivalent of simple bookmarks (~ tab to go home), and filters (*.jpg tab). I also love it (as was said in the parent post) how the file selector reduces the file list right down to just the files that match the current tab-completion pattern. It's like vi. Once you get to know it, it's very efficent and very fast. I think that the efficiency of the current widget is the reason it has taken them so long to come up with a replacement. Does the KDE selector still emulate windows and use that horrid method of a horizonally scrolling file list window?

Re:Ummmm, Who Is Eugenia?

[Anonymous Coward]

here you go

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:I really liked the original version better

[skidoo2]

Right. It doesn't matter who stole it first. It's still about two years behind the rest of the world. Sheesh.

I have a love/hate (mostly hate) relationship with M$ too, but at the same time I can't help but note that people getting jazzed about a common file selection dialog box really puts Linux in perspective regarding its viability as a desktop productivty OS.

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: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.

Re:I can't agree

[0x0d0a]

Sure, and there's a module for LUFS to support GNOME-VFS. However, this is awfully ugly. In the case of KDE, it means supporting C++ and the KDE types and model, and in the case of GNOME, the GNOME types and model. It's a lot of complexity, overhead and potential breakability getting added. Plus, do you want the additional dependencies? Do you really want to have to install GNOME for WebDAV support and KDE for SFTP support?

Re:I can't agree

[Telex4]

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

Hmm, you didn't give a reason why, and I'm not sure it's as obvious as you suggest. It would certainly be good if KDE and GNOME continue work through freedesktop.org to unify the underlying technologies that needn't be split up, like the coming transition to DBUS. It would be really great if the kio_slave system went the same way, forming the inspiration and basis for a cross-desktop protocol transparent filesystem (and note also X11 independent, since freedesktop.org doesn't rely on X11 for a lot of its technologies, e.g. DBUS).

But why all apps? When would most people really need all apps to do this? And how could KDE, for example, effect this sort of ground-level change?

Rather than wait around for someone to develop something that could be used by *all* applications, the KDE Project went ahead and made their own system that worked and is now influencing others. And thanks to technologies like Fuse and AVFS we may find that the kio_slave system is sort of "backported" to the basic UNIX filesystems by way of allowing them to be mounted onto the filesystem just as you'd mount a CDROM.

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:File selectors are crippled directory browsers

[be-fan]

Drag and drop is so manual. Who wants to fuss around with getting windows lined up just to save a file. Instead of hitting "CTRL-S," typing in a filename, and hitting enter, I know have to start up my file manager, unmaximize my window (I almost always have my windows maximized), get the two both visible at once, and drag the file over? And then I still have to name it!

Sounds like a stupid way to sap-away productivity just to adhere to "real world" metaphors.

Re:I really liked the original version better

[Denver_80203]

It'd be terribly annoying if UI ideas were patented and we had to have a bunch of half-assed environments

yeah. Every finger pointed is one less developing. *sigh*

Re:Nice Mockup

[Coryoth]

I love osnews little version, with all the directories in the path displayed at the top, the idea being you could click on them to go back to that directory.

It's a terrible idea, and, to be honest, typical of Eugenia's design style: Think of something cute, but don't bother to think it through. What happens when your path is very very long? Do you have lots of buttons? Do you stretch the window, or squeeze the buttons so they're unreadable? How is it an improvement over the standard option menu widget for dropping back directories that's even in the current GNOME file select dialog? The option menu scheme, as used in Tigert's mockup is slimmer, and provides identical functionality.

And what's with the weird layout on Eugenia's design?

I do like the drag and drop to add new shortcuts though.

I must say though, that for someone who bitches about bad GUI design all the time Eugenia produces some pretty shocking stuff herself.

Jedidiah

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:too complex

[Coryoth]

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.

Ideally all of those icons are completely configureable (and easily). If that is the case, then you simply set whichever icons you want to use instead of the stock GNOME ones. There were always going to be a few complications for using GTK apps in a non-GNOME environment, but ideally it should be a quick and easy configure away.

Jedidiah

Re:innovate damnit.

[timotten]

File selectors should be longer horizontally since file names can be long. Having something that is taller than it is long is just dumb, there just isn't a polite way to say it.

The file list widget -- but not necessarily the file selector dialog -- should be long horizontally, and all the mockups are better than the current layout (a narrow widget for directories to the left of a narrow widget for files). Eugenia's file list widget is actually wider and contains more information than tigert's. In fact, if you give Eugenia's dialog and tigert's dialog the same dimensions, Eugenia's will handle long file names better (though it will show fewer file names).

Re:I know these folks are working hard...

[Coryoth]

Especially since it's more ripping-off of Windows XP, when meanwhile the community claims to despise Windows.

It does bear a lot of resemblance to Windows yes. And the KDE select dialog (which bears a lot of resemblance to Windows, yet again). It also bears some resemblance to the MacOS X file selector.

As far as copying ideas - given the state of the current GTK file selector, they had a LOT of catching up to do, so it's inevitable that they'll just copy the current modern file selectors to get up to speed. Windows has a pretty good file selector - it occasionally changes from app to app, and the bare bones file selector from Win2k era used by some apps was pretty poor, but in general, and especially by XP they have it down fairly well. Why not use some of the good ideas?

Jedidiah.

Re:I really liked the original version better

[Anonymous Coward]

Well, MacOS X has a real ~ (home) but still feels the need to provide pre-fab "Documents", "Pictures", "Music", "Movies" folders and so on.

Except for the actual pathname, I don't see a big difference between modern Unix and Windows systems.

Re:I really liked the original version better

[be-fan]

You missed my point completely. I'm not saying that the file dialog is just a minor thing. What I'm saying is that the file dialog is not representative of GTK+ as a whole. You implied that people getting excited over the file dialog meant that the Linux desktop had a long way to go. It doesn't. The file dialog is an outlier, you can't draw any conclusions from it.

And the new file dialog didn't get put off because people didn't consider it important. It got put off because there was a significant technical challenge in switching to the new API required to support the new dialog. The GTK+ folks didn't want to rush out a half-assed solution, but take the time to implement it properly so something similar doesn't happen again.

And you are misunderstanding what I mean by remote servers. I'm talking remote servers in general, not just special cases for AppleTalk and SMB like MS and Apple do. KDE supports a completely generic filesystem model, where you can access ssh, webdav, smb, etc, servers through the file dialog.

Re:I know these folks are working hard...

[Coryoth]

Because people here are always complaining about how "bad" Windows is, yet cheer when one of its features is ripped off.

Yes. But then you must remember that they are idiots.

It makes the Linux GUI projects look like mere attempts to provide free versions of Windows-alikes rather than their own unique innovations on the desktop paradigm.

That's a little unfair. Certainly GNOME isn't looking like all that much of a Windows alike - only as much as MacOS X. Progress is a little uneven. There are some things that are pushing forward, and Windows will be borrowing. Other areas, such as the file selector have lagged shockingly behind, so Windows gets borrowed from. It's swings and round abouts. In the end the Linux desktop is still playing catchup though. It should be interesting where GNOME and KDE stand when Longhorn eventually comes out. We may be closer to a level playing field by then (because GNOME and KDE are catching up (and excelling past in some areas).

The again I think if you want real innovation you ought to look to fringe projects - GNOME and KDE are both, largely, steady as she goes deals. It's the small projects that often pioneer interesting new ideas that eventually make their way into the larger projects. I'm still waiting for tabbed windows (originally in PWM, but most famous in Fluxbox)to become standard in both GNOME and KDE. I'm also hoping they'll stop rewriting the base libraries for Enlightenment and get around to working on the desktop - Enlightenment used to harbour some of the more creative and original ideas.

Jedidiah.

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.

Re:Bigger question

[Idaho]

Doesn't the fact that a new Linux file selector dialog box becomes headline news really illustrate the state of the Linux GUI?

I couldn't agree more, except that you're making a mistake - there is no such thing as 'the Linux GUI' (some people might think this is a problem as well, but OK).

My point is, this has not been a problem in QT (and hence, KDE) for years, so what you should have said is "..doesn't this really illustrate the state of the Gnome/GTK UI".

Obviously, Gnome/GTK is not Linux-specific either, so why do you only mention Linux, and act as if GTK is the only GUI toolkit that is used together with Linux? I mean, isn't the whole point of Linux to have more choice and freedom?

Thankyou!

[horza]

Yes, the one thing I am sick of under Linux is the stupid Windows-copy file selector. Every time I want to save a file I have to pop it up and wend my way tediously from the normally illogical default start point. I would love an Acorn-like drag-and-drop system, much like ROX tries to do. Make it globally selectable in KDE/Gnome what file selector module to use so those that prefer the old way can keep it but those that need the drag and drop can have it in all their apps.

Phillip.

Re:Gah! Windows-envy!

[Lord Bitman]

The problem is, the current file selector is the worst layout I can think of, and the one in windows is pretty good.
I hate those "Home" "Trash" "Desktop" buttons, yes, and if there's no way to turn them off, it's a huge mistake. However, The idea of having a seperate place to type file, directory, and filter, that is a good thing.
The Linux version of Opera has a very good (though not perfect) file selector. Oh no! It's a clone of a successful and easy-to-use design! That must make it bad!

-Make it look like the windows file selector. Windows has a GOOD file selector, so you may as well start from there.

-Get rid of the extra windows-only crap (Like a "Desktop" button. That whole area where the "Desktop" button resides should be killed too.

-Allow people to actually type paths into the directory selector- including Tab-completion and bash-style escapes (eg: /home/$USER/`cat /var/omgwtf`/)

-A comprehensive filter which supports both simple patterns (*.mp?g) and regular expressions (with a fucking EXAMPLE of what syntax the regexps follow, god damnit! I hate not knowing if I should begin/end my patterns with /, and whether I should escape my parens. Are there even two programs which use regexps the same? It's fucking annoying, developers should clue in)

-allow patterns/bash escapes/regex/etc in the file selector AS WELL. Not "In the file selector, but not in the filter", not "in the file selector, so you don't need them in the directory selector", but allow them in every place you can type a path!

-If I type a directory into the file selector, don't close the file dialog when I hit enter. EVER. If it is a directory selector, give two buttons: "Use Current Directory" and "Use Selected Directory"

-Always show the user's home directory in the path drop-down. some MRUDs would be nice too, seperated by an HR

-stop and think to yourselves "Is this the gayest shit ever?" before showing off your ugly designs.

Re:Bigger question

[0x0d0a]

Doesn't the fact that a new Linux file selector dialog box becomes headline news really illustrate the state of the Linux GUI?

Apple has generally been considered a pretty good pathblazer when it comes to UI.

Apple was, not very long ago, in the news with OS X's new file selector.

So, no, I don't consider having a change in your file selector imply that your UI is behind.

That being said, the old GTK+ file selector really did rather suck.

Re:shell prompt

[tigert]

It wont :)

But there are a lot of people who need it. I use terminals myself too for tasks that make sense - compiling stuff (other peoples code mostly :) and for IRC (never got used to xchat and such).

But for non-text stuff like using the Gimp, editing and finding photos etc, there really needs to be a good file selector, it's about fricken time and I'm excited to see it happen now. It needs to have good keyboard shortcuts too, so one can use it without the mouse, like when saving a document from a text editor - where you are not grabbing the mouse all the time.

The commandline has its uses, but I much rather find photos by thumbnails than by looking at the filenames :) /tuomas

The problem with file selector is it's existance

[CaptnMArk]

A better GUI would be to have no file selector at all.

I wonder how long it will take for everyone (GNOME/KDE) to realize that...

that's not the original version

[ajagci]

No, that's not the "original version". Smalltalk, for example, had graphical file selection dialog boxes showing directories and file lists years before the Mac, and I don't even want to claim that Smalltalk was first.

In fact, text-based, screen-oriented interfaces had file selection dialogs that would present lists of choices from which you could easily pick.

Both of Them SUCK!

[xjimhb]

What is all this "Desktop" junk and all those stupid icons? And what is wrong with "Up"? We are dealing with a tree structure here, a nice clean file system, not the new "Micro$haft File System" that Uncle Bill is trying to foist off as part of "Long-Horny".

Why do these people try to brand good, working, interfaces as "legacy" and delete or mangle them?

The file selector on my Gnome Red Hat 7.0 system is clean, easy to use, and I find nothing "non-intuitive" about it.

Leave it alone, dammit!!!!

Re:Its ok, just dont bother to copy crap

[savuporo]

What i dont like to see, is when people try to copy the crappy ( but sometimes, pretty-looking ) features, that actually draw away from usefulness.

Improvements to file selector are all fine and dandy, as long as the thing actually improves the way you can work with it, at acceptable performance ( as this particular version seems to do )

But there are lots of widgets incorporated into "modern GUI-s" that should never have left the drawing boards. Witness the WinXP desktop in default post-install configuration. You have to spend significant extra effort every time to turn all that fancy crap off. And thats every time you create a new user profile.
Heres where OSS stands head and shoulders above anything that M$ has to offer, you dont want the misfeatures ? Simply dont install them.

The nice thing about KDE's file selector...

[JCholewa]

I'm taking a look at KDE 3.1's file open dialog box via an impromptu vnc session on a lonely ratpoison'd X session. I haven't played with the WinXP's dialog box, but here's the things that make the KDE dialog box more innovative than the one in Windows 2000:

A) You can right-click to add, delete and edit the shortcuts in the "Navigation Panel" (that's what KDE calls the "Places Bar"). In Windows, you'd have to add a registry key in a rather nonintuitive place ("HKCU\ Software\ Microsoft\ Windows\ CurrentVersion\ Policies\ ComDlg32\ Placesbar")

B) You can hide and unhide the Navigation panel via the mouse or the keybinding. In Win2k, you would have to play with the registry for this, which makes it rather annoying if you'd prefer to have the Places Bar hidden 90% of the time, only to be revealed when needed.

C) You can customize the Navigation Panel so that there are shortcuts common to all KDE apps and also shortcuts individual to each application. I frequently visit "/mnt/niven/code" from kate (a text editor with syntax highlighting), but I'd have no reason to go there from K3b (a rather sweet CD/DVD burning app).

D) You can swap between large and small icon size for shortcuts in the Navigation Panel. Nice if your current program has a ton of shortcuts. Oh, there's a scrollbar for when you have too many icons to fit in the visible space.

E) There's a button to refresh the current directory listing. I have to hit "F5" in Win2k more often than you'd think, so mouse access for this is kinda neat.

F) A bookmarking system is built into the selector. I don't use this, but I can see how it might be useful for some people who need a little more flexibility than you'd get from the regular, flat Navigation Panel.

G) Sorting is a little more flexible, allowing you to sort in any view mode without having to right-click (in Win2k, you have to do this unless you're in "Detailed" view mode). It also allows you to decide whether the sort is case sensitive, and it's easier to reverse sorts. And you can specify whether you want directories all listed above the files or intermingled in the sort.

H) You can dynamically toggle the listing of hidden files (there's a menu button for it, or you can just hit "F8"). That's a far cry from the more time consuming "explorer.exe, Tools->Folder Options->View->Hidden Files and Folders".

I) File previews are built into this widget, and you can toggle this on and off. Moreover, if you go into KDE's configuration gui, you can tell the system which file types should be previewed.

J) At any time, you can separate the files and folders into two separate window panes, or you can put them in the same pane.

K) As with the Win2k file dialog widget, there are dropdown widgets for the active directory ("Look in"), file name and file filter ("Files of type:"). But while Win2k only makes the file name editable by the user, KDE allows you type into any three of the fields. This means that I can change to another directory easily without having to worry about accidentally mangling the file name. Sometimes, Win2k takes a while to pop up the "Look in" bar when I click on it, and while I could type a directory location into the "File name" widget, I'd lose the file name itself (in a "Save As" situation)! And if I wanted to look at all *.html files to open up in notepad, the filter widget is useless (it only lets me pick "*.txt" or "all files"), and the only way to do it -- typing into the "File name" widget -- also destroys the existing file name.

L) The KDE file dialog box is fully network aware. I could load from or save to a file via ftp or ssh (sftp), and it'll even remember the passwords during my current session.

I'm sure that Windows XP has most of these improvements built-in. I'm not trying to suggest that putting the latest KDE against Windows 2000 is a valid comparison. But I do like that I can get the above capabilities without having to spend even more money on Windows than I already have.

--
-JC
coder
http://www.jc-news.com/parse.cgi?coding/main