GNOME Bugzilla – Bug 486839
Filechooser 'Places' items should not move up and down the whole UI when selected
Last modified: 2010-09-13 20:02:16 UTC
The bug has been opened on https://bugs.launchpad.net/bugs/152593 "The new implementation of the GtkFilechooser (2.12) is great: we now have 'Recent files' and 'Search' in the 'Places' bar. But these two new items don't need the same UI space at th top of the selector. So when you click them, they move up, and when you choose a standard location, they move down, and the whole file list goes with them. For example, when you click 'Recent', your mouse lands up on 'Home', and vice-versa. This is not convenient for the user, it makes us lose our marks! Space used at the top of the selector should be made the same so that the items never move a pixel. This is a standard behavior to help processing efficiently tasks. This should be a rule of the HIG. I hope somebody here has got ways to contact some GNOME developers, because this may be fixed simply with a little padding: - for the 'Search' item, only a few pixels must be added, almost unnoticeable for the UI design - for the 'Recent' item, maybe a label repeating 'Recently used files' could simply be added to stabilize the widgets' position. With search this label already appears together with a textbox (needed to type the keywords), and with standard locations, the filesystem hierarchy is shown. An redundant label would not harm much, and would be very useful to make the Filechooser easier to use. Anybody supporting this?"
Sounds like a good idea, in general.
*** Bug 488810 has been marked as a duplicate of this bug. ***
adding a padding label when in recently used mode seems the cleanest solution. I decided to simply hide the box containing the search entry/path bar because there's no equivalent when in recently used mode. anyway, assigning to me; will attach a patch here.
Created attachment 97557 [details] [review] add a padding label in recently used mode this patch adds a padding label. problem is: the widgets still jump around a bit, since a GtkEntry has a bigger height than a label.
Any news on this bug? Isn't it possible to add padding around the label to solve the size issue?
i was about to make a similar report : This bug report may concern both usabilty and accessibilty The window presentation is contextual, and that is great : - while selecting a directory, you can see at the top of the window the navigation buttons - while selecting "Search" option, you can see at the top of the window the search field - while selecting "Recently Used" option, nothing is showed at the top of the window since that function doesn't need any extra contextual GUI BUT the content of the "Open File" window resizes itself when selecting differents functions : for exemple, the Places panel goes up when selecting "recently used" and goes down when selecting another option (to allow displaying extra contextual GUI). The user loses one's points of reference : he may click on the wrong option since the option behind its pointer changes although the user doesn't move the pointer. I've attached a screenshot (OpenFileWindows.png) that show 3 different behaviours of the "Open File" window (with desktop directory selected, with Search selected, with Recently Used selected) and i've drawn an horizontal line that could represent a fixed pointer position on the screen. See that the graphical object under the pointer/line changes I think this behaviour breaks the 1st (although implicit) GUI rule : Graphical elements don't move behind the pointer, that's the pointer which moves over them. Graphical objets coordinates (X,Y) on the screen should not change unless the user moves them on purpose ("drag and drop" etc.) Users who make fast clicks or users who are not at ease with a pointer may be embarassed with that Therefore i suggest to fix the size content of the "Open File" window even when selecting different functions. For instance, when changing the current selection from "Search" to "Recently Used", the window should display an equivalent blank space of the Search field instead of reducing that part of the window. Thank you
Created attachment 107212 [details] related to comment #6. That screenshot shows 3 different behaviours of the "Open File" window (with desktop directory selected, with Search selected, with Recently Used selected) and i've drawn an horizontal line that could represent a fixed pointer position on the screen. See that the graphical object under the pointer/line changes
to my mind this really is a major usabilty problem : anything new about that ?
*** Bug 538281 has been marked as a duplicate of this bug. ***
I've worked on that issue from the patch Emmanuele proposed a long time ago, and I've got to a nice result that fixes most of the problems mentioned in this bug. In addition to the labels, I've used icons, and used a GtkSizeGroup so that they are the same height as location_button. There's no movement at all when switching from browsing to search and recent files. I've also used bold fonts so that the labels don't look to ridiculous, but that's obviously an option. See the screenshot for an idea of how it looks. I think it's pretty finalized, but here are some "concerns": - Please check that the dialog does not fill all the screen at start because of the patch. I'm seeing this on my box, but I can't find if it's because of the patch. Normally it shouldn't since the GtkSizeGroup is only vertical. - I'd have loved to set a padding for the icons so that they are placed exactly at the same location as the location_button icon. I could not find the property that gives the padding used by the button, so I only used a hardcoded 5px padding, which is nice (we need not to be aligned with the bookmarks pane's border), but may not be exactly the same with custom themes. I could not check that, maybe that's not a real problem. Else, hints are warmly accepted. - When you show the path entry, you lose the advantage of padding, and the behavior suffers from the same issues as before when going from browsing to {recent,search}. Obviously, padding a whole entry would be a waste of space. That's not a bug but a design limitation I don't think we can solve. This is all! Please test, criticize my coding style and report! ;-)
Created attachment 129976 [details] [review] Patch against gtkfilechooserdefault.c in trunk
Created attachment 129977 [details] Screenshot of the search mode
Created attachment 129978 [details] [review] Patch against gtkfilechooserdefault.c and gtkfilechooserprivate.h in trunk Oops! As always, I forgot a part of the patch. This version includes gtkfilechooserprivate.h too.
I guess we're in the right period to review this kind of little feature, isn't it? Please don't let my patch rot for 6 months! ;-)
Thanks, Milan! Committed as de280cc5c81c959786bbdd4325348ed07644e770 I made the following changes to your patch: * Make the size group be declared with type GtkSizeGroup * in the struct GtkFileChooserDefault (that was wrong; size groups are not GtkWidgets), and removed the unnecessary casts to GTK_SIZE_GROUP(). * Unref the size group in gtk_file_chooser_default_finalize(), not immediately after creating it, as it is also used by other functions. The object would still be alive then, but it's a good idea not to lose a reference until you actually not need it anymore. * Create the size group in browse_widgets_create(), not in the function specific to the location button. This works very nicely if the Location button is inactive --- that is, if the location entry is not being shown. In that case, the path bar's area indeed doesn't change its vertical size when you switch between browse/search/recently-used. However, if you enable the Location entry, the path bar's area still jumps when moving away or into Browse mode. Should we put the whole GtkPathBar and the location entry inside the size group? Milan, could you play with that and see if it works nicely? Maybe we can just de-sensitize the Location entry instead of hiding it...
Great, thanks! Funny how I managed to cast an incompatible pointer type to anything I wanted to have... how evil is C! :-p > Should we put the whole GtkPathBar and the location entry inside the size > group? > Milan, could you play with that and see if it works nicely? Maybe we can just > de-sensitize the Location entry instead of hiding it... That should work. But there's another solution that would be to replace the button with the entry, instead of showing both. That way, the entry would become the search entry, or would be hidden in recent mode. I'm not sure people use the path buttons and the entry at the same time. What do you think?
(In reply to comment #16) > That should work. But there's another solution that would be to replace the > button with the entry, instead of showing both. That way, the entry would > become the search entry, or would be hidden in recent mode. I'm not sure people > use the path buttons and the entry at the same time. What do you think? I'd like to keep the entry and path buttons at the same time. The buttons are the only thing that show you your current directory. Replacing the Location button with the entry is certainly interesting. Do you have some time to see if this works out nicely? [You may want to create a Git clone of the GTK+ repository, say, at gitorious.org or github, so that we can experiment with that branch there.]
*** Bug 555202 has been marked as a duplicate of this bug. ***
I can see what that looks like, though my concerns are that 1) the line may not be wide enough to fit all these informations, and 2) the entry will be larger than the button, making the path bar to move right - that may not really be a problem if you don't switch often, but the visual effect won't be very nice. I'm not using the path entry generally, so you may understand these issues better than I do. I'll report when I've tried something, that won't be immediately though. Depending on the size of the patch, maybe a branch won't be necessary.
Federico: actually, I've been thinking about this since my last comment, and I don't really see what design you have in mind. Do you ask me to put the location entry on the same line as the path bar? I really fear there isn't enough space for that.
on Ubuntu 9.10 Karmic alpha, the bug is not totally fixed : Filechooser 'Places' items don't move anymore while switching from Search to RecentFiles (thanks for that) but it still moves a bit while switching from one of them to another category (home or video or music etc)
Created attachment 144311 [details] FileChooser screenshot frm upcoming ubuntu 9.10 Karmic Bug is not fixed when you switch from Search or Recent to another item
Funny, I'm only able to reproduce this behavior in save mode here. So I guess there are two bugs to fix: - yours must be about margins not included in the size group because they come from a GtkBox, or something. Could you compare with other themes? - mine (in save mode) must come from the fact that location_button is not created/mapped there, so the size group is not used In both cases, using the GtkHBox that includes all the top buttons should help. I'll give it a try.
Created attachment 144750 [details] File Chooser on Karmic, "high contrast" theme Indeed on Karmic the bug only occurs with "Human", "high contrast" and "high contrast big size" Note that "high contrast" and "high contrast big size" have other problems ("recent files" and "search" entries sizes are not proprtional)...
shall i fill a bug against Ubuntu's theme ?
Absolutely not, that must be the file chooser's fault. I'll see what we can do soon. Thanks for the details!
Created attachment 144988 [details] [review] Fix-path-bar-size-group-in-the-file-chooser.patch So attached is a little patch that should fix both (relatively distinct) issues. First problem, the location button is not visible in save mode, and then it was not setting the size of the padding icons properly. I've added the path bar to the size group so that it always works. I have kept the location button in the size group because it seems to be higher than the bar, thus it is required when visible. Second problem, the whole bar space is a GtkHBox in which are packed the location button, the path bar, or the recent/search boxes, which in turn contain the icon and label. So using the size of the location button (or bar) for the icon is not right in some cases, where the box spacing is not the same as the button's. So now the recent/search boxes are added to the size group instead of their children icons. Seems to work right. Federico, are you OK to commit this? Could it go into stable too, or isn't it worth the risk?
Created attachment 148493 [details] Screenshot of open mode in recent and browse with patch
Created attachment 148494 [details] Screenshot of save mode in recent and browse with patch
Out of curiosity, did you try gtk_size_group_set_ignore_hidden ? That should have worked too, I think.
Yeah, this is already done by the already-committed patch. The reason why it was not sufficient is that the location button was used to force the height of the path bar to a sufficient size. When it was hidden, it was not playing this role anymore. That's the meaning of my first sentence in the commit message. Anyway I think I'll rephrase that message because I already find it very hard to understand. This is really tricky, so better document it precisely.
Created attachment 148516 [details] Screenshot of save mode in recent and browse with patch New screenshot for save mode, I had posted twice the same image...
Federico, any chance you review this trivial patch? It's been almost a year! ;-)
Beautiful. It works perfectly. Thanks, Milan! I've just pushed this to master and gtk-2-22.
At last! Great! Now I can find other bugs in the file chooser to dig up...