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

[j-pimp]

Uh except that MS got it from Mac!

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

[49152]

who got it from Xerox

Re:I really liked the original version better

[be-fan]

Hey, its just the GTK+ people that are living in the stone age!

Seriously, though, the file dialog is hardly representative. It was just an oddity in GTK+ that just got put off way longer than it should have. Other parts of the desktop are not like that, and in a lot of respects, they are ahead of Mac/Windows. For example, I can access remote servers transparently, right from the file dialog in KDE. Very handy when you live in a networked environment like a university.

Re:I really liked the original version better

[Anonymous Coward]

That left pane is an ugly waste of space. This is especially true under a Unix like file system, where everything is stored under "/". With that ugly left pane, you get shortcuts to "/", "~", and the ever useless "Documents" folder (I won't reduce myself to shlopping all my files into "Documents" when I already have a perfectly good home directory that I can access very quickly already).

Under Windows XP, where your home directory is usually under "C:\Documents and Settings\acct_name\My Documents", the left pane is understandable, but still ugly and wasteful of space that could be better spent putting more file icons on the screen.

Don't say that the pane is for newbies, either. The real way to help newbies is to get them to organize their files out right the first time, instead of giving them an uglier Windows.

Re:I really liked the original version better

[eswierk]

This is the true original version.

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

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

[ComaVN]

Yes. You see, they *COPIED* it. gettit? Ahhahaha

Re:I really liked the original version better

[jangell]

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?

Re:I really liked the original version better

[dair]

Not quite, that's just a normal Finder window.

A file open dialog is one of these (displaying list view: the 4th widget from the left will toggle it into column view).

Re:I really liked the original version better

[d_i_r_t_y]

KDE1 did true network transparency first.

ever since KDE1, any kde app can read/write files in any app in a network-transparent manner, using not just ftp://, but also sftp://, smb://, http://, and several others -- just prefix the filename with the correct URL prefix and it just works.

try doing that in notepad, or even window explorer for that matter.

Re:I really liked the original version better

[lintux]

And of course the idea of transparent terminals is sooooooooo original and unique that Apple would never be able to come up with that when the OSS people hadn't.

Just wondering, are you also angry with Apple because they "copied" the Terminal itself, or maybe the command line? Or maybe because they also have a Unix-like filesystem?

Re:I really liked the original version better

[ant_slayer]

kill -9? Try taskkill /F /PID [pid] sometime. And if you don't know your WinXP processes by PID, try tasklist for a list of 'em. Oh, right... this is only in XP Pro. Remember that, in case you're running XP Home -- you have to get third party tools for the "little" Windows.

Actually, there is *some* power in the Windows commandline, it's just poorly documented, and more poorly understood. Too bad it's still missing grep, sed, and awk (though there is "find" for some grep-like tasks).

Just my $0.02.

-Josh O-

Re:I really liked the original version better

[Kent Recal]

Who the hell would want a transparent terminal anyways?

Why not just run xscreensaver demos on the terminal backdrop?

Color cycling would be a nice feature, too (helps concentration).
Wobbling fonts could really aid to get work done while drunk.
Also I'm sick of the general static behaviour and boring shape of my xterms.
We have 3d acceleration, can we please get shape-changing terminals?
I want mine to be mapped onto a sphere and bouncing around the screen please.
And don't forget the bump mapping of the remaining desktop.
Oh I didn't even start, yet!
The crippled appearance and functionality of the cursor is pathetic, too. Can't you come up with something more sophisticated than a retarded blinkin' block?
Someone's definately stuck in the 80s there.
The cursor should generally change shape and bounce around like the rest of a well designed terminal window. For added productivity it definately needs to be able to leave the window, too. When will you guys fix these braindead APIs that lock the cursor up in a rectangular box?
Can't you even imagine the possibilities of a bump mapped 3d cursor that gives you the power to type in creative circles (and down the z-axis, too) all over the screen?
And why did backspace never get its cut of the so called "multimedia" (hohoho) revolution?
God damnit, it doesn't even make noise!
Next time you design a terminal emulator would you PLEASE at least get the basics straight and have an animated Ms Pacman to eat the letters on del/backspace?
I mean c'mon, work's hard enough as it is. We don't need to see depressive geometrics all day long.

And WHY THE HELL, yes WHY THE HELL do we still have close, min and maximize buttons on the window borders?
I mean, HELLO?
Can you spell M-o-o-r-h-u-h-n?

Ah this is all too much for me, mod me down..

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

[Anonymous Coward]

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

the stinky foot

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

[abigor]

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++. I can't figure either of these things out. If you want to write GPL'd code with Qt, go ahead. If you want to develop commercial software, buy a license (a miniscule cost for any software shop). It's pretty simple. And the weird conspiracy theories about Trolltech and SCO are just laughable.

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. And generic programming (most crucially, the STL) simply isn't possible in C. These days, I can't imagine programming in a strongly typed language without templates. Why not admit that C is a specialised language, and that better languages exist to build a desktop framework? I don't get 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).

Re:I need to ask

[joib]

Ah, the eternal C vs. C++ flamewar. I've been somewhat of a C++ fan, actually learning C++ before C when I started learning about programming a long time ago. But lately I've been gravitating towards C, primarily because of its simplicity. Rob Pike (one of the creators of Plan 9) summarized C++ quite well with "it's a very difficult, tricky, special-case-ridden language that takes taste and experience to use well.". E.g. take a look at gotw.ca (Herb Sutters website) for a large bunch of situations where C++ manages to bite your ass, in quite non-obvious ways.

Now, on to GUI programming. If there is one area where OO programming languages shines, it's GUI programming. I'm personally not very much in love with doing OO programming with C, GTK-style. What I prefer is using a high level language with bindings to a GUI toolkit, my personal favourite being python and the wxpython bindings to the wxwindows toolkit.

While python as a (bytecode)-interpreted language is slow compared to C/C++, performance of a GUI app doesn't suck that much because much of the prosessing is done in the C/C++ layers beneath your own code.

And if performance is a problem, it's easy to code that part as an extension with C and call it via python (SWIG is very helpful here). This is, IMHO, a very powerful approach to develop many kinds of applications, i.e. code the majority of the program in python, while the parts that are critical to performance (if any) are done in C and then use SWIG to make the C code callable from python.

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.

Re:I need to ask

[mackstann]

Can I make software with the Qt Free Edition and release it under the GPL, BSD, or Artistic license?

For Qt/X11 Free Edtiton the answer is yes. Since Qt Free Edition is provided under both QPL and GPL, all license conflicts are avoided.

Awesome! Thanks for clearing this up. I totally forgot that the QPL even existed.

Re:I need to ask

[IdleTime]

I honestly don't know what kind of hardware you run, but on my P4 2.4Ghz, KDE is lightening fast. If the whole KDE system takes up 3GB of disk space on my dual 320GB system, who cares?

I've heard this bloat and speed thingy about KDE and Gnome for years, but I have never experienced it myself! I have also used XFCE4 a lot, but it lacks all of the little things I use from KDE.

Another argument is the startup time of KDE (Gnome), but i don't care if it takes 1 second or 30 seconds, I normally only start the GUI every time I need to boot into a new kernel, so it is not an issue.

I think it is just the new and 1337 thing to call everything but the most uber-cool and geeky WM for bloated and slow. Pay no attention to these fools :)

Re:I need to ask

[IamTheRealMike]

C++ gets a lot of antagonism from Gnome people. I've seen it many times.

I have to admit, I've never seen it and I follow Gnome (and to a slightly lesser extent KDE) closely. I see far more anti-C antagonism from the KDE/Qt crowd than anti-C++ antagonism from Gnome/GTK. In fact the GTK developers have even said that if you use GTK for a big project you probably shouldn't be using C.

Of course, C++ bindings are available for GTK. But who will use them if there is an a priori hatred for the language? Do you see my point now?

No, I don't. In fact GTKmm is used plenty - often by in house commercial projects. See the gtk.org success stories - many of them are based on GTKmm. I've never seen people flaming GTKmm because it's C++, in fact.

A huge issue is generic programming. Few people understand the boon of the STL until they use it. And home-grown generic templates are unbelievably useful as well.

Templates have costs and they have benefits, same as anything else. The costs are obvious - fewer people understand them, and being basically a textual hack when they go wrong the error messages have to be seen to be believed. The benefits can sometimes (often, perhaps) outweigh those costs.

I can't specialise on structures written in C, a real strength of KDE/Qt.

I really think you should check out GObject. It's a light year from being just "structures in C". In particular GObject has things signals and reflection. It was designed with object orientation in mind, and as such wrappers like GTKmm can do a good job.

Sorry. GTK is used in VMWare, and so far as I know, that's the only commercial app on earth that uses it

Then I'm afraid you are seriously misinformed and I see no reason to take you seriously. See the gtk.org success stories page, they are almost entirely commercial/proprietary software developers.

I have seen it happen many times - people who are scared by OOP, defensive about their lack of knowledge, and maintaining that C is perfect for everything, when Python, Java, or C++ are better fits.

I hope that comment isn't targetted at me. I've written plenty of OOP code in my time, in a variety of languages. I'm certainly not "scared" of it. I've written bindings from Delphi (which has a pretty clean object model) to Python. I've written Java class frameworks. I've implemented parts of COM (though whether that's object oriented is highly arguable). Object models are in interest of mine - I can argue with you about the merits of CORBA vs GObject vs [D]COM vs .NET vs native C++ all day.

What I am pointing out is that your blanket assertion that anybody who doesn't use C++ or Qt is "irrational and emotional" is pure zealotry - the real world is simply not that black and white. Why do you think so much software is written in Visual Basic? Because of its merits as a language? I think not.

No offense, but I get the feeling you write code as a hobby, not for a living. You have all the time in the world to plink away at your little projects. I don't want to belittle your efforts, but please get real.

Then your feelings are as incorrect as your beliefs. I've worked for my countries Ministry of Defence (Java, C, XML and relational databases, webapp development), I've contracted (Delphi) and I've been paid freelance to do free software. I've worked the span from education software for preschool kids to reverse engineering DCOM. I would have done more but I'm 19 and simply haven't had the time.

In the case of much Linux software development, C is a popular choice because lots of people are very familiar with it, and that's more valuable than being able to play with functors. If you want to of course, GTKmm lets you do that: the interfaces to (for instance) the tree view are designed to strongly resemble the STL.

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?

Re:Looks a lot like the Mac OS X file selector

[Corvus9]

I don't think it looks like either the Mac OS X Cocoa or Carbon API file selector.

The Cocoa file selector effectively shows a spreadsheet of all the files in all parent folders of the current one. Fast to navigate but IMHO bewildering for a novice user. Also, the favorites are in a pop-up menu that you can't drag folders to.

The Carbon file selector is based on the classic Max OS navigation service; essentially it shows a dialog with a mini-Finder (i.e. file manager). I liked this method; opening a file from an application works the same as opening it from the Finder. I regret Apple didn't continue with this in OS X.

I know these folks are working hard...

[Osrin]

... and I don't want to be rude.

Neither of them are particularly inspiring though, I thought the community was hoping to steal the hearts and minds of the consumer in 2004.

This is not meant as a troll, although I know it will be read as such by some.

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

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

[Dion]

"desktop paradigm"?

That should earn you a score of:
-1 Astroturfing PR-nitwit.

About the "windows bad" vs. "reusing windows ideas good" issue; no there is no problem here, windows does suck major ass, but there are some good ideas in there that are worth reusing.

The biggest problem with windows is not that it's badly designed nor that it's badby implemented (it's both), but that it's non-free, reimplementing features in free software thus fixes the biggest problem with windows.

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

[mshiltonj]

Neither of them are particularly inspiring though, I thought the community was hoping to steal the hearts and minds of the consumer in 2004.


I think you're right. We are trying too hard to copy what has already come before. No matter how good we do it, we are still copying.

So, with my years of experience at interface and graphic design, I've spent the last couple hours trying to come up with a file selector that tries to be, as you said, inspiring.

What do you think?
http://mshiltonj.com/new_stuff/file_selector.html

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?

[Anonymous Coward]

here you go

Re:Ummmm, Who Is Eugenia?

[jared_hanson]

what does sending him/her love have to do with saving my files?

Well, in the case of her if you don't know, then you and your parents missed a very important conversation.

In the case of him it probably doesn't have a whole lot to do with it, even if evidence presented in Jurassic Park is to the contrary.

In all seriousness, I believe it is referring to the maintaner of OSNews. I believe it is a she, and they post quite a few UI mockups on their site, and some constructive discussion usually follows.

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.

Re:Ummmm, Who Is Eugenia?

[gnugnugnu]

Please dont have a default dialog that encourages devepers to add lots of extra widgets.

I predict it will get very ugly very fast.
Huge cluttered dialogs here we come.

I stongly believe there should be an options button at the bottom of the dialog to take users to a seperate window for toggline all sorts of extra settings and that developers should as much as possible avoid cluttering the dialog and instead aim for clarity and simplicity.

One possible feature I'd like to see

[Limburgher]

Will the shortcuts on the left side (home, etc) be configurable? That would be one way to beat the crap out of Windows once again. On my one Windows box, I never put anything in My Documents, I keep it all elsewhere, ona FAT32 partition for dual-booting use. I'd LOVE configurable shortcuts.

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.

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

Nice Mockup

[nervlord1]

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.
Example:
user clicks root, stuff, music
(root, stuff, music, / appears at the top)

user decides he needs to go back to root, clicks root
(top now says: /, root)

It could really work, and be really useful.

Keep at it gnome boys!

Re:Nice Mockup

[Paul d'Aoust]

from what I've read somewhere in the wild blue of mailing lists et al, apparently the new file selector class can be extended by developers to include things like preview panes. (Actually, developers for GTK+ 2.2 and earlier can do that with the current file selector too -- you can see an example in GIMP 1.3.)

The GTK+ developers are taking care to include as many good features as possible, and then develop a framework that allows easy extension. It's not apparent from this example, but the checkbox to send love to Eugenia is supposed to be an example of this extensibility.

Re:Nice Mockup

[timotten]

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.

I like it, too: going up a couple of directories only requires one short click. Using a combo box either requires two clicks or a dragging motion.

The problem is that it will suck for really deep directory trees. (Getting to the root will require clicking the arrow button several times.) I would like a compromise where the first button pops up a list (like the combo box) and then several buttons show the deepest directories.

For example, if the directory were

/home/me/music/artists/Crazy Fool/Greatest Hits

I would layout the path navigator like this:

[_ICON_] [artists] [Crazy Fool] [Greatest Hits]

Clicking on the icon would pop up a list (like the combo box):

| //////Greatest Hits
| /////Crazy Fool
| ////artists
| ///music
| //me
| /home
| /

This makes it easy (one click) to go up when you're browsing a small subtree in the file system, but more difficult (two clicks or dragging) to browse all over the file system. The latter case shouldn't be common, though, since "Favorites" would abbreviate navigation among distant subtrees.

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: 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:Gnome is lookin' good!

[Paul d'Aoust]

I've been watching XFCE for a short while, and it looks like a superb light-to-medium-weight desktop environment. Its toolkit is GTK2, so you can use a lot of the existing GTK2 themes out there. As for the window manager, it's not Metacity or Sawfish (the two popular GNOME window managers), but it has a window manager of its own that is apparently fairly skinnable. The dock reminds me of CDE or OS/2 Warp, and I remember Warp's dock being very nice. Way back in 1995... wow, that was ages ago.

I haven't installed it myself, but I really want to give it a spin as soon as I fire up Linux again.

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?

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

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

[RdsArts]

Nothing says "KISS" like a XML file to configure the **** out'a the file selector.

If you want to see real KISS, check out ROX-Desktop. A DnD item with a filename under it, save by dragging it to your filer. Open by draggin the file from the filer to the app. A file manager manages the files, so you don't have a dialog trying to cram all it's functionality into 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:too complex

[zsau]

The new dialog will be customisable. I imagine the ROX people, for instance, will rapidly replace it with an XDS implementation as much as possible.

Web/file browser

[gnu-sucks]

I think the next 'evolution' for linux desktop would be the merger of browsers for local and network data.

Yes, this is like windows. But linux could do it so much better.

A truely cohesive network workstation should be able to save or open any document to or from anywhere. Appletalk shares, WebDAV, HTTP POST, FTP, rsync, etc.

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

Of course, any mounted file system (networked or otherwise) can easily be saved to with all current file selector dialog boxes, but can you save to your .MAC account? Or can you upload to your web site? What about sending it as an email attachment? Or a fax.....

Be was a great OS, wasn't it.... :)

Re:Web/file browser

[RdsArts]

Why not AVFS?

Don't make things browse to network shares. Make networked things look like file systems to the tools available. Same idea, only with less recoding, and as such a smaller point-of-break. :)

Re:Web/file browser

[be-fan]

So what does KDE do for a "next-generation save/open box?" Because KDE has had support for this, in the form of KIO, for years. In any KDE file dialog, you can just save a file to "fish://foo" and it works just fine. It supports a ton of protocols, including SMB, bzip2, http, ftp, pop3, smtp, webdav, nntp, etc. Hell, there is even a cool KIO handler for APT, to turn Konqueror into a package manager :)

Great, install KDE.

[Inoshiro]

I've said it before, and I'll say it again, the KDE v3 file selector is the best one I've ever used simply because the shortcuts on the left hand side are easy to use and customize (just give 'em a context click, and you can change the name, location, icon, etc).

And then you add in cool features like the kio_slave support (so that the location can be a WebDav dir for DnD file publishing, etc), and the fact that the custom locations can be made app specific (wow, my digital camera knows about my image dir, but I won't worry about that cluttering my kwrite dialogs!), and you see why KDE is a great DE to use.

The KDE folks got the file dialog right a while back -- it's time more people noticed their great work.

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.

Re:KDE's file selector

[0x0d0a]

KDE has an awesome file selector - as I go down the list of PDF files, and choose one, a preview window shows the PDF scaled, right there in the selection windo

You're confusing GNOME and GTK+.

The discussion is about the GTK+ file selector, which is analogous to the Qt, rather than the KDE file selector.

Open-source world stealing ideas [flamebait]

[shanelenagh]

There is a lot of "borrowing" from Microsoft in the open source GUI world. I know some genius who thinks he knows something is going to make a comment about Microsoft "borrowing" from Apple (and, if they want to be fair, about Apple "borrowing" from Xerox).

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

[zsau]

An interface designed for DnD saving will not encourage maximised windows, or it will let you use a panel/taskbar-with-shortcuts-to-folders. ROX does both.

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.

Missing the point

[dmiller]

The point of the new GTK+ file selector is not so much how it looks than the fact that it is based around a new, extensible API. The old implementation was so tied to the API that its appearance couldn't really be altered (on a system-wide level), the new file selector can.

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

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:slow news day?

[johnisevil]

Are you kidding? Linus' gas isn't like ours. It's open source. Bill Gates charges licensing fees to be in the same room as him when he passes gas.

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.

Re:Hall of Shame

[Animats]

Exactly right. Go read "Tog on Interface". The wrong stuff is taking up most of the real estate. Not only is it yet another combo box, it's a lousy combo box.

The whole "Locations" column is redundant once you've started selecting a file.

Let's see some long filenames and long pathnames in those mockups, and see how it holds up. The example has no scrollbars. That's unrealistic.

Why do we have "full screen", "minimize", and "close" options on a dialog box? Note that the "Cancel" and "close" buttons typically do the same thing.

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.

readline-like text input fileds?

[femistofel]

i wonder, do GTK or Qt or any other toolkit feature readline based or readline emulating text input fields? many of us can type much faster then do wrist wrecking mouse gestures, i'm especially trying to avoid double clicks as inherently evil and I KNOW MY FILESYSTEM, i don't care how beautiful and selfexplanatory the icons are - they do not enpower me, i still prefer to ls /u <TAB> /p <TAB> /med <TAB> s <TAB> to see what's in my /usr/portage/media-sound directory.

i don't mean point-and-click and drag-and-drop interfaces suck, i just mean: why the mainstream open source desktop environments try to mock the mainstream commercial desktops? why command line and desktop are kept two separate worlds? why <TAB> serves absolutelly different functions in command line and GUI?

i dream about the day when using desktop applications will be as intuitive for a command line user as for somebody whose right hand seldom leaves the mouse. as for now i often feel trapped when i have to use another GUI application [for example using mozilla at the moment. why can't i maximize this text field? because i can't do that in IE?]

KDE 3.1.x file selector screenshot

[osho_gg]

Look at

http://www.kde.org/screenshots/images/3.1/fullsi ze /92.png

For KDE 3.1.x file selector screenshot. I prefer KDE version much more than the proposed GTK+ variants for the following reasons:

1) Preview that works fast and well. The previews for text, ps, pdf, jpeg, gifs etc. are very fast and very readable (even for texts). Also, almost all filetypes that I have run across are "previable".

2) Back/Forward arrows. I wonder how come they are not there in Gnome mock-ups. They have proven to me to be very very useful.

3) Network integration.

4) Icons/Look very well integrated with the rest of the KDE applications. For example, up/back/forward actions use the same icons as in the konqueror browswer.

Re:Bigger question

[Gherald]

> Open Source isn't about innovation - it's about copying... no driving force except playing catch up.

Its true, OSS doesn't have much of an R&D budget.

But our code is more solid and most of all, free and open. Therin lies the main attraction.

Keyboard seeking of files

[robolemon]

I only hope that I can type in the beginning of the name of a file and have it jump to that file in the list! I still haven't found a GTK+ file select dialog that does that before.

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.

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.

Re:Fileselectors are obsolete!

[grumbel]

Rox has something like that, the whole filemanagment is basically based on drag&drop, to load a file you drag it on the application, to save it, you drag an icon given by the application to your filemanager. Its pretty neat, but to make this one really work well all apps would need to follow that paradigma and looking at the whole mix of software out there I don't think that will happen in the near future, which is kind of a shame.

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.

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.

Re:You could say...

[Sigl]

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.

Don't forget the "Tucker" by Preston Tucker in 1948(?)

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

the KISS approach: use locatedb

[mydigitalself]

i photoshop user interfaces all day, so forgive me for not having the energy for visually articulating this idea...

the idea was inspired by Suggestion 3. if you go and read the discussion thread about this, the idea was actually to implement a FILTER rather than a SEARCH. i find this articulation a bit silly really because SEARCH implies a global search not a filter.. which made me think:

if you had a really simple dialog box that had a search capability you could just start typing in "hilton pari". in the background one just interrogates the slocate database and starts to put all items that start with "hilto..." in a list view below. the list view should display the parent folder of that element with a hyperlink/expander of sorts to illustrate the full path to that file.

furthermore if you abstracted this functionality, you could offer the same global search capabilities across filenames in the "recent documents" interface. so this would extend the search boundary to elements that are possibly not in your slocate database (SMB shared docs for example).

there would still be browing capabilities to allow users to do regular browsing of CD, Network etc... but i just thought this would be a highly Googleian way of opening files.

There *IS* a regedit hack to improve EndTask

[zapp]

I just discovered this the other day...

The registry key
HKEY_CURRENT_USER\Control Panel\Desktop\WaitToKillAppTimeout
(And if it isn't that one, just search the registry for 'WaitToKillAppTimeout')

is defaulted at I think 5000ms. Changing this to 0 gives you back that "shot to the head" effect.

Also, others have mentioned the desire for lsof or other such things...

go checkout SysInternals. They have tons of freeware monitor file handles , processes, threades, memory, DLL Accesses, port accesses, disk accesses, ...

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

Frobnicate from the Jargon file ...

[cyrus007]

From Jargon File (4.3.0, 30 APR 2001) : frobnicate /frob'ni-kayt/ vt. [Poss. derived from frobnitz, and usually abbreviated to frob, but `frobnicate' is recognized as the official full form.] To manipulate or adjust, to tweak. One frequently frobs bits or other 2-state devices. Thus: "Please frob the light switch" (that is, flip it), but also "Stop frobbing that clasp; you'll break it". One also sees the construction `to frob a frob'. See tweak and twiddle. Usage: frob, twiddle, and tweak sometimes connote points along a continuum. `Frob' connotes aimless manipulation; `twiddle' connotes gross manipulation, often a coarse search for a proper setting; `tweak' connotes fine-tuning. If someone is turning a knob on an oscilloscope, then if he's carefully adjusting it, he is probably tweaking it; if he is just turning it but looking at the screen, he is probably twiddling it; but if he's just doing it because turning a knob is fun, he's frobbing it. The variant frobnosticate' has been recently reported.

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