GTK 2.3, And The Emerging File Selector 99
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."
Frobnicate (Score:5, Informative)
Didn't really help me...
Re:Frobnicate (Score:2)
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
it's eXtreme Programming (Score:3, Funny)
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.
Re:Frobnicate (Score:2)
Frobnicate is a perfectly cromulent word...
frogging (Score:2)
It better be good... (Score:5, Funny)
wpw (Score:1)
hooray for usability (Score:2)
Frobnicate?
I prefer not to have to consult a dictionary to use my operating systems, thanks...
Re:hooray for usability (Score:2)
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 (Score:2)
Re: (Score:2, Insightful)
Re:hooray for usability (Score:2)
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 t
frobnicate (Score:2)
good start (Score:3, Interesting)
I like the idea of having "bookmarks" in my file selector.
Yea, good start. (Score:5, Insightful)
Hopefully the Gnome people can build on this.
Re:Yea, good start. (Score:2)
I don't care about setting it up to play a different
Re:Yea, good start. (Score:1)
Re:Yea, good start. (Score:1)
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 mous
Re:Yea, good start. (Score:2)
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
Re:Yea, good start. (Score:1)
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
Re:Yea, good start. (Score:2)
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."
"You folks" (Score:2)
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 n
Re:"You folks" (Score:1)
Re:Yea, good start. (Score:1)
No, please no! (Score:2)
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 co
Re:No, please no! (Score:2)
Re:No, please no! (Score:2)
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! (Score:2)
Re:No, please no! (Score:2)
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 str
Re:No, please no! (Score:2)
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 ca
work in progress (Score:1)
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 (Score:2)
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.
Why run a desktop environment? (Score:2)
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
Why is this so hard? (Score:5, Insightful)
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? (Score:1)
Re:Why is this so hard? (Score:1)
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?
The reason is Qt.. (Score:2)
Well.... (Score:5, Insightful)
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.... (Score:3, Insightful)
Re:Well.... (Score:1)
Re:Well.... (Score:1)
Re:Well.... (Score:1)
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 her
Re:Well.... (Score:2)
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
Re:Well.... (Score:2)
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?
thank you, voice of sanity (Score:2)
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
Re:Well.... (Score:2)
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.... (Score:1)
Re:Well.... (Score:2)
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.... (Score:1)
Whats weird is that MS's flagship programs Office and IE don't use the feature but neglected old Notepad does.
Re:Well.... (Score:1)
Re: 2000 and 98SE are not 95 (Score:2)
Neither MS-Windows 2000 nor Windows 98SE fall into that catagory.
Maybe next round... (Score:5, Insightful)
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... (Score:2)
Re:Maybe next round... (Score:3, Insightful)
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... (Score:1)
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
Re:Maybe next round... (Score:2)
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... (Score:1)
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... (Score:2)
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
oi (Score:1)
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 g
Refreshing (Score:1, Flamebait)
I say (Score:2, Interesting)
What SGI? (Score:2)
Re:What SGI? (Score:1)
Re:What SGI? (Score:2)
Heh. (Score:1)
Re:Heh. (Score:2)
Re:Heh. (Score:1)
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 _ver
MacOS (Score:5, Interesting)
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. [michael-forman.com]
Another Prototype. (Score:2, Informative)
They look really good.k [wanadoo.nl]
Re:Another Prototype. (Score:1)
Re:Another Prototype. (Score:2)
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 (Score:3, Insightful)
For their next trick... (Score:2)
About the file selector (Score:1)
Re:About the file selector (Score:1)
Spawn a new process (Score:2)
GTK should install its versions of dialogs in
Re:Spawn a new process (Score:2)
Do you remember using a Mac? (Score:1)
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 p
Fix it (Score:2)
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.
Look beneath the surface (Score:3, Interesting)
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 [gnome.org] 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...
Not bad looking but (Score:3, Insightful)
just a sugestion.