GTK 2.3, And The Emerging File Selector

Anon. writes "GTK 2.3 was released today, and initial (not finalized) screenshots of the new file selector are available here(1), here(2) and here(3). But do remember that the new file chooser is very much a work-in-progress, and the UI is not yet final."

Comments

Frobnicate

[sydb]

From Foldoc.

/frob'ni-kayt/ (Possibly from frobnitz, and usually abbreviated to frob, but "frobnicate" is recognised 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".

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 also been reported.

(1994-12-16)

Didn't really help me...

Re:Frobnicate

[albalbo]

The point of having a new API is you can have a number of implementations that target it - the frob thing is just a dev showing off.

The problem previously wasn't that people weren't able to code a nice new file selector - that's the easy part - but that the API wasn't sufficiently flexible to get enough information from the app to know what files it wanted.

I imagine this one is nice and flexible, so people will be able to code whatever cool fileselector they like and it will just slot it. There's a lot to be said for UI evolution...

Re:Frobnicate

[Bishop923]

What?

Frobnicate is a perfectly cromulent word...

It better be good...

[Gnulix]

Considering the time and effort that has gone into this file selector, the previews of porn pics ought to be able to jump out and give you a blow job...

Re:It better be good...

[Anonymous Coward]

Sorry, no, only windows sucks..

wpw

[Apreche]

it's gtk alright, but those file selector screenshots really remind me of KMail. Are the lines between qt and gtk beginning to blur?

Re:wpw

[Anonymous Coward]

"Are the lines between qt and gtk beginning to blur?"

Let's hope they are.
KDE has a great file selection dialog ...

hooray for usability

[ceejayoz]

http://primates.ximian.com/~federico/news-photos/2 003-10-07-gtkfilechooser.png

Frobnicate?

I prefer not to have to consult a dictionary to use my operating systems, thanks...

Re:hooray for usability

[noselasd]

It just shows that the GtkFileChooser can be extended with custom widgets/items.
The coder of the example the sceenshot is taken from added a checkbox, and labeled it Frobnicate the file.
* It was an example.
* That checkbox is not going to be there in the standard dialog.
* The UI might be somewhat diffrent in the final version

Re:hooray for usability

[passthecrackpipe]

And how, exactly, is the abillity of the random coder to add elements to key parts of what is supposed to be stable, non-changing system real estate an improvement and in-line with good UI design, or even inline with good usability design....?

Re:hooray for usability

[squiggleslash]

Most OSes I've seen generally give the coder some ability to add custom elements to standard selectors. An app might want to add a "Open Read Only" check box. A text editor might want to allow a user to select an HTML document and check an "Edit as plain text" box to ensure the editor doesn't load it as a rich-text document.

It can be a useful thing to do. Whether it'll end up being used properly is ultimately the choice of the programmer.

Re:hooray for usability

[noselasd]

No no. Most filechoosers I've seen provides an API to add custom elements to it.
You might have seen some filedialogs that have a preview of an image besides it ?
And the ability of Joe Random Coder to add elements is rather high since the source
is available and anyone can fiddle with their dowloaded sources, no ?
This was not an example of that though, thisone used the exposed API.

The code is at http://kidcrash.no-ip.com/testfilechooser.c btw, I'm only sorry he had to use a word
like Frobnicate, which seems to boil the brains of the average Slashdot reader..

Re:hooray for usability

[Anonymous Coward]

Slashdot reader? I can't believe people say Linux is "ready for the desktop" and show stuff off like "Ooh this is our new FILE SELECTOR" and then when you take a look at the new file selector it contains jibberish as some kind of geek joke.

You don't have to be a Slashdot reader to have your brains boiled by this Linux bullshit.

good start

[Ender Ryan]

That's a nice start, just put a friggin home button on it and i'll be happy.

I like the idea of having "bookmarks" in my file selector.

Why is this so hard?

[Crayon Kid]

I hope they get it right, already. I bet it's gonna be some bloated kitchen sink that resembles Nautilus in complexity, complete with all kinds of previews and bells and whistles, and that it still won't be able to remember the last used directory.

I'd also put my 2 cents on them trying to catch up with KDE's file selector. No matter what people say, that's not my ideal one. I'm much more fond of the one Mozilla [Firebird] has -- that one is the embodiment of the KISS principle to such extent I'd venture to call it perfect. That's if you agree on the definition of perfect as being "not nothing to add, but nothing left to take away".

Re:Why is this so hard?

[damiam]

I believe the design is loosely based on the Panther fileselector. The Firebird fileselector is nice, but it's ruined by the lack of tab-completion. That's what makes the current GTK selector so nice, and hopefully they'll keep it for the new one.

Re:Why is this so hard?

[alecthomas]

Man, I agree. How frickin hard is it? The GNOME file selector has sucked monkey nads since 1.x and we're now at, what, 2.4? It's not just missing functionality, it actively sucks!

What I really don't understand is that various attempts have been made to add a better file selector (by Ximian, for example), yet they haven't make it into the GNOME core? Why not?

Re:Why is this so hard?

[Anonymous Coward]

> I believe the design is loosely based on the Panther fileselector.

No, it's almost an identical copy of the Windows 3.1 file selector.

Re:Why is this so hard?

[Anonymous Coward]

DRAG AND DROP, people.

Jeez, RISC OS got this right a decade and a half ago.

You don't need a "file selector" seperate from your main file browser.

Well....

[samjam]

We've come a long way since the original stinky X file selector dialogs, but thats about the best I can say about it.

No doubt a lot of honest graft has gone into the design but it stinks, really.

Give me the latest windows shell open dialogs with shortcuts in the left hand side, pop-down directory list and big file selector with alternative views.

The only fault with that windows dialog is the small default size.

But these new GTK dialogs are just true-type anti-aliased windows 3.1 dialogs trying to show the directory tree and file list through two tiny peepholes.

Ugh

Sam

Re:Well....

[Alethes]

Giving them credit for something that is not finalized, I still have to say that I'm disappointed with the direction this is headed. It seems that the file selector and Nautilus both have gone the complete opposite direction as the rest of the GNOME and GTK projects in that they're not simplifying and making the desktop more intuitive and usable. Even if everything else is perfect, the usablity of GNOME will suffer greatly as long as the foundational elements of the file selection and file management are not done properly. Even copying the UI of the KDE and Windows file selectors would be a dramatic improvement over the existing product.

Re:Well....

[gid]

It definitely needs some short cuts icons across the top, like for the user's home directory, the root dir, maybe per user configurable favorite directories, maybe a last used list even, that could be a pulldown, or some kind of small button that fans out a big directory list of previously used directories. And remember the last used directory on a per app basis some how, dunno if that's up to the application or the file selector tho. If you do that, you might not even need the left hand treeview pane, or at least can make it hideable so you have more room for the right hand pane.

Being able to create dirs, rename them, and delete files/dirs from that dialogue would be nice as well. But heck, if you're going to want that, you might as well just make a full blown gnome app and use an already much better dialogue, so I guess keeping the vanilla gtk one simple is a "good thing". Although, maybe a simple and a complex gtk file dialogue box would be nice.

Actually, which makes me think, I wonder if it would be possible to have an application use the simple gtk file dialogue, but if gnome was installed, it would use the full blown, bells and whisltes gnome dialogues if gnome happened to be installed, and do this automatically, so the programmers wouldn't have to even know about gnome, just simply call the gtk dialogue, and the various libraries would figure out the best one to use.

This would ease up the task for developers, so they wouldn't even have to explicitly program a gnome app to get gnome like features.

Re:Well....

[dimator]

I for one love the fucking horizontal scroll bar on the directory tree window on the left. It is not completely annoying, either. The fact that you cant resize that part of the window is also fucking great.

But hey, we can't ignore such amazing UI innovations as having the word "Yesterday" under the file modification date column, instead of yesterday's date.

Honestly, is the guy in charge of this a complete moron? File choosing widgets have advanced far beyond this, why don't they just copy them?

Re:Well....

[cpeterso]

My biggest complaint about the Windows File Open dialog is its fixed size. I have a HUGE monitor at work, yet Microsoft forces me to scroll (horizontally, no doubt) a tiny window to find my files. I wish the File Open dialog could be maximized or at least resized.

Looks like all three of these GTK dialogs make the same design error..

Re:Well....

[Random832]

the windows file open dialog has been resizeable since windows 95. what app are you using? it's possible that your app is reinventing the wheel

Re:Well....

[damiam]

The is no "extra bells and whistles" gnome file selector. Gnome apps use the same widgets as regular GTK apps (this used to not be entirely the case, but it is now).

Re:Well....

[gid]

In gnome 2.4, footprint, run application, run with file, presents a "bells and whistles" file dialogue, with a button for your home directory, desktop, and documents, with rename, delete, and new directory buttons. Other gnome apps use this same dialogue. I assumed it was a gnome thing, but actually, it looks like a gtk thing as normal gtk apps use it.

Kinda weird that the "new file dialogue" takes away these useful features, looks like a step backwards, which leads me to believe I'm missing something here so I should probably just shut up as I probably don't know what I'm talking about.

Re:Well....

[damiam]

The dialog that you're seeing is probably the Ximian dialog, which is a patched version of the dialog in vanilla GTK 2.2. It's basically just the same old dialog from 1998, except slightly prettier and with shortcut buttons. It's included in the Ximian Desktop (obviously), but some distros (Debian, for example) have applied the patch to their own GTK packages.

The new dialog has a much cleaner and more extensible API, does support most of the same features as the Ximian dialog (along with a few extras, like sorting) and will presumably get all the pretty stuff before it's actually released (they've only been working on the GUI for a very short time, most of the design work has gone into the API).

Re:Well....

[some guy I know]

the windows file open dialog has been resizeable since windows 95

Which version of MS-W95 are you using?
I use MS-W95 OSR-B nearly every day, and I have never been able to resize the official open/save dialog boxes.

Re:Well....

[Anonymous Coward]

> I use MS-W95 OSR-B nearly every day,

Maybe that's your problem. The resizable dialogs are in Windows 2000 at the very least, perhaps 98SE.

Re:Well....

[turpie]

I was about to ask where in w2k the dialogs were resizable, because they aren't in IE6 or Office2k. But then I checked in Notepad and found it does have resizable file dialogs.
Whats weird is that MS's flagship programs Office and IE don't use the feature but neglected old Notepad does.

Re:Well....

[Random832]

IE and Office have _always_ used custom file dialogs. (since IE4 and since "always", respectively.) and, i found screenshots (on google, can't find it now) of an early chicago (that is, windows 95 before it was windows 95) beta that had a resize widget on the file open dialog, and that was my basis for saying w95 had it... word in office XP, incidentally, does have resizeable file dialogs (just checked)

Yea, good start.

[Inoshiro]

Getting closer to QT/KDE's fileselector. Once they add home; back; forward; logical parent; new dir; bookmarks (web kind), configure, a direct type path with memory; character encoding; proper MIME filtering; and (my favourite feature) an easy to configure with custom-icons left-hand directory bookmark, which just happens to be configurable per-app that calls the file selector dialog or globally, we'll have seen progress.

Hopefully the Gnome people can build on this.

Re:Yea, good start.

[Phleg]

See, this is why I can't stand KDE. You folks make everything too complicated. When I go into a file selector, I want to be able to clearly see directories, files, a couple of helpful buttons, and not any other distracting shit.

I don't care about setting it up to play a different .wav file for different file types as they're selected, or being able to compile source files in the window by typing alt-ctrl-g with the files I want to compile highlighted, or changing the channel on my T.V. to a show matching the name of the file selected. I just want to select a damned file!

For Christ's sake, your configuration screen for the clock has what, four separate tabs? It's just a fucking clock!

Re:Yea, good start.

[ichimunki]

Personally I enjoy the ability to make a new directory when I'm in a save dialog. That can be handy. But other than that I completely agree. Keep the navigation extremely simple and the basic widget from being too cluttered-- at least make most of the clutter optional and not on by default.

Re:Yea, good start.

[Brandybuck]

Have you actually used the KDE file dialogs? No, it's not simplistic. But it is simple. There is a difference.

Let me bring one up here and describe it for you:

Browser style buttons and path at the top
Quick directory icons on the left (optional)
List view of the current directory in center
Preview on the right (optional)
Filter, filename, OK and Cancel buttons on the bottom

It's very usable, well thought out, and elegant. Any simpler and it wouldn't be usable. As it is now, you can use it solely with the mouse or solely with the keyboard.

Are you afraid of those options? Get used to it, because that's the real world. Go buy a new car and the first thing the salesman is going to ask you is what options you want. And I don't see people getting themselves all in a lather because Burger King says "have it your way."

Re:Yea, good start.

[Phleg]

Are you afraid of those options? Get used to it, because that's the real world. Go buy a new car and the first thing the salesman is going to ask you is what options you want. And I don't see people getting themselves all in a lather because Burger King says "have it your way."

Just because it happens in the real world doesn't mean it's the ideal. Frankly, I'd rather have a car that's more user-friendly than one with a hundred buttons I need to learn, to operate the smallest of things.

And just because I don't want to do something doesn't mean it's because I can't. Sure, I can figure out the options, and I can take time to customize the GUI to be *exactly* how I want it. But frankly, I'd rather put that time into being more productive, and say...working.

Not to mention, this is a completely different area than cars or burgers. Where I'm pretty sure most of America can figure out what foods they like, or how to navigate in a car, most of America is computer-illiterate. When we're trying to get more people into Linux, the last thing we need to do is make it visibly overcomplicated. I far prefer the mentality of the GNOME project, with fewer options but sane defaults.

Let's use the car analogy. Right now, when you get a car, you can get it manual or automatic, with a CD changer, satellite radio, sunroof, etc. They don't ask you if you'd rather have four gears or five, what you prefer for the resistance on the steering wheel, which side you want the pedals on, whether or not you want the gear shifter "inverted", and how you want the dash layed out.

Sure, some people might want them differently, but for 99% of the population, it just doesn't matter. They accept the fact that not every car is perfectly tailored to them, and they learn to cope in a week.

Re:Yea, good start.

[Tailhook]

For Christ's sake, your configuration screen for the clock has what, four separate tabs? It's just a fucking clock!

Just a fucking clock? Clocks are complicated things. Not everyone lives in your time zone, follows your conventions on time (24 hour vs. 12 hour,) cares to see the date as well (or not.) Clocks often have alarms attached to them. Clocks are supposed to be accurate, requiring some method to set them, or even automate the setting of them. Useful clocks also include the notion of "date."

That it only requires four tabs to get all this right is good. I personally live in a complex world where I must deal with people in Europe and Asia, and their various schedules. I need good time tools. Maybe your world is a nice, simple world of Quake servers and MP3 hoarding, but that's just you. Enjoy your hobbies while I keep the lights on and please try not to bitch when you glimpse a little bit of the complexity that is the real world, and it's various clocks...

Thanks.

Re:Yea, good start.

[Anonymous Coward]

Just because it happens in the real world doesn't mean it's the ideal. Frankly, I'd rather have a car that's more user-friendly than one with a hundred buttons I need to learn, to operate the smallest of things.

KDE's file dialog isn't hard to learn, that's one of the nice things about it. It's nicely organized so those features don't get in your way when you don't need them.

What I also like about the KDE file dialog is that I can save/open directly to/from protocols like FTP. I really miss that when using a GTK-app...

Re:Yea, good start.

[unborn]

It is two tabs now. It was a design problem, rather than functionality issue - the functionality is still the same with less clutter.

Re:Yea, good start.

[Brandybuck]

They don't ask you if you'd rather have four gears or five, what you prefer for the resistance on the steering wheel, which side you want the pedals on, whether or not you want the gear shifter "inverted", and how you want the dash layed out.

KDE doesn't ask this stuff either. Get real here!

The KDE file dialog has sensible defaults. You don't have to change anything. You don't have to configure it. You just use it. Is that so hard?

Usability != conformity

Maybe next round...

[kwerle]

Sigh. You can see the problems with it just by looking at it on any system with a good dialogue (OSX, for example).

No favorite folders (buttons/popup). No home folder (button). Image3 shows PERFECTLY that you can't tell the full path in the window without scrolling up and memorizing the directories you're in, instead of left->right and seeing them all highlighted (treeview blows). Look at it - am I in my image directory, or bobs?

There are good file dialogue boxes out there - have been for years. STEAL THEM.

yeah, maybe this is flamebait, but mostly I'm tired of bad non-osx file dialogues.

Re:Maybe next round...

[damiam]

Which part of "initial (not finalized)" don't you understand? The design work on this just started less than a month ago. Give them a chance.

Re:Maybe next round...

[kwerle]

initial (not finalized)" don't you understand? The design work on this just started less than a month ago. Give them a chance.

To me, this looks like just about every other unix file dialogue. Bad.

They're posting mock-ups. There's no reason a mock-up should look this bad.

Again, this is all IMNSHO.

Re:Maybe next round...

[You're All Wrong]

"""
To me, this looks like just about every other unix file dialogue. Bad
"""

Are you sure?

I'd have said _worse_! :-)

I'm not a huge fan of the OSX style, but I'm failing to think of anything better. Some old windows 3.1 applications had decent
home-grown file selection widgets, but they were few and far between, and I can't remember any of them.

I'll know them when I use them. These are the things that either feel _just right_ or feel like a pain in the neck instantly.
Everything apart from Opera 6 is a pain in the neck at the moment.

And to your parent poster - "The design work on this just started less than a month ago. Give them a chance."

??? They _had_ a chance - they chose a design, and they chose a poor design. Past tense. Maybe the only way they can fix it is by _retreating_, going back to basics, reading Tognazzini et al., and performing usability studies (much as I hate them, Microsoft do actually do this), and _not_ by pushing forwards.

YAW.

Re:Maybe next round...

[Tailhook]

yeah, maybe this is flamebait, but mostly I'm tired of bad non-osx file dialogues.

Don't worry, you're not alone. Truth is I was astonished to see that "file open" dialogs are worthy of screen shots. Microsoft had this figured out back in w2k, and OS/X is even better. GTK is right about where win3.x was 10 odd years ago. What is the problem here?

Re:Maybe next round...

[amoe]

Half of these things are unfeasible, since GTK+ is a toolkit and has to avoid having state that would tie it to a given environment.

And tree view with completable boxes is clearly the best approach to file selection. More importantly, the widgets have to be programmer-extensible (like Java's are, IIRC).

Re:Maybe next round...

[kwerle]

Half of these things are unfeasible, since GTK+ is a toolkit and has to avoid having state that would tie it to a given environment.

BS. GTK+ is a toolkit, which is why it should be able to maintain state and use it in any environment it finds itself. What would it possibly have a problem with? Home directory button? If the current context has no home directory, disable the button. Favorite directories? Ditto.

And tree view with completable boxes is clearly the best approach to file selection. More importantly, the widgets have to be programmer-extensible (like Java's are, IIRC).

What on earth are you talking about? Just about every damn file dialogue box written in the past decade has been programmer extensible. What does that have to do with a tree view? Try a browser view sometime - speaking of "clearly the best"...

Damn, just borrow someone's OSX machine long enough to hit cmd-o and see how much better it can be. It's not like I'm suggesting anything new here - just better.

oi

[Deternal]

Seems nice and simple which is good.

Don't need back/forward buttons. To me that is probably the most annoying 'feature' of the windows file selection UI (if it gets in please let it by off by defeault and let behaviour be controlled via the gnome config tool).

The possibility of adding some kind of bookmarks via the gnome config tool would probably be nice. Though home dir should be max for default.

The filetype box should have an other type (ie so it's possible to type in the mimetype if for some reason gnome doesn't know it :P). Obviously linking to Gnome's known filetypes makes perfect sense to.

Also try stuff for the default setup - the windows file selector is not the do all end all of file selectors.

Thats the thoughts flying thru my head when I see this :)

frobnicate

[Tumbleweed]

Dude, that was the BEST PART of the the new design! :)

Refreshing

[turgid]

It's refreshing to see that our Free and Open Source Software elders and betters continue to make such ground-breaking improvements at such a pace. Their innovation knows no bounds.

Looks Frobnicated to me.

[Anonymous Coward]

Lets see. No icons, file type selector on the top (thats bad). No thumbnails (preview pane dosent count), no way to access remote file systems (IO-slave support), no navigation buttons, and still feels too nerdy.

I suggest that the GTK designers go and look at various file dialog designs, and try again.

I like the Office 2000 and KDE file dialogs the best, But get gtk+ out of the 1980's PLEASE.

I say

[Kickasso]

steal a few ideas from SGI's file selection dialog. It's probably the best (and the most underrated) widget that ever existed on a Unix desktop...

MacOS

[Michael.Forman]

Ugh. What a hideous file selector. After installing and taking MacOS X Panther for a spin last night, I'm just amazed how backwards and unprofessional GTK's file selectors are.

If it's not possible to compete with commercial operating systems, why not make a radically different file selector as an option. Imagine a command-line interface where the user 'cd's into the appropriate directory and does a 'put'? Of course, I'm of the mind that Evolution and Open Office should have a "vi" input mode.

Michael.

Another Prototype.

[Anonymous Coward]

I came accross these GTK file dialog mock ups recently.

They look really good.k

Re:Another Prototype.

[waffle zero]

All I see is a dozen shots poorly emulating the deficient Windows file selectors in their many forms (9x, 2000, XP). I would rather read a couple paragraphs explaining the reasoning behind each with a little analysis. A bit of innovation wouldn't hurt either. I'm not asking people to reinvent the wheel, just stop copying a tired Windows look and calling it a masterpiece.

Re:Another Prototype.

[nutshell42]

They're all masterpieces compared to the current file dialog.

I don't expect brilliant innovation I just want (a) an usable file dialog and every "innovative" mock-up convinces me that the only way to get it is to copy Win/MacOS/KDE/etc. and (b) *one* file dialog, currently there are myriads of slightly "improved" versions out there, practically every gtk-application has a different file dialog. And that sucks.

FLTK gets it right

[sunya]

FLTK's file chooser uses the best of all worlds... GTK should probably just adopt it and be done with it.

Re:FLTK gets it right

[Anonymous Coward]

Which wouldn't be a problem except that last time I looked there were no C bindings availiable for FLTK.

Will the new version support ioslaves?

[Anonymous Coward]

The great thing I like about the KDE dialog is that it uses ioslave technology to be able to have transparent access various file systems. This is also why Konqueror has the edge ofver nautilus for power users.

thank you, voice of sanity

[DrSkwid]

those itty bitty little trees are *the* most advanced tech on earth

do you now how long it takes to optimize the blitting to get that to display so quickly

it is not for you to question why some of the most important text on the page is obscured when at least 20% of the canvas is devoted to ok/cancel

scroll scroll scroll your boat, gently down the screen

No, please no!

[Ender Ryan]

I don't want all that clutter, please leave it out of GNOME! :)

Seriously, GNOME, these days anyway, is all about simplicity. There shouldn't be a zillion buttons everywhere that you really don't need. If a particular apps needs that complex a fileselector, it can have it's own.

I like GNOME better than KDE these days simply because when I use KDE, all the buttons on everything are too distracting, and instead of having nice comfortable defaults, there's configurations for everything, but often those configurations are less useful than GNOME's defaults, in my opinion.

Of course, YMMV.

BTW, it's not "easy" that I enjoy, it is simplicity. There is elegance in simplicity when done right, and IMO, GNOME is starting to "do it right." It is simple, quick, and stays out of my way.

Cheers.

Re:No, please no!

[Spy Hunter]

The KDE file dialog is simple to use. It works just like a browser with forward and back buttons, except it has a preview pane and a pane on the left for large icons of frequently used locations, both of which are practically required in a modern file dialog. The dialog works exactly how you would expect it to work. There's no learning curve at all. When features can be added without detracting from usability, then they should be added, because features are good. They help us get our work done faster.

This new GTK file dialog, OTOH, looks like it will have a learning curve. It doesn't work like most other file dialogs, and it doesn't use icons on the files. Plus it has less features than a normal file dialog. What the GTK folks have done here is *remove* features while *decreasing* usability! Exactly the opposite of what you want in both respects. Simplicity is not the end-all of computer interfaces. Usability is what counts. Plus I would argue that this dialog is not simple. For one thing, it contains a treeview, and for another, the main part of the file dialog is connected to the treeview. If you click something in the treeview, the other pane changes completely. This kind of invisible connection is confusing to unsophisticated users, which is the type GNOME is trying to target with all this simplicity stuff.

Re:No, please no!

[damiam]

and it doesn't use icons on the files

Yet.

Plus it has less features than a normal file dialog.

I don't see how you'd know that, since I doubt you've used it. Even if it was true, why would that necessarily be a bad thing? Do you need a full-blown instance of Windows Explorer in your file dialog?

Re:No, please no!

[Spy Hunter]

I do think that a full-blown explorer instance in the file dialog is a good thing, actually. It is an interface for navigating through files that users are already familiar with. There's no extra learning curve, and all the features of the normal file browsing windows are accessible. Why make a totally separate interface for the file dialog? It causes code duplication and it causes confusion among users who must learn two separate interfaces for file browsing. I don't see any benefit to inventing a new interface for the file dialog. In fact, I would love to have the preview window from the KDE file dialog in regular Konqueror windows, and even the quick-access buttons on the side might be nice. Having only one interface to file browsing is the way to go.

Re:No, please no!

[Haeleth]

> Do you need a full-blown instance of Windows Explorer in your file dialog?

I don't know whether I need one, but I certainly use most of the Windows Explorer functionality in my file dialogs on a daily basis. I don't know about you, but being able to copy the old version of a file to a backup directory before saving over it is quite useful, and I appreciate not having to fire up a file manager and navigate to that file separately when selecting File/Save As will open a window in the right directory straight away.

Re:No, please no!

[ahfoo]

I do too. When you've got big huge directories and you were looking at them in a file manager arranged by size or extension it's a bummer if the file chooser doesn't let you go back and find your file in the context that you remember using it.
However, the more detailed view with a few more tabs across the top could also be done as a right click perhaps. That way people who wanted it could have it and other wouldn't know it was there. Also, to be able to resize the thing when you use the detailed view can be a real breath of fresh air. But again, it could be that the dialogue doesn't allow you to resize unless you right click and request a detailed view.

What SGI?

[axxackall]

Any screenshot to explain why you want to do it? Or you expect 90% of /.ers to be familar with SGI UI?

Re:What SGI?

[Kickasso]

I tried to find one on the web but couldn't... sorry, and I don't have an SGI any more to make a screenshot.

Re:What SGI?

[axxackall]

Seems like you are the only one who knows why it's probably the best (and the most underrated) widget that ever existed on a Unix desktop. Well, let it be you little secret :)

it's eXtreme Programming

[axxackall]

In extreme programming frobnication of source code is what the coder does most of the day hoping it will work by the end.

I guess that that gtk programmer occasionally created that file dialog after a lot of frobnication. But he was a smart lazy programmer, so he automated a part of frobnication running it recursively from within the file dialog itself.

I also guess that if no-one will stop the guy then he will frobnicate the code further and eventually it will be AI dialog talking to him.

Heh.

[Kickasso]

If you are so eager to know, I'll find a screenshot tomorrow, okay?

Re:Heh.

[Anonymous Coward]

Indigo Magic File Selector

Re:Heh.

[QuantumG]

that fuckin' sux!

Re:Heh.

[O2dude]

Actually it doesn't.

It has an extremely powerful Drag 'n Drop 'droppocket' feature. So you can drag items in and out of it to your desktop. It has an entry box with filename autocomplete that is linked to the file list above. It remembers the name of the last file you used and it has funky buttons on top of the directory path parts so you can jump to a higher level dir _real_ quick.

As with most things in computerland that are 9 years old, it can be improved with some of todays ideas, but it's still a _very_ good design.

For their next trick...

[avdi]

...The GTK team will invent the scroll bar!

About the file selector

[Random832]

what was wrong with the old one? or maybe i'm remembering a different one, can someone point me to screenshots of the one everyone hates?

Re:About the file selector

[Tisephone]

A lot of applications need specialized file selectors (with previews and such,) the old file selector can't be specialized so it needs to be reconstructed, these reconstructions usually don't take the utmost of care when conforming to GNOME UI/i18n/etc guidelines, and chaos ensues. I think.

work in progress

[Ender Ryan]

This file dialog is purely a work in progress, expect it to be entirely different when it's done.

There were some technical reasons for not changing the file dialog sooner, hence the reason for this even being a worthy announcement.

Re:work in progress

[Spy Hunter]

Well, I certainly hope that they throw this mockup away and start on a new one.

I'm well aware of the arguments over the GTK file selector, and I already know that this was worthy of a Slashdot story. I just don't like the mockup, that's all.

Spawn a new process

[umoto]

The concept of a file dialog is simple, yet it's apparently hard to write a good file dialog. Solution: delegate dialogs to child processes. Let end users replace dialogs they don't like with something better by changing things around in /usr/X11R6/bin.

GTK should install its versions of dialogs in /usr/lib/gtk/dialogs, KDE should install its versions in /usr/lib/kde/dialogs, etc. Then a symlink at /usr/X11R6/bin/choosefile should point to an executable called /usr/lib/???/dialogs/choosefile. A bonus would be that scripts can easily use these dialogs as well.

One thing I didn't take into account is the possibility that two users of a single box prefer a different set of dialogs. Even so, the core of the suggestion stands.

Re:Spawn a new process

[QuantumG]

You could use an environment variable to override the default or look for "chooser" in the path. This is such an obvious concept that it is absolutely rediculous that no OS does it.

Can you disable goofy icons on OK, Cancel buttons?

[Anonymous Coward]

I've always hated this Borland icon nonsense on the OK and Cancel buttons - it looks amateurish. Can you remove them easily (and globally) in Gtk somehow?

"You folks"

[Inoshiro]

I ran KDE 1.1 in 1999. Then I ran Gnome 1.0, 1.2, 1.4, and recently 2.0. Guess what? Going over to KDE 3.2 recently was great. Not only is QT faster than GTK+ 2 (which is mind bogglingly slow on my Athlon XP), I gained usability of file dialogs.

You may think it's complicated, but it's not. It intelligently sizes itself to be a larger portion of my desktop, and the customizable (per app!) quick-jump bookmarks on the left make it so much easier to work with data in directories that are far apart, it's not funny.

Before you knock it, try it. I've ran Gnome for a lot longer than I've been running KDE, but KDE beats the pants off Gnome -- I have no problem admitting it.

Re:"You folks"

[Anonymous Coward]

your athlon must suck,

gtk is wicked fast compared to qt

so in closing, can i buy some drugs from you

Re:"You folks"

[pebs]

Interesting, I was using KDE 3.1 and then switched to Gnome 2.2 (and recently to 2.4) because most of my apps are GTK+ anyways. I found it a bit faster, and also wasn't missing much. Though, Nautilus needs a bit of work. Actually, I'm finding most of my complaints and desired features have been answered in 2.4. Gnome has mostly caught up I think. Konqueror file browser still has a bit of an edge. I will have to keep checking out KDE, but I am a Gnome user for now. They are both nice, you can't go wrong with either.

Why run a desktop environment?

[Inoshiro]

If you're looking for simplicity, grab your TWM and VI via xterm. Live in them all you want.

I want usability. I want to be able to say where the 3 most common dirs I save in KWrite are in a shortcut on the left hand-side, and I want to be able to customize my browse-for-icon dialog to include /usr/share/pixmaps. I want drag and drop from Konq to download files to the desktop intelligently (which Mozilla doesn't do, annoyingly). I want all these great features Mac users have, because the automation means I spend less time working on the computer, and more time working using a computer.

Amiga ARP File Requester

[Anonymous Coward]

I know. Jeez. Why can't they just look at the amiga's early ARP file requester, clone it, and be done? That was amazingly simple, but I've never used another file dialog like it.

OK Cancel buttons are still on the wrong side

[Anonymous Coward]

The Ok and Cancel buttons are still on the wrong side.

Ok on the left and Cancel on the right. This is the norm. Why is it the opposite way. I have clicked Cancel many times thinking it was OK.

Is the person who did this dyslexic?

Do you remember using a Mac?

[yerricde]

Ok on the left and Cancel on the right. This is the norm.

Norm who? On Microsoft Windows brand operating systems, [OK] [Cancel] is the norm. On Mac OS, [Cancel] [OK] is the norm.

Why is it the opposite way. I have clicked Cancel many times thinking it was OK.

If OK is anchored to the corner of a window, it's less likely to move around relative to the window edge (as in Windows) when other buttons are added. If OK is anchored to the bottom-left corner (as in OS/2), it's likely to "disappear" because people in Latin-alphabet countries tend to see the top left and bottom right stronger than anything else.

Look beneath the surface

[timotten]

The release notes say:

GtkFileChooser: a replacement for GtkFileSelection with replaceable backends, many new API features, better user interface (UI is still a work in progress) [Owen Taylor, Federico Mena Quintero]

It's not clear from the changelog what is supposed to be replaceable, but looking at the gtk-devel mailing list (it took me 1 minute), a fine description was posted a couple weeks ago. Applications and users can both provide shortcuts. It can use GnomeVFS instead of Unix file access, so you get access to remote folders and all that...

The reason is Qt..

[QuantumG]

The KDE file selector? What? It's just the Qt file selector man? Almost everything in KDE is just Qt with lipstick on. Qt is a brilliant product and KDE is riding the wave. When you consider how much excellent stuff they've got to work with you see that they're not really putting in any more work than the GTK team.

Fix it

[nuggz]

Yes, I keep making this mistake.
By reflex I just hit the other, it was really funny when I hit the reboot button on gdm, said "oh no" and proceeded to hit "OK" instead of cancel.

Not bad looking but

[LWATCDR]

I did not see anyway to change the view I tend to like to use the details view in windows. It would also be useful to beabile to sort by date or name and to have the option of setting the view for the applications or for the entire desktop.
just a sugestion.

And there was much rejoicing

[Anonymous Coward]

because the old GTK file selector looked and felt like something from Mac OS 6. Gnome and KDE are pretty close in most places; this isn't one of them.

frogging

[SolemnDragon]

sometimes referred to as frogging a switch, at least on one campus i know.

Screw the file selector

[Anonymous Coward]

The COLOR selector is terrible. Does anyone know if they're planning on offering different versions of it, at least? Or if a prettier one is in the works?

Re: 2000 and 98SE are not 95

[some guy I know]

The resizable dialogs are in Windows 2000 at the very least, perhaps 98SE.

The earlier poster wrote "the windows file open dialog has been resizeable since windows 95 ".
Neither MS-Windows 2000 nor Windows 98SE fall into that catagory.