A little bit ago GTK's got a new file dialog that shows buttons for the current directory path. There has been a lot of talk about what people didn't like. So much so that in the latest Gnome version they have included a button that will bring up a line edit so you can put in a path.
A different way of showing the current path is to put buttons with menus inside of a editable combo box. One button for each directory in the path. One problem I personally had with GTK's solution was how the buttons didn't look related to each other, but by putting them inside of a combo box it looks like a single widget.
When the mouse moves over the button it is painted (like in toolbars). When you click on the button it takes you to that directory and if click on the arrow it will show all the directories inside the selected directory.
Clicking on the white space on the right hand side or on the folder image on the left will turn the line edit into a normal editable path.
This idea (hiding the line edit) is not new, you can already see variations of it in Gnome, Vista, OS X, and Dolphin. I don't know what is the best solution and right now am between the above way and the way that OS X does it. During akadamy I plan to meet up with the usability guys to get some real evidence about what is better. If the OS X way is better don't worry you can always pull up a line edit to enter a path by hitting the '/' key.
P.S. The above application is just Qt 4 and doesn't link to KDE, but notice that Qt will pull the current KDE icon theme (Kids for the first two screenshots) to get the folder icon. A new feature in 4.2
Syndicate Blogs
How about the web approach?
Why not use the web approach of separating different directories with '>'?
So above would look like "{rooticon} > home > ben > dev".
Clicking anywhere between two '>'s could emit a signal which could bring up that cool popup menu. Have a model coordinating what is displayed in both widgets and the code should stay pretty clean.
Cheers
Ben
itunes store
Yah, I have thought of that, check out in iTunes the store "location" widget. It is very similar to that.
Dude!
Great to see KDE is also starting to implement such widget. I've downloaded Vista rc1 recently and it was one of the (relatively few) features I really loved.
I'd love to see this in KDE4/konqueror. So far the Vista approach (the way you describe it) seams to work most intuitive.
Very Interesting
This is a very interesting idea. I too have never felt comfortable with the Gnome solution because a line of buttons doesn't relate to a file path for me.
I am however left with a question: What appends when the URL fills the entire widget? If there is no empty space at the right end of the widget how does one manually enter a path?
long path and changing the question.
I am however left with a question: What
appendshappens when the URL fills the entire widget? If there is no empty space at the right end of the widget how does one manually enter a path?Aaron was working on a "clear" button for Edit widgets. He moved it inside, but I forgot where, left or right. (hmm... left is already occupied by site logo / mime icon) So, assuming that goes into UrlEdit widget too, we have a solution for clearing the field to type. Clearing the field automatically puts the cursor in the beginning of the field.
Editing could be almost as simple. Go to the place on the path you will use as a base (by pressing it). UrlEdit widget "path element" button can behave in the way similar to "clear" button and put an active cursor after the slash of the selected element.
There you can start typing and get autocompletion, or move cursor left one step (to end up on "slash") and press down button to view the full list of "path elements" for the next section. This way one could use "left" and "down" buttons to "type" the whole address line.
Demn, my dreams are soo cool, I want that UrlEdit widget now!
squeeze
Never tried it myself, but what happens in gnome in the same scenario? In vista at least the left most items disappear and they show up in the first menu list.
gnome
it's just the same behaviour IMHO!
Baaad kitty.
There was a blog here on planet about reducing the number of IO slaves, namely, going away from media:// because of the complexity this introduces to all apps and confusion due to differently-rooted access point to the same thing.
I find your blog entry and Gnome's, Dolphin's and OSX's way of doing things (and lets face it, it all started with OSX) continue to propell the same confusion-laden approach.
In all of the methods presented, user is told that it is ok to separate the point on the path with anything he wants: triangles, spaces, slashes, etc.
Triangles and things are ba'ad, M'kay. You'll have ppl asking you in the bug reports where is the button to enter a triangle. They'll be entering spaces between the slashes. All manner of bad things will come when KDE joins the "bad design and it's copy-cats".
On of the awesome things about unxy-platforms - local usrl look almost exactly similar to web urls. Because of that, I can easily mix them and that, in part, what gives KDE "network transparency" - all path look fairly similar, file:// or media:// or smb://...
Now, my suggestion:
1. "Visually" keep the slashes between the path sections and turn THEM into down-arrow buttons when one hovers above.
2. Have the courage to "pad" separators with spaces as little as possible. Besides giving a wrong idea, this also produces an ugly visual effect when length of the path jumps upon the editing mode switch.
Other, rather subjective, and completely unimportant suggestions.
1. Have the separator pull down button be either attached to NEXT item on the path or completely separate from the surrounding paths. The presented method somehow gives the ides that home folder is on the same level as anders, ben, kdetest, qt, windows user folders.
2. Second the previous comment about making path element links and not buttons This keeps the behavior consistent with other web-related activities.
3. Love, love love the part about "clicking on empty space gives you edit box. It is very consistent with web browsing behavior and really cuts on useless buttons.
4. Completely agree about the need to keep the path in a location-looking box. Again - consistency with all other browsing experience.
I hope changes of this kind are submitted and throughly reviewed by parties that be. Universally usefull Location field is one of the selling point of KDE. Let's not try to replace it, but, enhance it. Make it look like the same ole path suddenly just became a much more rich experience. This way all parties - old-timesr and newbies - will be very happy.
"In all of the methods
"In all of the methods presented, user is told that it is ok to separate the point on the path with anything he wants: triangles, spaces, slashes, etc."
Interesting, your are the first person to bring up that point.
"1. "Visually" keep the slashes between the path sections and turn THEM into down-arrow buttons when one hovers above."
Yup, this goes with the next one.
2. Have the courage to "pad" separators with spaces as little as possible. Besides giving a wrong idea, this also produces an ugly visual effect when length of the path jumps upon the editing mode switch.
I don't need any courage, just haven't gotten around to doing it.
"1. Have the separator pull down button be either attached to NEXT item on the path or completely separate from the surrounding paths. The presented method somehow gives the ides that home folder is on the same level as anders, ben, kdetest, qt, windows user folders."
I noticed that Vista did that, but I didn't pick up why. At least the way that Vista does it it looks wrong, I couldn't put my finger on it, but it was offset at a odd pixel offset.
"2. Second the previous comment about making path element links and not buttons This keeps the behavior consistent with other web-related activities."
Hmm, guess that would require some usability testing. It might be an ok idea, it might be not, I honestly don't think it would make much of a difference.
"3. Love, love love the part about "clicking on empty space gives you edit box. It is very consistent with web browsing behavior and really cuts on useless buttons.
4. Completely agree about the need to keep the path in a location-looking box. Again - consistency with all other browsing experience."
Thanks
"I hope changes of this kind are submitted and throughly reviewed by parties that be. Universally usefull Location field is one of the selling point of KDE. Let's not try to replace it, but, enhance it. Make it look like the same ole path suddenly just became a much more rich experience. This way all parties - old-timesr and newbies - will be very happy."
Well in Konq the web browser I see no reason why you would want this. In Konq the file manager maybe. Everyone can argue all day long about what they think is better, but like I said I plan on getting some usability testing.
How does OS X do it?
Any chance you can add a screenshot for OS X for those of us not familiar with it?
I quite like the dolphin approach, but not having to click a button to type manually. Visually I think perhaps a normal looking path entry box with clickable directories underlined (like hyperlinks) might be better. As - generally - more of a keyboard than a mouse user, I prefer to have it easy to just type the path so I detest the current gnome method (I recently added kde-dialogues to the Gimp via something on kde-apps to get round this). I appreciate of course that other people do things in different ways so I'm sure the usability folks can give you a lead on this.