GNOME Bugzilla – Bug 136541
poor discoverability of text entry box in filechooser open dialog impairs accessibility
Last modified: 2008-02-10 22:00:52 UTC
The new filechooser open dialog lacks a text entry box by default. This is less than ideal for disabled users using software like GOK or Dasher, or a hypothetical speech to text system. In these cases, navigating through a combination of buttons and a table is significantly harder than simply being able to type in a pathname. Possible easy fixes would be either to add the text entry widget back, or alternatively include a button to provide the same functionality as ctrl+L currently does. Other vague off the top of my head ideas include doing this only when accessibility is enabled if it would be considered too much of a usability issue otherwise, but that sounds fairly crack-like.
A pop-down (up?) button for the entry field sounds like a reasonable idea to me; it could be small and inobtrusive, but advertise its name and description via ATK so that it could be found by ATs and reported to the user.
just noting the obvious - this suggestion (pop-down button) would be a UI change and therefore would require an exception to UI freeze in the stable gtk+ series, or would have to wait for gtk+2.6.0
I think this could be a candidate for promotion to AP2, depending on user feedback/etc.
Would it help if the accessible for the dialog (or widget) provided AtkAction with a "enter path" type action that brought up the dialog? Or is that not useful with current ATs?
owen: that would help - but it would require a convention for such an action name among ATs, since there's no inherent semantic content in an action name (ATM ATs recognize things like "click", "activate", "menu", etc. as actions, so this would be a new naming-convention). But it would indeed be an improvement over the current situation, as things like GOK tend to expose the first/default action for objects that implement AtkAction; if this were the default AtkAction for FileChooser then GOK would more-or-less work (by popping up the entry field when GOK users activated the appropriate Gok key). Having a "popup" button in the tab sequence would be arguably better for blind users though, and equivalent for GOK users, without requiring the naming convention.
*** Bug 142217 has been marked as a duplicate of this bug. ***
Copied comments from Bug 142217 which has been marked as a duplicate of this bug: Reporter: uridavid@netvision.net.il (Uri David Akavia) I would like to have an option (gconf option or otherwise) to have the location bar as a permanent part of the file selector, similar to the previous GTK+ version. This location bar should behave exactly like the floating location box that opens with Ctrl-L. To be more specific - when you start writing, it will complete the file as much as possible. The files shown and/or the directory current will update when you press Enter (which currently closes the box). The permanent location bar should also have the same regex ability as the floating box. When the location bar is "switched on", I would like the focus to jump directly to this location bar, when the file selector is first opened. Rationale: Similar to Windows UI (I believe that this is similar to Mac, but I can't verify), allowing people to adapt easily. Similar to previous GTK+ UI, likewise. Intuitive, since if it appears it is far easier to find it, than using Ctrl-L on a selector without it. Allowing people who were in love with the powerfull shell-completion of previous GTK+ to use it. Personally, I (almost) always open files using Ctrl-L and shell completion. Having the location bar permanent would really make it simpler for me. This was discussed on Gnome-UI list, the last message was http://mail.gnome.org/archives/usability/2004-May/msg00000.html. Since there were no comments exclaiming (and explaining) that this will bring GNOME down in flames, I take it as indicating a lack of strong resistance (if not acceptance, since some messages seemed to like it).
*** Bug 143598 has been marked as a duplicate of this bug. ***
We need consistency. If applications hide portions of the dialog box, Gnome should show them collapsed, not missing. This is a screenshot of what I see: http://bugzilla.gnome.org/attachment.cgi?id=28278&action=view The collapsing could work like "Browse for other folders" in the save as.. dialog. I also should be able to type in, for instance "/usr/local/" in the text box, and it'll browse to that directory.
This is my problem with the lack of a text entry box by default in the gtk file selector. I have been involved with gtk apps for a long time. One of the things that I showed off to my dad when showing off my gnu/linux software to him was the magical tab completion that the smart developers writing my software had included. He thanked me for showing him this powerful keystoke thingie. He was greatful. Now something has happened and there is a special key stroke to get the text entry? On the gimp developer list, they made it sound like it was a trade-off for a really useful save dialog; these dialogs should be unrelated. Can someone explain to a linux user what happened?
Please put the text box back by default, or at least make it more obvious how to find it. It is an enormous regression from the user's point of view to upgrade to 2.6 and then have a commonly used feature disappear.
Another problem with the popup dialog for typing filenames is that the dialog is centered on the filechooser itself, thus obscuring the list of filenames. It can be convenient to be able to see the list of files while typing in a filename. For people who use their keyboards more than their mouse, the new fileselector is a huge step backwards. The old one had a location entry which was focused so one could just hit C-o and start typing. This convenience has been sacrificed in the name of accessibility. A help button in the fileselector would also be appropriate considering the complete lack of discoverability of keybindings.
Yes, the lack of a text entry box by default is disturbing for those of us who never use the "mouse features". Indeed, I'd like a way to get rid of the other parts of the dialog -- they merely slow things down (enormously, it seems). Another problem with the new pop-up text-entry box is that it's far slower and seems to behave much less consistently than the old one, I guess because of the complicated and dynamic presentation of the completion list.
Jens said: "This convenience has been sacrificed in the name of accessibility." Actually, the accessibility team didn't have much input into the new file selector - I think it's a step backwards for accessibility too!
*** Bug 145167 has been marked as a duplicate of this bug. ***
*** Bug 148839 has been marked as a duplicate of this bug. ***
I consider this dialog a regression in ALL aspects compared to the FileSelectionDialog. 1) The location entry should be there, always. It's generaly faster to write part of the name, than to find it in the list and click on it. 2) The different forms for open and save are confusing. They are two completely different dialogs for something that could be the same. So it should be the same (once location entry is included, of course). 3) Bookmarks do not balance out the loss of ability to entry name as text and tab-completion. They are broken. 4) In the location entry, tab should cycle between the possible completions.
Apologies for spam-- ensuring Sun a11y team are cc'ed on all current a11y bugs. Filter on "SUN A11Y SPAM" to ignore.
In lack of a voting mechanism in gnomes bugzilla, here's my vote as comment: +1
*** Bug 159815 has been marked as a duplicate of this bug. ***
Just to add to the points on how annoying the lack of the text dialog is. Not knowing about ctrl-L until I came across this thread, I spent a while cursing at the thing, especially with automounted NFS file systems: they don't even show up in the hierarchy until you've accessed them, so there is no apparent way to get at them without separately mounting the file system.
1. Were the folder names bold, that would be nice. 2. I have many folder under my /mnt directory, because of many mounting point what I have (cd, dvd, 3 partitions, usb pen, floppy, nfs directory and 8 windows folders shared across the LAN, 1 directory where I usualy mount the .iso files( using the loopback device)). This should not be unusual. However I have only 3 directories (the 3 partitions) what are always mounted. (the cd, dvd, usb pen and the others are just permanently mounted) So my open dialog is very confusig because of the many mounting points. And I cant remove the mounting points from the list. Whenever I add folders to the list, accessing them requires me scrolling down. This is unwieldy. Instead of being an advantage, this just equals for a waste of space, as the open file dialog overbloats. Best regards, Khiraly
I agree (and vote for it), that we need the text entry back, without mentionning again the terrible accessibility and automount problem; you can't paste anymore a link that was send by email and you also need to make lot of mouse gesture to select a file when traveling in crowded directory hierarchy.
*** Bug 163224 has been marked as a duplicate of this bug. ***
*** Bug 163654 has been marked as a duplicate of this bug. ***
This is my proposal: 1. The text entry is always there, and the cursor gets placed into it when the dialog comes up. 2. By default, the text entry hasn't got tab completion or anything like that, because non-sophisticated users would easily get confused by that. 3. There is a checkbox named "sophisticated usage" or something like that. By default it is disabled. When enabled, the following is valid: a) If the letters typed by the user are non-ambiguous, the file name which the user is likely to want is shown below the text entry and can be reached by pressing key-down, Enter. b) The files in the file list match the pattern in the text entry. c) There is another checkbox or drop-down list, controlling what the word "pattern", mentioned in (b), means. You could even integrate finding files by regular expressions (though that may be overhead). 4. There is gconf key "sophisticated_file_chooser", controlling whether the checkbox mentioned in (3) is enabled by default. The default value for sophisticated_file_chooser is false. What do you think?
I've got to correct sth. in my previous post. 3a. The text entry works the same way the current "Ctrl-L" dialog works.
Tab completion is a relatively standard Unix feature. It should be available so that new users can learn about it and become happy, proficient users instead of continuing to be stuck as new users. A "sophisticated usage" checkbox is unnecessary and just more confusing.
Well, I would be happier about such a checkbox than about the current state: no text entry, no tab completion or similar feature at all. Thought about it as a trade-off. By the way, who is going to decide issues like this? Is there any official policy Gnome is acting on?
tab completion conflicts with tab keyboard navigation.
It is better to refer to it as "Auto Complete" rather than Tab Complete because Tab complete is only an implementation detail and other keys can be used instead. I think the problem is that there are users and developers with different goals trying to take the file chooser in different directions. There are those who want to kill off the file chooser entirely and encourage users to use the file manager or drag and drop. Unfortunately for them some users will always need the Location Text Entry for accessibility. Others want a more complicated File Chooser with everything in it but those wanting to get rid of the file chooser see this as being completely redundant. I think Apple have managed to get this right. The average users is not particularly likely to use the File Chooser over clicking a file and opening it from the file manager. Those who are most likely to use the File Chooser are those who want/need the poweful Location bar, so Apple shows it first but still allows the dialog to expand to a more complex interface. I'm inclined to think Gnome currently has it a little bit out of order and that the simple but basic Location text entry with a browse button and an expander widget should be the basic File Chooser.
Sounds sensible to me, too. Something I'd like to complain about, supporting the addition of a text entry: The current dialog doesn't show the file name in Unix notation (e.g. /home/me/example). However, something the Unix newbie learns first when starting using his workstation is that his home directory is /home/me, and that a file called example situated in his home directory would be accessed by the string ~/example. He doesn't recognize this in the Gnome file choosing dialog. Pedagogically a bad experience.
GTK 2.6 provides typeahead find, so the accessibility issues are dealt with. I'm closing this bug. Please reopen under a different title if it's still a problem.
Matthew, why do you think the typeahead find deals with the accessibility issues? PLEASE reopen this bug, since I'd just reopen under the same name.
There's an identifiable widget that will take text entry events, which I thought was the issue under discussion. Are there further problems?
I thought the new one still doesn't act like a GtkEntry but I haven't run gtk+ 2.6.0 lately.
Hmm. What semantics do we want from the widget?
This bug isn't about text entry widgets, or typeahead find versus tab completion, or any other trivial implementation details. It's about the gtkfilechooser widget and the fact that users do not have an obvious way of typing in filenames/paths. No one really cares if autocomplete is done automagically or if it needs to be explictly invoked by pressing tab. My preference is for autocompletion ala the entry box in the ctrl-l subdialog. It will not confuse users since that has been the default functionality in every major web browsers' location bar for several years now. The 'tab' key isn't important since automatically doing the completion, and in gui enviroments users are conditioned to press the 'end' to jump to the end of the line in an entry box. The simplest solution is to simply move the entry widget and its accomapning "Location: " label back into the main gtkfilechooser widget. The gtkentry is only 25 pixels tall, and an entry box has been visible by default in file choosers since the advent of the WIMP interface. The accessability/usability issues are mainly about the hiding of expected and desired functionality. The problems with the current "ctrl-l design" of gtkfilechooser are numerous. First, there's no way for a user to know that this functionality exists. (I only learned about it thought this bug report.) Second, there's the whole aesthetics issue of having a popup dialog requiring an additional popup dialog that contains only 3 controls, two of which are "open" and "cancel" buttons. Third, once the ctrl-l subdialog is up, it requires clicking two different "open" buttons to actually open the file. The first one inside the subdialog, and the second inside the main gtkfilechooser dialog. And finally, the ctrl-l dialog only works for directories not full paths to files. If the user types in the full path to a file say "/home/user/dir/file" and clicks "open" in the ctrl-l dialog, the file "file" isn't actually opened. Instead the main gtkfiledialog switches directories to "/home/user/dir" and the user now needs to click on the gtktreeview row for "file" and press "open" again. This is incredibly confusing even to advance users since "open" doesn't actually "open" anything. I'm sorry that this sounds like a bitter rant, it's just that the gtkfilechooser was released with several obvious usability issues and IMHO should have been laughed out of CVS the moment it was checked in. This bug has not been fixed by any stretch.
*** Bug 165961 has been marked as a duplicate of this bug. ***
I have to agree, this is pretty badly broken. A vivid example of this is when this dialog is instantiated as part of "Choose Helper Application" in Firefox. Most helper applications are in /usr/bin, which has a massive amount of files. It takes 45 seconds on a reasonably fast machine with a reasonably typical install of FC3 to load the entire contents of that directory. In the meantime, the dialog is pretty unusable. I would have had no idea to try typeahead or Ctrl+L had I not known to Google for "file selector".
*** Bug 168220 has been marked as a duplicate of this bug. ***
I think we'd better reopen this bug based on the many duplicates being filed against the 'fixed' version of the widget...
Rob: Not only that, but the fact that the dialog becomes unusable while loading the file contents is a usability issue in and of itself. The UI shouldn't become unresponsive like Windoze Explorer.exe and perhaps there is a loop there without any yielding back to the OS. Anyone know for sure?
See bug 166601 which discusses performance of the file chooser on large directories.
I strenuously agree that some form of direct path/filename entry needs to be put back into the file chooser. Like others above, I didn't know about Control-L until I started seriously Googling on this issue - but even that is an inadequate alternative; the path entry box needs to be there by default. Mousing folder-by-folder through a 160+GB filesystem hierarchy is not my idea of fun.
*** Bug 300273 has been marked as a duplicate of this bug. ***
*** Bug 301760 has been marked as a duplicate of this bug. ***
*** Bug 162213 has been marked as a duplicate of this bug. ***
This is a reply to Owen Taylor's comment (#5) in 162213. "Global bookmarks" or whatnot are *not* a solution to the automount problem. There are some things that simply cannot be done in any general way without a text entry box. The fact that there's such strong demand for a visible text entry box (without the ctrl-l hack) should suffice. Automounts come in many flavors. In addition to the simple case of an enumerated set of directories like /home, there are other things such as /net, where there's no practical way to enumerate all the entries, and no way to visit a particular filesystem *without* actually accessing the virtual directory in question. Why won't global bookmarks work? Think about a large company, where many different groups export automounted directories of different types. Aside from the fact that the number of global bookmarks would be unmanageably large (tens of thousands of home directories across the company, thousands of project directories, /net for the case where the local system administrator isn't being very cooperative), there may not even be a single system administration group that knows all of the exported directories! In the case of /net -- where different organizations may maintain DNS servers serving particular domains, even inside a company -- there certainly won't be a system administrator that has any hope whatsoever of maintaining something like this. Even in the case of something that can be enumerated (such as home directories), would you seriously suggest that someone should scroll through tens of thousands (literally) of entries to find the one they're looking for, when they know the name and can simply type it in? And saying "well, they could type ctrl-L in this case" just makes for petty nuisance. Please don't try to argue that networks shouldn't be set up that way -- they are, and it's something we all just have to live with. Where I work, I frequently have to cross domains for any number of things. In large companies, it simply is not practical to set things up so that there's a compact, centralized namespace. Nor is it possible to say "certain users will only access certain things" -- people work across a lot of different group boundaries, with different administration policies. As for "What are you going to do, give them a sheet of paper with the paths written on it?" while generally I don't favor paper for this purpose, I might well cut and paste a path from a web site or an email message. Or in case of a directory I access frequently, I simply commit it to memory, just like with some URL's where it's easier to type the URL than to pick it out of a list. My own use case -- the only GTK+ app that I use regularly where I use the file dialog -- is in the GIMP, in a much simpler environment. I frequently generate an image and want to look at it in the GIMP. I'm always generating the same filename, /tmp/b.pnm, and I might do it tens of times in a single session. I can type that faster than I could possibly scroll through a list -- ctrl-o b.pnm <enter>. The way it is now, I have to type ctrl-o ctrl-l b.pnm <enter> <click>. Different people have different issues, but it all boils down to the fact that a lot of people are just plain used to the filesystem, and used to having entry boxes in file choosers. Trying to force people into a certain way of working -- which as I explained above, simply does not cover in any reasonable way some important cases -- just leads to frustration. Upshot: please restore the text entry box forthwith, and done with.
*** Bug 305079 has been marked as a duplicate of this bug. ***
Please ignore the whole discussion above; it has gotten just too long. The main argument against adding a "_Location" button is that it clutters the dialog. I just figured out that we can put such a button on the left of the path bar, and it would not clutter things. It would be accessible with Alt-L as per its mnemonic, and also through Control-L as things are right now. This would be an improvement for blind users and other users of accessibility devices.
What exactly is this going to look like? Is it going to pop up another dialog? Is there going to be an entry field I can just type into without having to do anything special? If there is going to be a separate dialog just for the path, am I going to have to click OK twice (once on the entry dialog, and once on the main dialog)?
Federico: Your suggestion in comment #51 sounds good to me, it seems like more-or-less what I've been requesting all along. As I said in comment #1, this button need not be big and obtrusive, it doesn't even need an onscreen text label (some sort of icon would do, with onscreen placement near the path bar as a contextual hint for sighted users). If we make the "accessible-name" and "accessible-description" reflect its use (description can also be the tooltip text), then the problem is solved for blind users (provided it is in the TAB sequence, which is important), gok users, and also for mouse users who may be perusing the dialog via mouseover and might be looking for a way to enter a text path. I'd suggest something like "Enter Path" as the 'accessible name' and perhaps "Enter a file or path name" as the accessible description.
Instead of having a hidden Location bar couldn't we put it back in place of the current name bar/text entry, on the basis that the any simplcity gain has been outweighed by the other complications?
I don't mind having a button, but something else should work as well: starting to type anything beginning with / or ~. And then there'd be no need for a separate dialog.
I don't think that a location entry box clutters the dialog since as I said in comment #38, it's only 25 pixels tall, and has been in file choosers for 30 years. But whatever. I REALLY don't like the idea of subdialogs. It think they're ugly and the double-ok is really perverse and confusing. What's really confusing about the current subdialog is that when you type in a full path to a file, it merely switches the filechooser dialog to the directory containing the file, rather than openning the file. That confused the hell out of me when I first saw that, and has been stated before leads problems when you're trying to select a file hander from '/usr/bin'. All of that said, I think instead of an unlabeled button being tucked away in a corner, it would make more sense to use gtkexpander, since hiding/revealing widgets is exactly what gtkexpander is meant for. The gtkexpander label would say something like "pathname" or the like. You can default the expander to close, but a gconf key that would enable the expander set to open would be ideal. Also the expander should be hotkeyed to ctrl-l, just like the subdialog is now.
One other thing, the concern I have with using typeahead find for directory tree transversal, is I don't understand how it would work. First, it isn't very obvious (but that's true of typeahead in general), but more sersiously it would require a break with the current typeahead behavior. When you type a character that isn't in the list, the search fails. To enable tree transveral, the behavior would have to change to "if the character isn't in the list, then fail, but if it's a / then we're walking." I don't like a widget having two different behaviors. Widgets should be consistent across all instances. Second, how would typeahead work? Would typing immediately switch directories and reload the chooser with the contents of the new directory (assuming a unique directory is found), or would the directory only be changed after "enter" is pressed? What happens when you type in a full path? Does typing enter merely close the the typeahead find with the proper file selected, or does it actually open the file? If typeahead find is ultimately chosen, which I don't like nearly as well the gtkexpander idea in comment #56, it doesn't really bother me either way if a two "enter" key presses are required to activate the chooser. In fact, I would think it would make more sense to simply obey the current typeahead behavior for "enter". If that means closing the typeahead without activating the unique file, so be it. Two key presses are much easier to perform, than two "ok" button clicks, since you don't have find the the button you want. :)
Navigating during type-ahead (also known as interactive search) is bug #305385. Having to press Enter twice when you use the location dialog is bug #158423. /usr/bin being slow is bug #166601, bug #302322, and bug #154394. "/" and "~" is bug #153213.
Just as long as the typeahead is consistent between the filechooser and the other widgets. That's all I'm concerned with.
*** Bug 305483 has been marked as a duplicate of this bug. ***
Just to bring this back to attention for gnome 2.14: I have three issues with the file selector dialog: - The user should be able to choose between the buttons bar or the location bar in its place (so a text input widget at the top of the dialog where the buttons are now, I guess you developpers can imagine how it should look: a bit of auto-completion, etc...). I think it is obvious by now that not every user loves the buttons. I don't mind having the buttons as default, just give me a gconf key or otherwise plz! It's kind of like with spatial nautilus -- I'm not using it ;-). - There should be a "move up one folder" button like in nautilus, left of the other buttons. Because if you want to move to "../" you have to click the button of the previous folder AFAIK, but this button's position ofcourse keeps changing every time, so this wrecks my routine. - The dialog's window size should be bigger, or at least it's size should be remembered so that if I resize it once it keeps that way. Now it's way too small, so I always only see one button (do I have long dir names or what is my problem?) so it's even harder to go up one folder. At least one of these three things should be implemented, and preferrably all three. They must be like one hour work for a descent gtk programmer. And I don't see a reason not to do this if this get's hundreds of otherwise-supportive users/fans of your back. So why don't we (do it)?
*** Bug 312296 has been marked as a duplicate of this bug. ***
Any idea when this problem will be fixed?
>- The user should be able to choose between the buttons bar or the location bar >in its place (so a text input widget at the top of the dialog where the buttons >are now, I guess you developpers can imagine how it should look: a bit of >auto-completion, etc...). I like this idea, and I was going to suggest more or less the same thing. If I understood well on the nautilus list, the browser mode of nautilus is going to work in the same way: it usually shows a button bar for the location, you hit CTRL+L, it is replaced by the location entry. As someone suggested, for accessibility (and discoverability) reasons it might be better to have a button for the same toggling, or if the interface might remember the last setting. Having two types of typeahead is also confusing imo... can't we override the gtk-tree standard typeahead so that when you start typing in there the location entry shows in place of the location button bar, and the tree under it follows in real time the content of the location bar? When you start to typeahead the buttons are not useful anymore, unless you want to change directory, and even then then the locationbar is more useful for this goal than the gtk typeahaed. After all, we're dealing here with a specialized type of tree, that would benefit from auto-completion etc. Nothing wrong imo if it isnt treated like a standard list.
I have a very simple proposal, similar in conept to the comments #1, #38 and #51. If you must stay with the button-based approach to the folder path, then please consider adding the "ellipsis" button on the far right side of those buttons. It should show the location dialog, exactly as Ctrl+L does right now. The ASCII art follows: +--------------------------------------------------------------------+ | Open file [X]| |--------------------------------------------------------------------| | +--------------------+-+ +=+ +====+ +===+ | | | |^| |<| |home| |...| | | | |-| +=+ +====+ +===+ | | | | | +------------------------------------+-+ | | | | | | |^| | | | | | | |-| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |-| | |-| | | | |v| | |v| | | +--------------------+-+ +------------------------------------+-+ | | +==========++==========+ +=================+=+ | | | + Add || - Remove | | All files |#| | | +==========++==========+ +=================+=+ | | +----------------------------------------------------+-+ | | Encoding: | Automatic detection |#| | | +----------------------------------------------------+-+ | | | | +============+ +============+ | | | Cancel | | Open | | | +============+ +============+ | +--------------------------------------------------------------------+ I refer to the ellipsis [...] button near the top right corner of the window. It fits naturally there and fills the usability gap. Every developer that ever worked with any RAD environment will easily recognize that this new button would show some more options. I propose that it should show "open location" dialog box at the very least. Alternatively it could cycle between the buttons bar and the text box. It's simple to implement, natural and easy to find. Please think about it. Friendly, Wiktor Wandachowicz PS. The very first contact with the gtk filechooser made me think that the designers must have lost their minds. A row of buttons instead of a simple, yet powerful text box? I became less angered when I accidentaly found the Ctrl+L shortcut. Now searching through the bug list I've found this one, which has been opened over 18 months ago... I think it's the high time this should be resolved for good.
I really like this idea, and from my POV at least, it solves the problem elegantly, with minimal change to the existing GUI. As a minor nit/aside, I would recommend that we assign an accessible-name and tooltip/description to this ellipsis button like "Enter filename" or "Enter path to file" (not sure "open location" is as meaningful). This would further help with discoverability for first-time-users of the dialog, and would also assist blind users who might not otherwise anticipate the result of activating an "ellipsis" key. Let's do it! Any concrete objections?
The only objection is that the ellipsis is only an (elegant) workaround - still I think a permanently visible entry-box would be better. Another thing to consider (not an objection though) is that the button will take away place from the folder-hierarchy at the top. Not all languages use the short "Home", e.g. in german it is "Persönlicher Ordner". But I guess an ellipsis-button is OK.
*** Bug 324249 has been marked as a duplicate of this bug. ***
*** Bug 324994 has been marked as a duplicate of this bug. ***
Personally, I very much dislike this proposal. The space that would be allocated by the ellipsis button is desperately needed by the path-bar. If such a button was added there, that place would be missing for the path buttons. And unless it is separated by a lot of horizontal spacing it would appear as part of the path-bar, which it isn't. The fact that three dots on a button could mean anything doesn't make it any better.
sven, compared to path names, the ellipses consume a very small bit of real-estate, so I don't agree with you that the space tradeoff is bad. In the ascii-art mockup, the ellipses are indeed separated by a lot of horizontal spacing. Let's put this thing to rest at last, there are too many dups and too much time has elapsed (four stable release cycles).
From what I see, the idea of putting the entry in place of the path-bar, as is done in Nautilus (see comment #64) has been welcomed a lot. But it doesn't really deal with the original concern of this report which is discoverability. So perhaps that suggestion should be moved to a different bug report then?
I don't see why you would think so; maybe I'm missing something. The idea behind the ellipsis is improved discoverability. PLEASE DON'T file a separate bug report as that will just confuse things further (note the large number of dups against this bug).
Bill, I was referring to comment #64 which is not about the ellipsis button but deals with the suggestion to get rid of the dialog that pops up when Ctrl-L is being used. The text entry can instead be displayed temporarily in place of the path-bar. This is what nautilus is doing as well and it is IMO a good idea that deserves to become a separate bug report.
Sven Bug 324994 describes that Ctrl-L should change the path bar into a text box as in nautilus, but that bug was closed as a dup of this bug
Please leave this bug as it is. The idea is to have this for the path bar: [*][<][federico][Downloads][foo] where the "*' is GTK_STOCK_JUMP_TO icon or something like that. That button will toggle between the path bar and an entry line, and the file chooser will remember that setting. The C-l dialog will disappear, and pressing C-l will simply turn on the entry line. We can make additional things to make the path bar nicer or to fit more path elements in it. We could make the text slightly smaller, or remove the padding between its buttons, or otherwise turn it into a custom widget that really requires less screen real estate. This is also related to the problem where the file chooser dialog doesn't do a good job of picking a default size for itself.
Thanks for clarifying Sven. I think I agree with you about that. Federico, I like the idea you and Sven are suggesting for replacing the path bar with an entry when the foo button is toggled. Making the test smaller would cause other accessibility problems though - a textual element should not disregard "system font settings" unless there is a clear justification for the user to expect the text to be smaller (i.e. superscripts, subscripts) or larger (headings). Just making the font smaller in order to fit more text on doesn't count, that would be flagged as an accessibility bug again.
Would there be any advantage in providing a gconf key that allows toggling of the default behaviour? I can imagine that gok and dasher users may prefer to be able to interact with a text entry widget immediately after opening the file selector window, though I don't think it's something that needs to be exposed in the UI.
(In reply to comment #78) > Would there be any advantage in providing a gconf key that allows toggling of > the default behaviour? I can imagine that gok and dasher users may prefer to be > able to interact with a text entry widget immediately after opening the file > selector window, though I don't think it's something that needs to be exposed > in the UI. Read what I said: That button will toggle between the path bar and an entry line, and the file chooser will remember that setting. It doesn't need to be any more complicated than that.
I was thinking in terms of allowing default user setup, but I guess the filechooser will be storing this in gconf? If so, that leaves me happy.
Related bug with additional problems that I guess nobody is going to bother to fix: http://bugzilla.gnome.org/show_bug.cgi?id=326499
I don't like the idea of having to choose between the path-bar and the text-entry. Ideally I want to have both at the same time. - But I definitely don't want to loose the path-bar in favor of the text-entry. I use bookmarks often, have a directory structure that can easily be navigated with the gnome-filechooser's bookmars and the pathbar. For the cases where I need to navigate elsewhere, I know <ctrl>+L, and that works reasonably well. I don't want to be forced to toggle between them every time. Either I use the mouse or the keyboard. When the setting is remembered, I would have to use the keyboard to toggle back to the pathbar to be able to use the mouse. I don't like that. The solution with the ellipsis button or similar fits better IMHO. (a permanently visible text-entry would be best) My 0,02 €.
>I would have to use the keyboard to toggle back to >the pathbar to be able to use the mouse. I wouldn't think so; I think the plan would keep the toggle button visible so that you could toggle back with a single mouse click. Maybe I misunderstood - but I think keeping the toggle/ellipsis button present in both states makes sense for the reason you suggest, Christian.
> I think the plan would keep the toggle button visible so > that you could toggle back with a single mouse click It this is the case, then OK for me.
(In reply to comment #82) > I don't like the idea of having to choose between the path-bar and the > text-entry. > There's enough room for a full text input below the path bar. There's a lot of poorly exploited space at the bottom. > Ideally I want to have both at the same time. - But I definitely don't want to > loose the path-bar in favor of the text-entry. I use bookmarks often, have a > directory structure that can easily be navigated with the gnome-filechooser's > bookmars and the pathbar. For the cases where I need to navigate elsewhere, I > know <ctrl>+L, and that works reasonably well. Reasonably well is not good enough . I think the ergonomics of these file dlgs is very poor. It sounds from the way you describe it that you manage to work around the limitations of the interface rather than work with it. >I don't want to be forced to > toggle between them every time. Either I use the mouse or the keyboard. When > the setting is remembered, I would have to use the keyboard to toggle back to > the pathbar to be able to use the mouse. I don't like that. > The solution with the ellipsis button or similar fits better IMHO. (a > permanently visible text-entry would be best) It was great shame when this was removed from the earlier interface. I too would like to see the return of a permanent text entry. > > My 0,02 €. > Make the 0.04€.
PS Any chance of someone in a position to change the code making some changes. This interface is central to a whole fleet of software, some of it excellent, so these usability issues are very important. This bug will soon be old enough to go to school on it's own! It would be nice to see some movement. Thx.
I have to disagree with the ellipse button suggested in #65. He suggests that using an ellipse button is intuitive since "every developer that ever worked with any RAD environment will easily recognize that this new button would show some more options." That in a nutshell is the endemic problem with OSS software interfaces. He designed it with developers in mind, and that is the wrong target audience. The fact that he explictly stated this, and no one called him on it, I find troubling. I am not arguing that the target audience is, as some believe, the mythical person-who-has-never-seen-a-computer-before-in-their-life either. That's an equally invalid audience since those people don't exist in any significant number the year 2006, and those that do are very unlikely to take up using a computer. The ellipise means "more." Seeing a possibly partial pathname followed by an ellipse will be often read as exactly as it says on the screen. "[/] [home] [user] [dir] [dir] [...]" will become in the mind of the user "/home/user/dir/dir/..." which is "the directory /home/user/dir/dir/ and then something else." "..." could mean scrolling, or some other navigation control. It could easily be interepreted as "the place where the file goes." The fact that we know that a button containing "..." means "brings up a dialog" is more due to our knowledge of specialized interfaces for small audiences (often with horribly baroque interfaces), rather than our knowledge of interfaces for general audiences. The filechooser is a general widget for a general audience, and should therefore use the vocabulary of the general audience. Even if you change the button from an elipise icon to the some other icon, this bug will still remain open. This is because there's actually two different problems have with the dialog. First is the undiscoverability of the subdialog. The addition of the ellipse (or whatever) button for the most part solves this problem. The other problem is the general usability of the dialog. The ellipse button does nothing for that. The usability problem isn't just that the elimination of the location bar goes against 30 years of the GUI, it's that you've doubled the amount of work that must be performed to use the dialog in a common manner. Consider the traditional chooser and the gtkchooser for simple tasks. Opening a file through clicking Traditional: Select "open". Click file from list. Click "open." 3 steps Gtk: Select "open." Click file from list. Click "open". 3 steps Opening a file through typing Tradtional: Select "open." Type filename. Click "open." 3 steps Gtk: Select "open." Bring up subdialog. Type in filename. Click "open." Click the file name from the list of files, since the the dialog didn't open the file, but merely changed directories. Click "open." 6 steps. You've doubled the work. People don't like that. People REALLY don't like that. The number of duplicate bugs filed against the chooser is evidence for this. Furthermore, click depth is a standard metric for measuring HCI usability, and this dialog has moved in the absolute wrong direction. People won't be satisfied until they get the entry box back into the dialog. You can grind your teeth and pull your hair all you want, but that's the truth. Having the ellipse button switch the path button bar to a text entry still doesn't solve the problem. All that would be accomplished would be the elimination of the subdialog. While commendable, this only a partial solution. It is implied (through its location) that text entry would still only be used to switch directories, NOT open files. You'd still have to scroll through the file list and click on the file you want to open. That is frustrating for users because it goes against their expectations of how the dialog should behave, given their experience with similar dialogs on different platforms. In measurment of click depth, the depth would only be reduced to 5 clicks versus the traditional 3. The argument of that adding the the location bar back into the dialog makes it "too cluttered" is a strawman. The exact same dialog is used to save files as well as open files. In save mode, the dialog has the location bar, yet no one is suggesting that in this mode the dialog is "cluttered." If one was to remove the location bar from the save dialog and shove it off into some subdialog in the interest of reducing this supposed clutter, (I would hope) that proposal would be laughed off the list since it makes the standard task of saving a file much more difficult. The basic usability issues for saving are equally valid when using the same dialog in the complimentary manner. WRT thte "add" and "remove" buttons under the bookmarks pane, I'd drop them. They look too big, and cause another subdialog with only three controls (open, cancel, text-entry), or heaven forbid, ANOTHER filechooser to appear. These buttons could easily be removed and replaced with drag and drop. If you're yoing to rip off the MacOSX chooser, rip it off right.
>> If you're going to rip off the MacOSX chooser, rip it off right. AHHH! So that's what this is all about. That explains a lot. I agree almost entirely with your rather long post, well said. The only bit I disagree with is the "twice as much effort" part: I'd say it takes 3 or 4 times as much mouse manipulation unless your files is in the current directory where the dialog opens up. This interface has annoyed me too much , for too long. I am currently trying to code some changes to make it easier to use. My first step was to make the path bar full width. This helps some. Patch available in the related bug thread if anyone cares to try it. Post your findings there rather than here. ;) http://bugzilla.gnome.org/show_bug.cgi?id=327733
Created attachment 59396 [details] Mockup A
Created attachment 59397 [details] Mockup B
[Arg, i thought Create a New Attachment would add an attachment to the Comment currently in edit! Sorry, this is less than optimal.] A proposal for a file chooser with combined path button / input field. See the 2 Attachments above. The basic idea is treating path buttons somewhat like characters in an input field. Backspace will delete the last button, going one level up. "../" (maybe even "cd ../") should also work. Entering / after the name of an existing dir could turn that part of the path into a button. A / as first character entered might be a good way to allow input of full pathes. A file extension (specific or with wildcards) could be given after putting in a dot. That should also affect the filetype selector below the list. Including / in the labels is an option to make users familiar with that seperator. The path/button section of the field is right aligned to theleft edge of the list view, to make the input section lineup with said list view. This way the dialog is split up into a path/places part and an input/list part. With no input, all files of the current dir are shown, withthe first one preselected. Hitting enter will open it (go into a dir or open a file). Mockup B shows how the file list will be filtered and how completion could work. If there's only one match, it would be selected to be opened on hitting enter. Partial completion is to be shown after the cursor, in a different colour and an Enter icon, as hitting Enter will accept the completion (until then, the Open button should be grayed out, actualy). (A single character for completion is not the best example, I was just lazy here ;) Wildcards (?, *) should also work for list filtering. I thought about automatical partial completion, so in my example entering "h" would result in "ha" directly. But that would require the user to check what happens after each single key ... I removed the bookmark buttons, because a larger list and less cluttered look seems more valuable to me. Would also make using the bookmarks in one-click mode a no-brainer. Maybe a hint about drag and drop could be shown as last element in the list.
That is really nice - I would like to see path handling done like that. It kind of looks similar in concept to the KDE 4 file manager mockups, and I liked it there too: the idea is to have the mouse-only-browsing users be able to operate the interface without fuss and with no learning curve, while not preventing a person who knows what they want and where it is to get intimate with a keyboard (and/or making life difficult for either by making them go through hoops to get at their favorite interface). The KDE 4 mockup went further by having a click on each path element open a pull down of alternate possible entries at this location - did you had something like that in mind ? > I thought about automatical partial completion, so in my example > entering "h" would result in "ha" directly. But that would require > the user to check what happens after each single key ... Which is what happens now when you open the "open location" sub-dialog, which is really really annoying.
How about making the whole path selectable text, but making the path elements activable and decorated in a special manner within the text -- both by mouse and keyboard (e.g. Shift+Enter would switch up to the directory under cursor). Something like /[foo]/[bar]/[baz]/asdf.txt With [ ] denoting some kind of decoration that should hint that that part of the address works also as a button.
From #92 > The KDE 4 mockup went further by having a click on each path element open a > pull down of alternate possible entries at this location - did you had > something like that in mind ? No. Clicking a path button should work like now. Everything of the current level can easily be selected in the listview. That's the route of least surprise and keeps mouse and keyboard navigation together. Menus would require a different visual style anyway. To #93: Making the path selectable as text would be nice and could be done even with the button style. The path elements should look like buttons to make it clear they're clickable. Showing them underlined as links would be an option, though.
Yeah, I like this too - though I agree that the visuals could be made prettier and the buttons could be shaded to look more button-like. I like the idea posted in comment #93 too, as the inclusion of the '/' path separator within the separate buttons (as in mockups A and B) looks a bit awkward to me. But the basic idea of appending a text entry to the end of the path buttons seems like a very nice solution to the problem(s).
Nice, looks like a step in the right direction. A patch against current CVS would be nice to actually try this out. It would make it easier to assess how it actually works. I too find the inclusion of the / separators a bit unwieldy although I think it would help readability if the root directory was represented as / rather than an icon. I dont like the over use of icons and mixing icons and text lacks clearity. There is perhaps an unnatural ammount of twisting going on to actually link the bar and the file list. I find this unnecessary: we all know why we are here, to select a file name . Going into contortions to tie the two impedes clarity. eg the column headers are now footers. Unusual (probably unique) , therefore requiring yet more "what's this" rather than instantly being obvious. Glad my idea to give the pathbar full width has fallen on firtile ground.
To #96 I lack the skills to code it. I don't care for the / seperators much, put them in the mockup to show how path buttons are not about hiding anything. About linking bar and list: I felt a bit uneasy about it at first, too. But: - Up/down arrow keys have to work imediately in the list, while the focus has to be on the input field initialy and should stay there if possible. So I made it one big widget, with one focus. - Contents of the list change depending on input in the field. Column headers inbetween would break the visual connection. They look and act like before, so for learning it's a short huh? folowwed by recognizing the familar controls just placed differently. I would even rather remove the headers than breaking the filed-list connection (not once in my whole live did I use them in the file dialog).
Sorry, I misunderstood your mockup , I thought you had coded a prototype and this was a screenshot.
Created attachment 59448 [details] screenshot of modified dlg If you want to reproduce that you should be able to apply each modification individually with the patches in the following bugs: 331313 331306 331319 331334 59042 They were made against CVS gtk+ but are simple enough to apply to just about any recent gtk+-2.8.x
Created attachment 59449 [details] [review] agregate patch of above changed
I share the uneasiness at the amount of contortion going on trying to turn something fairly simple (separate "path buttons" and text field) into something "kewl" (I find it a bit hard to the believe the frankenstein looking thing shown would be more friendly to newbies). In particular I'm concerned because I want the text entry field to _act like a text entry field_ -- in particular in my case, that means I want the emacs editing keys to work as they do in other input text fields. I don't know how the mockup shown would actually be implemented, but given it's ad-hoc look, I fear it would also behave in an ad-hoc manner, and not give the proper "text entry experience." [Of course it's not unusal for apps to break text-entry by adding hacks here and there, but it would be nice to at least start on the right foot...]
To #101 Mr. Bader: I take offence with your accusation I tried to make something "kewl". How about actualy reading what I wrote? I stated why I made it this way. So what's wrong with my reasons and the proposed functionality? Please explain how it would be less friendly for newbies in a way having an impact beyond the first 10 seconds of the very first encounter (and it's not like the current dialog, or any other new dialog of that complexity wouldn't require some getting used too). It's only a mockup. Why do you make asumptions on it's behaviour in a realm I didn't touch? What emacs editing keys and why wouldn't they work?
Um, you didn't give much in the way of justification for other than a few minor details. One can presume you believe it would be easier to use or more efficient (in terms of space) than the alternatives. My concern is as I stated: a text box is a simple and familiar interface for many people. This bug is about making that simple and familiar interface more available in the file chooser. If it is to instead be replaced with something else, I want to be sure that the replacement is a sufficient replacement. ["take offence"?!?]
On #103: Strange. I though I gave justification on pretty much every detail of my proposal. (#91, #94, #97). You ignored my questions. That's not helpful. I still don't know what's with those Emacs keys. Poor discoverability of text entry box is best solved by putting such a box back in right away. Additionaly, my proposal is about making the best use of it. By giving meaning to backspace and ../, using the filelist as completion list instead of popping up a menu which would hide the listview and therby not add usefulness to the dialog. Up to now I don't see one thing that can't work in this field that does work in a standard text box, as it would be used in the dialog.
(In reply to comment #93) > How about making the whole path selectable text, but making the path elements > activable and decorated in a special manner within the text -- both by mouse > and keyboard (e.g. Shift+Enter would switch up to the directory under cursor). > > Something like /[foo]/[bar]/[baz]/asdf.txt > > With [ ] denoting some kind of decoration that should hint that that part of > the address works also as a button. > hmm, I think there's something to gleaned from the existing path bar idea which , despite being rather restrictive introduces a potencially useful idea of a clickable address. In fact this is all it has to offer which is why I find it restrictive. I'd already thought of incorporating this idea into a text edit path where a dblclick could scan left and right and act as you suggest. I'm a little wary of making this too fancy. Many of my critisisms of the current interface are that there are too many exceptions, modes of behaviour and hidden features. The user should not have to "learn" how to use something like this or read the man page or google to find out how to enter an address with the keyboard. That's essentially why this now rather long bug was started.
Clickable links for directories in a text edit box containing the full path would not be that fancy, and would provide the so-called "benefits" of the path-bar while also providing the text edit box that is essential for usability.
I'm assuming all these mockups are pretty rough and ready at this stage - i.e. not necessarily refined for looks, HIG, or details of behavior. I think there are good ideas floating around, thanks to those who are taking the time to make concrete suggestions.
I like thorwil's idea, it has the advantage of making the path entry box always and immediately available. I agree that there are some behavioral issues to address in that case. However, my initial reaction is that it's immediately obvious how I would "expect" it to work, maybe that's just me... One disadvantage of the 'aggregate' patch is that the edit bar is still not easily discoverable (at least AFAICT), and making it a separate dialog is also suboptimal IMO. The "footers" feel wrong to me, I'd prefer to see the headers in their traditional place, with the path bar/buttons across the top. Minor question: what happens to the path bar if the path gets superl-long and doesn't fit across the dialog? Do scroll buttons or ellipses of some kind appear? (in the theoretical proposed dialog, I mean).
For a too long path I would vote for scrollbuttons like current path buttons have them. They work quite well in my experience. I think it's ok for the dialog to be very wide. Maybe the full path can be shown in a tooltip on mouse-over. For a better job at avoiding scrolling, we would have to go vertical and use more space (multiline, perhaps even a row per level for the lowest n levels).
Created attachment 59474 [details] Mockup, separated listview, column _headers_ With input field and list not connected, keyboard focus has to be on 2 widgets: cursor keys to list, characters to field. Enter on list or for completion if there's more than one match (refer to earlier Mockup B on how that is to be communicated).
Created attachment 59478 [details] Mockup, no column headers
Created attachment 59480 [details] Mockup, connection by set back area Trying to communicate the close connection between field and list in another way.
Created attachment 59481 [details] Alternative link styles
That looks a lot better. What we are moving to is a button that can be typed into. I can imagine how that may be coded. Clearly only one object can have the focus but it could evoke action in another . I would generally say that is bad design. Could you explain what you had in mind that would require both objects to have the focus at the same time? @ bill.haneman the agregate patch was not intended as a final solution but as a painkiller for the current setup. It addresses some of the things I find annoying. I feel the separate dlg was probably added on when it was realised the interface was lacking. It looks and feels like an after-thought and is probably why it is not properly integrated into the design. I think any solution to this interface must have text input at you finger-tops as soon as any of these dlgs come up. Coding that is going to require some proper design planning and a lot more coding effort. I hope that the tweeks I posted may aleviate the suffering until the magic day our voices are heard ;)
thorwil , I really like the third one. Graphically I find it pleasing but also it seems to communicate the idea it's somewhere to go. Nice work. (Looks like ten times more work to code tho') I'm also against this icon next to, or instead of, root. Icons should only be used when they clearly communicate something . "root directory of the filesystem" is rather abstract . Icons here tend to be confusing meaningless icons for the sake of icons. (Not a critisism of you , I know you just copied gnome, but I'd like to see this go.) If the user has ever seen a file name in his life he knows what the separator is . If he does not understand the concept of the directory at the top of the file tree then a little box icon is not going to help him any more than "/". He's going to have to learn , but my guess is it wont take too long. May be worth padding / with a space each side o/w it gets a bit tiny as a target for the mouse.
The decision on link style should, of course, be left to the theme. I think I would prefer a simple dotted underline, although the first and third mockups aren't that bad. The second one might work with a lighter colour. Some spacing is indeed needed around the slashes. Also, anyone who has ever seen a web page or an URL should get what the underlines and (at least vaguely) the slashes mean.
#114, on shared keyboard focus: Letters/numbers need to go to the input field right from start. But it must also be possible to select from the list via cursor keys at any time. #115, root icon: There needs to be somthing to click on. With / appearing as seperator everywhere else, it might be strange having one clickable / at the start. Hmm, I just noticed that icon doesn't look much like the one for Filesystem in Computer.
if you want to select from the list you should use the mouse in that control's area, in a mouseless context you can tab to that control then use the arrow keys and enter. redefining the behaviour of these basic, univeral elements is likely to be confusing , I would disfavour that kind of design.
I think that the idea of having the up/down keys redirected to the list is a good one - the purpose is to do away with the popup autocomplete menu which makes no sense when the path bar is integrated back into the control (it just offest options that can already be seen in the file list), while retaining the important parts of its functionality. I don't see it as forcibly coercing two different widgets together, but as a completion of the logical evolution of the file-selector/auto-completion-path-editor - IIUC that's also why the path editor is right aligned to the left side of the file list - so it actually looks and feels like the file list is logically the continuation of the path editor. I think its a good example of forward thinking interface design that isn't tied down to old customs just because "that's how it always been coded". Regarding the headers vs. footers - I think that unless you plan to let users adjust the columns, such as adding new columns and modifying widths (which in the rather limited case of name and data can be done automatically), then you can do away with them and just use the interface like in comment #111. Regarding icon for the root: A surprisingly large number of users, mostly MS-windows users don't understand the concept of '/' as the root. A large and friendly icon which would symbolize what Nautilus' "Computer view" calls "filesystem" would help users to understand where things stand, and would also provide a large mouse target. Also - if you have an icon for the "filesystem", you can also use the other custom icons available in the "bookmark" list - like clicking on "home" would show the "home icon" as the root and only when you "../" above that it will be replaced with the location of the user's home directory relative to '/'.
*** Bug 331915 has been marked as a duplicate of this bug. ***
This is just oh-my-god bad. I hope I'm not alone in respecting someone who can swallow some pride, admit the error, and revert the change that put this thing in CVS. Lack of a text area is only 40% of the problem. There isn't a directory tree! There isn't a link to the /tmp directory. Everything is crammed into a tiny little dialog. Has this been posted to the GUI Hall of Shame yet? It should be. Meanwhile... does anyone have a fix? Usually, people use the LD_PRELOAD environment variable to force apps to load a library of replacement functions. Probably it should use dlopen() so that stuff like "bash" and "grep" don't need to load all the GNOME libraries.
>> people use the LD_PRELOAD environment variable to force apps to >> load a library of replacement functions. Good idea. In case you have not noticed this is not cvs, this has been mainline gnome for 2 ro 3 years. Someone thinks they have come up with an amazing new way of working based on this idea that users only want to access two or three directories and thinks it is appropriate to force all users, not only of gnome desktop, but all programs written using gtk libraries to work that way or be damned. Whether this is pride, arrogance, dictatorial attitude, or simply not listening to the userbase I can't tell. Anyway there seems little chance of an official change of line before gnome becomes completely marginalised, so dont hold your breath. You could try some of the patches I've posted , they help a bit. >>Probably it should use dlopen() so that stuff like "bash" and "grep" >>don't need to load all the GNOME libraries. what do you mean here? I dont see my bash loading anything from gnome.
(in reply to comment #122 -- geez that's a lot of comments) If you hack around this with LD_PRELOAD, then bash will indeed load the GTK libraries. (or GNOME or GDK or whatever is needed for the file selector) The hack would involve setting LD_PRELOAD in .bashrc or /etc/profile or similar. Like this: export LD_PRELOAD=/lib/libunstupid.so That *.so file supplies a replacement dialog box. It would get loaded by every app. With dlopen(), loading all the graphics libraries could be avoided for apps that don't call the dialog function. Suggestion for something decent: Add a "Preferences" button. Generally, put a tree view on the left and a list on the right. For preferences, let the tree show everything, directories only, or nothing at all. Let the list view show everything, non-directories only, or nothing at all. Views that are set to "nothing at all" just don't get displayed. For the path the choices: tab completion, mozilla-style completion, no completion, no path display. Have a button with "/", one with "..", and one with "$HOME". On those same buttons, put some pretty soft-focus-look icons underneath the nerdy text. Also have a back button and one for "/tmp". Put non-normal files and dotfiles at the bottom of the list, in italics, and ask for confirmation when the user selects one. (with a checkbox to disable future confirmation) BTW, I suggest that _everyone_ ask about this defect whenever a GNOME/GTK/GDK developer speaks at a conference. Insist on a damn good answer.
Ah thanks, I see what was meant by LD_PRELOAD . Not really appropriate to burden everything that runs with these large libs. The only real solution is to provide something better and convince the gnome crew that the user base is dissatisfied with the current interface. (If that fails it could be done as separte package but that's not a very good route. Last choice.) I agree there should be at least the choice of a treeview. That seems to be what most ppl need and want. However be aware that there is a question of style here where gnome tries to distinguish itself from kde. KDE tries to give everything, with checkboxes and options abound. Gnome tries to give a minimum of options and regards this sort of thing as clutter. Sadly current thinking seems to regard a text input for the address as clutter as well. :?
(In reply to comment #121) > This is just oh-my-god bad. > > I hope I'm not alone in respecting someone who can swallow some pride, admit > the error, and revert the change that put this thing in CVS. > > Lack of a text area is only 40% of the problem. There isn't a directory tree! > There isn't a link to the /tmp directory. The directory tree is quite complex representation of the filesystem. A lot of users have problems with this kind of abstractation. Things within things within things - it too much for them. The current filechooser tries to "flatten" the directory structure by introducing this nice bookmark feature. Instead of browsing through the filesystem, you create heap of links to your most used directories. This way, searching in the filsystem-structure is reduced to the minimum. This way, browsing is no common task anymore, therefor there is no need for a directory tree. If you spend a lot of time browsing trough you filesystem in the search of files or directories, I suggest you make more use of the bookmark-list to the left of the filechooser. This way, you can also create a link to the /tmp directory, just as I have done. I don't think that the filechooser needs an "Option" button. It's a fileselector, not a filemanager. >Everything is crammed into a tiny little dialog. Well, yes. It a filechooser _dialog_.
I don't think the userbase is dissatisfied. Some users are but the majority including myself is quite happy with the new file-chooser. I remember that we (the GIMP developers) got a lot more complaints about the old GtkFileSelection dialog than we get since we have moved to GtkFileChooser. I admit that the first versions didn't work very well but with a recent version of GTK+ the user experience is quite satisfying. The work that is being done on making the file-chooser asynchronous is going to make it even better. The new dialog works nicely for most users, newbies are happy with intuitive point-and-click interface and more experienced users can navigate it nicely thanks to typeahead and the availability of keyboard shortcuts. What is missing is user documentation. There are a few rather useful keyboard shortcuts that are hard to discover. And no, I don't speak about Ctrl-L. That popup dialog should best be removed altogether.
Sven, are you saying that the text entry doesn't need to be available at all? I certainly don't think you will get consensus for that. Though frankly I don't believe we have consensus regarding its omission from the default dialog. These comments are not just coming from the fringes.
Bill, I think the idea is that you can simply start typing a file path. If you start with slash, it will just navigate you from the root...
The keyboard shortcuts are a joke. (Even the name "shortcut" implies that there's something fundamentally wrong in the basic UI design.) Instead of conveniently typing '..' to go to the parent directory, one must move hand to the cursor key block to type Alt+Up. Same with completion: the entries can only be selected between from the cursor keys. Moving hands there is not something one should have to do while typing in a usable system. Control+letter-combos are much more convenient. Or just commands; see <http://iki.fi/tuomov/b/archives/2006/02/12/T21_08_50/> for more ranting on the current pitiful state of user interfaces, if interested. And don't get me even started on the dialog jungle madness.
That behavior about ".." is just a not-implemented-yet feature. There's even a bug about it open somewhere. Now can people stop flaming and file individual bugs with any constructive words they may have?
In reply to comment #127: I think that it is fine not to have a text entry as in the current version of the dialog. A text entry would only collide with typeahead keyboard navigation in the files treeview. There are certain use cases where the Ctrl-L text entry is useful but I think that a popup dialog is the wrong place to put it. I would suggest that it replaces the path bar similar to what Nautilus is doing if you press Ctrl-L.
On #131 right above: Just not having a text entry does not adress the accessibility problem this bug report started with. My proposal (see attachments, #91 and following) is also about making text-entry and type-ahead one, so no collision. Your suggestion of replacing the path bar on Ctrl+L would be an improvment for the current dialog, though.
(In reply to comment #126) > and the availability of keyboard shortcuts. What is missing is user > documentation. There are a few rather useful keyboard shortcuts that are hard > to discover. This is documented here: http://developer.gnome.org/doc/API/2.0/gtk/GtkFileChooser.html#gtkfilechooser-key-bindings That page needs to be regenerated. The full list of key bindings is here: http://cvs.gnome.org/viewcvs/gtk%2B/docs/reference/gtk/tmpl/gtkfilechooser.sgml?rev=1.32&view=markup And it needs to be moved to the user documentation. Instead of whining, can anyone cook a patch for the GNOME user's guide?
(In reply to comment #133) > Instead of whining, can > anyone cook a patch for the GNOME user's guide? Do you honestly believe that this is a proper solution? Do you really believe that people should have to read documentation just to learn how to enter a file path in dialog? People will either stumble on it accidentally, or assume that it's impossible and be unhappy about it (or both - first unhappy, then stumble on it and be angry that it is so unobvious).
>>A lot of users have problems with this kind of abstractation. That's what a lot of the problem is here. Thinking the "average user" is an absolute cretin. If they dont have the mental capacity to use a file hierarchy they should be taken away from the computer and given some nice friendly plastic bricks to play with . In the meantime can the rest of us be taken into account as well? >>There are certain use cases where the Ctrl-L text entry is useful but >>I think that a popup dialog is the wrong place to put it. >>I would suggest that it replaces the path bar >>similar to what Nautilus is doing if you press Ctrl-L. Thanks , if that's how it works in naughtilus maybe there would be a good chance of getting that accepting into the filechooser. re documentation: >>And it needs to be moved to the user documentation. LOL. Strange no-one had suggested that before ;) >>That behavior about ".." is just a not-implemented-yet feature. IFRC that was my bug. It got pretty short scrift. I was told I "did't need it" and it got marked WONTFIX.
>>Do you really believe that people should have to read documentation >>just to learn how to enter a file path in dialog? Which is what the title of this thread is all about. This needs fixing. Fixing the holes in the doc so you can say RTFM is not a solution.
Frankly, if the supposedly easier-to-use file chooser requires users to read loads of documentation first until it works for them there is a fundamental issue. I think the larger problem is that the gtk+ file chooser has been designed for a very specific way of working - as some people have mentioned, for example you use bookmarks for frequently accessed locations. The problem is that this basically excludes all other users that can work with about any file chooser (even the bad ones by means of select and paste). The message is clearly "you are not in our target group, your problem", and refering people to the documentation for workaround shortcuts is not fixing the issue. Most problems with the filechooser can indeed be worked around by cryptic-even-if-documented shortcuts, but the problem is that those (wether it be ctrl- or cursor-up) are just ugly workarounds. Gtk+ will drive people away with this attitude. Maybe not their target group (whoever is that), but the people who don't feel well with being forced in a specific unnatural and inefficient (for them) workflow.
I think we are missing the issue here with all the directory browser talk. The point of this ticket is to make the currently "hidden" features of the file chooser dialog usable - and that means not reading the documentation, if GNOME developers are serious in addressing the needs of people who are initmidated by a directory structure (which are usually the same people who don't bother with docs). I also believe that the popups have to go - this is a dialog, not a full fledged application (and IIRC GNOME HIG frowns on such popups). There was some mention of nautilus having some sort of path bar like the file chooser where CTRL+L turns it into and editable area? My version of nautilus (2.12) doesn't have such a contraption and CTRL+L opens the same annoying (and unusable) popup which is the point of discussion above. I think this popup should be killed on sight ;-) None the less, the needs of the non-wimp-addicts must be addresses if GNOME is expected to survive as major desktop environments, so simply removing the ability to type paths would be a step in the wrong direction. As such the thorwil's suggestions (comments #89 and onwards) are a valid solution, if a bit far fetching. The option of addition a *visible* cue that allows switching between the path bar and a real path editor, is another one. So let's be a bit productive and think about what can be done to solve this ticket instead of digressing into an opinion war. We have two possible solutions - any one here with a third (and no, fixing the documentation is not a solution, though it should be done anyway) or can we vote on the proposals as they are ?
Here's a screenshot of a modified filechooser in "save" mode. Snapped from Gimp, hence the image preview panel. http://bugzilla.gnome.org/attachment.cgi?id=59500 This exists as a patch and represents just a few trivial changes to std gtk code. Since the file-save version has the text input visible I would like to take this as a model for file open as well. It opens in this state with file browser open and the now redundant combo hidden. This cleans the dialogue up and makes it much closer in appearance to the file open dlg. I think both versions should be very similar in appearance, what ever that ends up being.
Regarding comment #125 about the tree abstraction being too hard: First of all, this is simply something that a user MUST learn. Trying to keep users in the dark only ensures that they are forever confused and lost. Some things you just can't avoid. Given that we do have a tree-structured filesystem, think about what might be the most gentle way to introduce it. I think that the normal tree view fails for many users because it lacks animation. Just maximizing an app should show the window shooting out of the task bar, expanding a directory in a tree viewer should show the subdirectories coming out of the parent directory. If you must: Label the tree view "where you are". Label the list of files "things that are here". As things are now, I have difficulty finding my way around the filesystem. I am lost. Imagine you have a car that is covered in ice and snow. To drive it, you clear a 4" by 4" (10 cm by 10 cm) patch of ice off the windshield. This is a view of things, so now you can drive the car, right? There is no need to have a wide view of things, right? This like putting blinders on horses.
Reharding comment #139: I agree whith your assertion that the "save" and "open" dialogs should look close, and the attachment is not unlike the KDE file dialog, except that the file name editor is on the top of the dialg here and at the bottom (closer to the "save" button) in KDE. The KDE approach is also to have the "save" and "open" dialog to be as close in appearance as possible. The location of the filename editor on the top makes sense if the dialog is almost always collapsed and shows only that (so when you open it, you don't wonder where did it go - it stays right there on top), but if its always fully opened (maybe with no option to be collapsed), then it makes much more sense to either have the file name below the file list (again - closer to the "save" button, as what most time you'd just type a file name and hit "save" and that way you don't have to visually scan the whole dialog for what you need), or just dispose of it completely and somehow integerate it with the path bar. What I didn't understand is how you suggest to include the capability of typing in complete paths, especially after removing the file name editor (I assume that's what you mean when you say "combo"). Are we going to rely on the invisible pop up behavior again ?
what I was suggesting is what I posted , no more no less. the combo is not the text input it is the dropdown list you see in the save dlg which only duplicated the "places" (ugh) that you have preselected . If you have the full dlg this is disabled , so completely redundant anyway. fire up a gtk program and do a save-as if you are unsure about how it looks now.
Ok, this indeed was my confusion - I'm used to having widgets that offer to choose one option of many called "select boxes", and if they have sort of a pulldown menu then they may be called "pulldown select boxes", where as "combo box" is referring to a widget which looks like a combination of an edit box (where you can edit text directly) and a pulldown select - hence "combo". Anyway - then what I'm missing in your original comment (Comment #139), is how you plan to address the issue described in the this bug, namely the poor discoverability of the text entry box. From reviewing it again, except for the much welcome suggestion (IMHO) of making the "open" dialog look like the "save" dialog, it doesn't appear to address the issue described, at all.
I dont know where you get your terminology from, but if you look at the source code you will find it is a combo. "pulldown select boxes" and "pulldown select" are not a gtk class that I have come across. If you review it again , again, you will notice an attached jpeg that shows you exactly what I mean . It has a text input visible permamently. This solves once and for all the discoverability problem. Does that address the issue for you??
Ok. thanks for the explenation. As I've said, this is quite similar to the KDE open dialog (in regards to the available widgets), and as I've mentioned - the KDE dialog places the text editor below the file list widget - which makes much more sense. As it is now (the screenshot you attached), its very confusing what exactly the text entry is referring too, and as you already have the path bar, its not immediately clear that you can type full paths into the text box. P.S. The terminology I used is widely known, regardless of what the GNOME developer decide to label their code elements, and regarding combo boxes - see Wikipedia excellent description of the concept (http://en.wikipedia.org/wiki/Combo_box). It'd be nice if, when participating in a user interface discussion, the participants will have some experience with user interfaces outside GTK+ code base, and I recommend that you read up wikipedia's "graphical user interface" category as a primer.
Whilst I would hardly regard a Wikipedia entry as a reference on any subject , may I suggest you read the link you posted: >>Combo boxes may allow editing of their text box component... >>or highlight the text for edit if editing is allowed. A combobox has two elements, the input which displays the current entry and the dropdown list (hence the combo). The text is not neccessarily editable as you can read above in your own refernce. It is still a combo. >>It'd be nice if, when participating in a user interface discussion, the >>participants will have some experience with user interfaces outside >>GTK+ code base, Then you'll be pleased to know that I have 25yrs programming experience on a variety of platform and a dozen languages . win32 API has similar controls and they are called ... comboboxes. They can be editable or not. I recommend that you read up wikipedia's "graphical user interface" category as a primer.
*** Bug 333623 has been marked as a duplicate of this bug. ***
Created attachment 60874 [details] Fileselector mockup Back in the year 2004, I have created a fileselector mockup. I think is still valid in this day too. I have commented about my idea in comment #22, but still forgotten to attache a screenshot. This screenshot has many issue fixed includeing: 1. text entry (main issue) 2. separation between files and directory (bold vs. normal font): normal font: regular file bold font: directory italic font: symbolic link 3. eliminate the icon in the clickable path bar In my opinion the first and most important to port back the text entry. After that, we can brainstorming which is the most beautiful solution. Cant imagine, that this bugreport is two yeary old, and sine there is no solution at all. Why cant the gtk developer consider to shipping at least two fileslector (can be configureable through gconf)?
The point is that if you add a text entry as you do in your mockup, you are brekaing the keyboard navigation of the current design. How do you want to solve this problem? You should at least outline all the details. Just showing a mockup is not enough.
What? You're claiming gtk/gnome has keyboard navigation to speak of? Strange, I haven't noticed.
>>Just showing a mockup is not enough. the keyboard navigation is the least of the problems here. It's the file chooser itself that is "not good enough". Please dont be scathing towards those who take the time to make constructive input. @ khiraly you could note that CVS now has some small changes like the pathbar is full width. And the bookmarks panel now has a header ..."places" :? I like your rendition of the pathbar buttons. The text input uses space efficiently where you have put it but since this is the key data for the dialog is probably should not be relegated to the bottom. The file save dialog has a text entry at the top. I would be good to get the two to be similar in appearance. Thanks for your ideas
I am not trying to discourage anyone from making constructive input. But a mockup only defines the look of the dialog while it is at least as important to know how it is supposed to feel. Keyboard navigation using typeahead is a key concept of the current dialog (I almost never use the mouse in the current file-chooser). Adding a text entry is likely to break this concept. This is fine as long as it is replaced by something better. But I cannot see that from just looking at a mocked up screenshot. Some further explanations are needed or the mockup is not constructive input.
To Khirali: Some changes in your mockup (the fonts) are a good idea, and the addition of a text entry is a good idea IMO. It should not impact the keyboard navigation at all: the way I see it, when the dialog first opens the focus would be on the file selector, so everything you normally did with the current implementation would work the same. By pressing TAB or CTRL+L you can move the focus to the text bar where full paths can be entered, another TAB (and possibly by using another "keyboard shortcut") the focus is moved to the bookmark pane where a bookmark can be selected, and another TAB (or ENTER on a bookmark) moves the keyboard focus back to the file selector (we don't need more then these three locations to receive keyboard input). What I didn't like about Khirali's mockup is this: *) I like the "path bar start icon", and removing it is not a good idea IMO - as discussed, non-CS users don't really understand the concept of / as the root and an icon (similar to "my computer" in ms-windows) helps here. Also the mouse target for / is incredibly small and an icon makes it so much easier to hit. *) In the mockup the path is displayed twice: once in the path bar and once above the text box - even if they both sync properly, one of them can surely be removed, and I'm guessing its not the path bar. *) the location of the text box is indeed out of the way and makes good use of screen real-estate (we need to remember that this is a dialog box and its size should be kept to the minimum possible without making it look clattered), but that location also makes it feel not a part of the "file selecting action", and without clear labeling (and probably even with) nobody would understand what it does there. I think it should be placed prominently immediately below or above the file selector, and that for each item chosen in the file selector, it should be automatically populated with the file name selected.
I don't think that the gtkfilechooser needs an aditional text entry for the path. All the functionality is available through Ctrl+L and the path bar. Adding a text entry would lead to inconsistency - the path would be available/modifiable through both the text entry and through the path bar. However; Ctrl+L _is_ not very discoverable. Maybe if the Ctrl+L dialog would simply replace the path bar on Ctrl+L instead of popping up a dialog? This could be configurable so that the location entry would not be shown if a new dialog is created. The path bar should remain the default, however. There is one curious thing: Nautilus _________________ |_________________| <- path bar | | | | | | | | | |____|____________| FileChooser _________________ | |____________| <- path bar | | | | | | | | | |____|____________| Nautilus has the path bar on the top of both the file list and the shotcut list. The filechooser has it on the top of only the file list. Maybe if the difference between Nautilus and the filechooser would be reduced further, the Ctrl+L (also used in Nautilus) would be easier to discover.
A question if I may - how do you get nautilus to have a path bar and/or shortcut list ? The nautilus I get by running 'nautilus' or by clicking 'Places'->something from the menu is the spatial nautilus that have only a file view and going any place opens a new window. It drives me crazy (and is the single most important reason I don't use it for file browsing) and I would love to have a nautilus with a path bar. how do I get to have such a beast ?
You can launch the navigational nautilus by using the "--browser" switch or setting the gconf-key "always_use_browser" to true. I myself created a navigational nautilus shotcut on the panel, that works great.
Ahmm.. as there is no user visible way to set this (not that I could find anyway, and I don't consider gconf-editor as visible: its worse then MS regedit if that is even possible), how do you expect people to use that mode ? I didn't even know its possible until people started mentioning it on this ticket, and I'm sure that no GNOME user who isn't a developer or avid bugzilla reader uses this mode. Considering all that, I don't think that making the file chooser look like nautilus browser mode should be high priority.
(In reply to comment #157) > Ahmm.. as there is no user visible way to set this (not that I could find > anyway, and I don't consider gconf-editor as visible: its worse then MS regedit > if that is even possible), how do you expect people to use that mode ? Did you even *look*? In a nautilus window, Edit/Preferences/Behavior/"Always open in browser windows".
Yes, actually I did, but apparently I'm stupid :-( I missed that completely. sorry about the rant.
Regarding comment #154: In GTK+ HEAD the pathbar goes over the full width of the dialog just as you suggested. I fully agree that we don't need a text entry and that the Ctrl-L dialog should not be a dialog but a text entry that replaces the path-bar just as it does in Nautilus.
I think cntl-L should disappear. The user should not need to know the "cheat" to use this basic dialog. Since the clearly a call (or even a cry) for text input why not use the same code that is already present in filechooser.c when it comes up in save mode? The path bar has its use, which is a complement to the text input . There is no reason for them to be mutually exclusive. The layout used in the save dlg is great . Text on top , then the pathbar.
Created attachment 62262 [details] [review] gtk2-160605-filechooser-filename-entry.diff This is a draft patch of what I'll eventually use.
looks interesting. especially saving the state. do you have a patch for this against recent cvs? I get about 4 chuncks fail dur to the reorganisation of the pathbar to wide screen format. thx.
(In reply to comment #163) > do you have a patch for this against recent cvs? I get about 4 chuncks fail > dur to the reorganisation of the pathbar to wide screen format. I'll attach a diff against (mostly) HEAD in a second.
Created attachment 62404 [details] [review] gtk2-filechooser-new-features.diff This is the patch I'm using within Novell for GTK+ 2.12.x. Some notes: - If you use it against 2.12.latest, you'll get some already-applied hunks; just remove them. - This also includes Beagle searching (you don't need Beagle to be installed; the file chooser will still work, but will show a Search item in the shortcuts). Maintaining two separate patches is too painful, since they both touch the same parts of the widget layout code.
Created attachment 62408 [details] [review] gtk-HEAD-filechooser-entry.diff Patch against mostly HEAD. This is actually cvs diff -u -r FEDERICO_FILENAME_ENTRY_BRANCHPOINT -r federico-filename-entry plus two new files that "cvs diff" didn't pick up.
Hmm, patched nice and cleanly against cvs got a whole pack of compile errors. have I missed something? _DEPRECATED -g -O2 -g -Wall -MT gtkrecentmanager.lo -MD -MP -MF .deps/gtkrecentmanager.Tpo -c gtkrecentmanager.c -fPIC -DPIC -o .libs/gtkrecentmanager.o gtkrecentmanager.c:109: error: parse error before "GBookmarkFile" gtkrecentmanager.c:109: warning: no semicolon at end of struct or union gtkrecentmanager.c:113: error: parse error before '}' token gtkrecentmanager.c: In function `gtk_recent_manager_class_init': gtkrecentmanager.c:245: error: invalid application of `sizeof' to incomplete type `gtkrecentmanager.h' gtkrecentmanager.c: In function `gtk_recent_manager_init': gtkrecentmanager.c:257: error: dereferencing pointer to incomplete type gtkrecentmanager.c:261: error: dereferencing pointer to incomplete type gtkrecentmanager.c:262: error: dereferencing pointer to incomplete type gtkrecentmanager.c:264: error: dereferencing pointer to incomplete type
what's this 2.12.x you refer to, how does 2.12.x and 2.12-latest relate to cvs HEAD ? ftp://ftp.gtk.org/pub/gtk/ only knows 2.10.x what is the definitive location for gtk if not gtk.org ?? Thanks if you can clarify
Sorry, I meant gtk+ 2.8.x, which is what gets used in GNOME 2.12 :) > gtkrecentmanager.c:109: error: parse error before "GBookmarkFile" You need Glib HEAD if you want to compile GTK+ HEAD.
*** Bug 337231 has been marked as a duplicate of this bug. ***
I am sure this has been mentioned but why not just make the location bar entirely implicit in nature? There is no real point in actually drawing it to the screen explicitly since if one wants to change directories or even open a specific file by name one already knows that they want to type a path or file name so immedeatly performing the action of typing something should trigger a text box. There are already characters that delineate paths and such so there is no need for an explicit field to even be drawn at all times. I know I wouldn't want to have to go to have a bar visible at all times just to select an item in Nautilus or even Thunar. I already know I want a file of a given name in a directory I should be able to just type the name without having to bring a predefined bar into focus BEFORE I actually start typing. Ctrl+L or any other shortcut for that matter is really nothing more than a way to bring a pathbar into focus and the need for this focus is part of what creates the problem with the current dialog. I doubt that anyone who dislikes the current layout would have had a problem if the path of least resistance after looking for a text entry field failed [just typing the desired path or file.] worked correctly in the first place.
Darkintent (comment #171), the behaviour you describe is exactly how the file-chooser behaves and has always behaved. This bug report exists because it seems that this behaviour is not intuitive enough for some people.
I do notice that there is a difference between the location selector and the implicit file selection box that shouldn't be so because if you want to change to a file in a subdirectory say /darkintent/Ruby Stuff/Wall.rb you can't do it properly at all unless you type ~/Ruby Stuff/Wall.rb even if you are actually in ~ that is not the behavior I described although it is indeed true that if you type things like / or ~ the location bar will become active however those things are nessecary in order to activate the location bar. This is not intuitive at all and it shows that the implementation itself doesn't work properly to begin with. There should be no difference between me starting to type Ruby Stuff/wall.rb when I am actually in ~ that is the problem the path of least resistance itself is broken that is what is undiscoverable. The current dialog does not function in the way I described however adding a bar to the interface is probably not truly nessecary if the implentation was made to work correctly as I said before.
Regarding comment #171, entry via keyboard works fine if the keyboard is the only thing you want to use. I often copy path and filenames from a terminal window (for example) and want to paste it in to the file chooser dialog. To do this I have to move my hands from the mouse to the keyboard to open up the text entry box then back to the mouse to paste in to the text entry box so I can finish the filechooser operation. No text entry box interrupts my work flow slightly and is why I want a text entry box always visible in the filechooser dialog. Since others don't want it in the box I have no problem with having a configuration option allowing it to be always visible or only visible via Ctrl-L (or when you start typing).
I wouldn't mind an option either what I don't want is the need to bring into focus a location bar. I can't tell you how annoying it is for me to have to move my eye to location bars away from what I want to actually pay attention to. The current dialog just needs its implementation to be fixed and the problems with that particular layout would pretty much cease to exist. What I want to get at is that the current layout is not broken just the implementation of the layout is. I would agree that if one is copying paths from a terminal alot the current implementation is a bit screwy [I do this alot too.] there probably should have been a right-click option to paste a path as well as having ctrl+v [or whatever keybinding one desired] work like Opera's "paste and go" feature.
what we see here is that many people have different ways of working and different needs. The basic flaw of the file choosers is it provides an innovative but restricted way of working. If that does not fit your needs you're stuck. The pathbar should be kept for those who like it and because in some circumstances it can be efficient. Text entry is needed by many. It should be present without any special codes tricks or magic keystrokes. It should work with the universal X paste mechanism (3rd button click) although I suspect the fact that ppl are needing to cut and paste is a telling witness to the usability of the current dlg.
While I disagree that the current layout is restrictive [if implemented correctly.] I whole heartedly agree that the option to make the bar appear if one _wants_ it to be there at all times should be there. I would be perfectly happy if the current layout was simply fixed and an option to have a bar was added; it doesn't really matter to me which was the default however I would ask that regardless of which layout is chosen as the default burying the layout option(s) in Gconf be avoided simply right clicking and selecting hide or show location bar should set the layout for all dialogs. It is perfectly fine to have Gconf settings I just don't want the [these] option(s) to end up getting relegated to the "Gconf pray to the gods at google realm." like other useful options have been.
*** Bug 161742 has been marked as a duplicate of this bug. ***
*** Bug 305646 has been marked as a duplicate of this bug. ***
*** Bug 305385 has been marked as a duplicate of this bug. ***
*** Bug 324036 has been marked as a duplicate of this bug. ***
Apologies for spam... ensuring Sun a11y folks are cc'ed on all current accessibility bugs.
*** Bug 340080 has been marked as a duplicate of this bug. ***
*** Bug 340082 has been marked as a duplicate of this bug. ***
*** Bug 340085 has been marked as a duplicate of this bug. ***
*** Bug 340087 has been marked as a duplicate of this bug. ***
This is fixed in the HEAD branch now. 2006-05-03 Federico Mena Quintero <federico@novell.com> Merged the federico-filename-entry branch, to fix bug #136541. Combined ChangeLogs: 2006-04-17 Federico Mena Quintero <federico@novell.com> * gtk/gtkfilechooserdefault.c (pending_select_paths_process): Oops, we *do* need to check that we are in OPEN mode before selecting the first row in the file list. See https://bugzilla.novell.com/show_bug.cgi?id=166906 (gtk_file_chooser_default_get_paths): If we are in the case for the file list, and the list has no selected rows, jump to the case for the filename entry. This is so that 1. The user types a filename in the SAVE filename entry ("foo.txt"). 2. He then double-clicks on a folder ("bar") in the file list. will yield the expected "bar/foo.txt" selection. 2006-03-29 Federico Mena Quintero <federico@novell.com> * gtk/gtkpathbar.c (gtk_path_bar_init): Reduce the inter-button spacing to 0. * gtk/gtkfilechooserdefault.c (browse_widgets_create): Make the location label bold. 2006-03-29 Federico Mena Quintero <federico@novell.com> * gtk/gtkfilechooserdefault.c (location_mode_set): Just change the location_mode field if we are in SAVE/CREATE_FOLDER modes. (gtk_file_chooser_default_get_paths): Get the path based on the currently focused widget, or the last-focused widget. This is what we should have been doing in the beginning, but it worked out fine because we didn't have the possibility of a filename entry in OPEN mode. (gtk_file_chooser_default_should_respond): Handle the case where the last focused widget is the location_entry. 2006-03-28 Federico Mena Quintero <federico@novell.com> * gtk/gtkfilechoosersettings.[ch]: New files with a simple framework for saving/loading settings from the file chooser in $XDG_CONFIG_HOME/gtk-2.0/gtkfilechooser. * gtk/gtkfilechooserdefault.c (gtk_file_chooser_default_unmap): Save the current settings. (settings_save): New helper function. We save the location_mode and show_hidden flags. (gtk_file_chooser_default_map): Load the settings. (settings_load): New helper function. * gtk/gtkfilechooserentry.c (_gtk_file_chooser_entry_set_file_part): Oops, don't modify in_change. Our handlers are what set the file_part, so they *must* be run when we modify the text. 2006-03-27 Federico Mena Quintero <federico@novell.com> * gtk/gtkfilechooserprivate.h (struct _GtkFileChooserDefault): Removed the save_file_name_entry. We'll make this be the same as the location_entry widget. (struct _GtkFileChooserDefault): Leave only location_button, location_entry_box, location_label, location_entry. We'll use a single toggle button for the location entry, which will appear below the path bar. (struct _GtkFileChooserDefault): Added a processing_pending_selections flag. * gtk/gtkfilechooserdefault.c (save_widgets_create): Destroy the old location_entry if necessary, and hide the location toggle widgets. (update_chooser_entry): In multiple selection mode, just clear the location_entry. (check_save_entry): Allow running in OPEN or SELECT_FOLDER modes if we are in LOCATION_MODE_FILENAME_ENTRY. (gtk_file_chooser_default_should_respond): Switch to a folder if the location_entry contains a folder name in OPEN and SAVE mode, not just SAVE mode. If the entry doesn't contain a folder name, but is otherwise well-formed, and we are in OPEN mode, return that we should respond with that filename. (gtk_file_chooser_default_initial_focus): Focus the location_entry if appropriate. (browse_widgets_create): Create the location_entry_box and the location_label here. (update_appearance): Call location_mode_set() when switching back to OPEN/SELECT_FOLDER mode. Hide the location_button when switching to SAVE/CREATE_FOLDER mode. (pending_select_paths_process): Turn the processing_pending_selections flag on and off around changes to the current selection. Don't special-case OPEN mode anymore, since the new flag will take care of things in update_chooser_entry(). (update_chooser_entry): Don't do anything if processing_pending_selections is TRUE. This keeps the entry from being polluted when changing folders. (location_popup_handler): In OPEN/SELECT_FOLDER modes, toggle between the path bar and the entry. In SAVE/CREATE_FOLDER modes, simply focus the location_entry. (update_from_entry): Removed. (location_entry_create): Removed. (open_location_cb): Removed. (file_list_build_popup_menu): Don't add an "Open _Location" menu item. (location_entry_set_initial_text): Don't do anything if current_folder is NULL. * gtk/gtkfilechooserentry.c (_gtk_file_chooser_entry_set_file_part): Turn in_change on and off around the call to gtk_entry_set_text(). This makes completion not happen when the caller has explicitly set a name. 2006-03-24 Federico Mena Quintero <federico@novell.com> * gtk/gtkfilechooserprivate.h (struct _GtkFileChooserDefault): Added fields location_mode_box, location_pathbar_radio, location_filename_radio, location_widget_box, location_label, location_entry. The radio buttons will switch between the pathbar and the location entry; the other boxes are for layout purposes. (enum LocationMode): New enum. (struct _GtkFileChooserDefault): Added a location_mode field. * gtk/gtkfilechooserdefault.c (browse_widgets_create): Create the location radio buttons to switch between the pathbar and the location entry. Pack the browse_path_bar in the new location_widget_box instead of a generic hbox. (location_buttons_create): New function. (gtk_file_chooser_default_init): Initialize impl->location_mode. (location_switch_to_path_bar): New function. (location_switch_to_filename_entry): New function. * gtk/gtkfilechooserbutton.c (model_add_special): The display_name should not be const.
Congratulations, this looks like you've been busy and adressed quite a lot of issues at the same time. Cant wait to see it in action but pkgconfig seems unwilling to see glib HEAD has been installed. :?
Has the look of the dialog(s) been changed at all? I am really hoping that comment 187 is just stating that the current behavior was made to work as it should have in the first plave but I am not so clear as to what all of the stuff in the comment actually means for the end users.
Is CVS compiling at the moment? I have a clean checkout of gtk+ glib and glibmm , installation of cairo-1.1.6 snapshot but gtk+ is failing to build: /include/pango-1.0 -I/usr/include/cairo -I/usr/include/atk-1.0 -DG_DISABLE_DEPRECATED -g -O2 -g -Wall -MT gtkrecentmanager.lo -MD -MP -MF .deps/gtkrecentmanager.Tpo -c gtkrecentmanager.c -fPIC -DPIC -o .libs/gtkrecentmanager.o gtkrecentmanager.c:109: error: syntax error before "GBookmarkFile" gtkrecentmanager.c:109: warning: no semicolon at end of struct or union gtkrecentmanager.c:113: error: syntax error before '}' token gtkrecentmanager.c: In function `gtk_recent_manager_class_init': My bad or broken CVS? TIA
your bad: you are not using GLib 2.11.0/HEAD (where GBookmarkFile is defined). also, please stop cluttering this bug report with requests for compilation errors.
Indeed , I had had a problem building glib. Since the gtk+ precompile checks stated that it required >=glib 2.10.1 I was able to fulfill this with 2.10.2 So there is indeed a bug in CSV that may concern those trying to build Federico's latest offering: the version control requirements are out of date and lead to the dependancy failure stated above. No point in opening a new bug for that since everyone is aware now. Thanks for your prompt help in pinpointing problem.
>>* gtk/gtkpathbar.c (gtk_path_bar_init): Reduce the inter-button spacing to 0. nice >>Get the path based on the currently focused widget, or the last-focused widget. nicer. should this logic not be extended to syncing the location when user clicks pathbar. Otherwise the file list does not reflect location bar address. suggest location bar visible on first use , the icon is less than obvious. If the user prefers no location bar once he has found the icon his prefs will be saved, but he should have full functionality straight away. would like to see more consistancy between the different modes (inversion of pathbar and location entry). Instead of learning one interface the user has to learn two. Great to see some contrete improvements in availablilty and usablility of text input though. Esp. the autocompletion is much nicer without dropdown. Nice work.
Wow and it only took two years! I think this shows that innovation is not a corporate process. Great work mate! I'll buy you all beers/ciders/colas =)
new button works well , nice layout. hwvr, the icon does not seem too helpful. It suggests and editor type program. I would suggest some form of keyboard or single keyboard key image may be more explicit. Or better an image of a text entry box since that is what it's really about. regards.
Why is it that the behavior is still virtually the same as the old behavior yet the bug is marked as fixed? The path bar if enabled completely dissallows moving the selection highlight with the arrows because it has "focus" if I click on an item the pathbar no longer has focus and I am back to the original problem that being the need for keyboard magic to get things going again or I must click in the field assuming the pathbar was set to visible in the first place which I don't even like. The dialog still makes an illogical distinction between files and folders which contributes to the inability to do the following: Click folder A and descend into it, type B/H to descend directly to B/H without having to click a button or the inside of a field. If I want to save an image for example I very rarely need to change the file name so I typically click somewhere outside of the pathbar to keep myself from accidentally getting rid of the file name given to me by the server it doesn't help me at all if I can't type A/B/Z unless I reposition the cursor in the path bar and then begin typing stuff. In fact if I even try to do that I would have to type out the entire destination so its easier to start off by clicking out of the pathbar and moving a bit closer to where I want a given file to actually end up before I start typing. This bug should not be marked fixed until the underlying issues with the behavior of the dialog are actually addressed. Putting a toggle for a pathbar still doesn't change the fact that the behavior of the dialog is at its core counter intuitive and counter productive.
I quite agree with your final point. This dialog is fundamentally misconceived but there is a mountain of resistance to evercome in getting the smallest changes accepted. As this thread clearly shows. This bug was originally about discoverability. While I would say that the icon on the new button looks more like it will launch a notepad editor than reveal an address bar, the original bug was addressed in some way and so kind of fixed. Even it took over two years to get a button added. Corprate ineria commes to Linux! If you wish to comment on another issue with the interface you may want to submit a new bug or add a comment to #331404 where I submitted a critique of the original design assumption of these pesky dialogues. It seems the original design study made some fairly gross assumption about what "most users" need and want. The hundreds of posts this thread has attracted suggest some of those ideas need to be reviewed.
*** Bug 378433 has been marked as a duplicate of this bug. ***
*** Bug 334333 has been marked as a duplicate of this bug. ***