After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 486839 - Filechooser 'Places' items should not move up and down the whole UI when selected
Filechooser 'Places' items should not move up and down the whole UI when sele...
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: GtkFileChooser
2.18.x
Other Linux
: Normal normal
: ---
Assigned To: Milan Bouchet-Valat
Federico Mena Quintero
: 488810 538281 555202 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2007-10-15 14:18 UTC by Sebastien Bacher
Modified: 2010-09-13 20:02 UTC
See Also:
GNOME target: ---
GNOME version: 2.19/2.20


Attachments
add a padding label in recently used mode (2.01 KB, patch)
2007-10-21 15:18 UTC, Emmanuele Bassi (:ebassi)
none Details | Review
related to comment #6. (53.22 KB, image/png)
2008-03-13 11:05 UTC, antistress
  Details
Patch against gtkfilechooserdefault.c in trunk (3.23 KB, patch)
2009-03-03 22:56 UTC, Milan Bouchet-Valat
none Details | Review
Screenshot of the search mode (34.96 KB, image/png)
2009-03-03 22:57 UTC, Milan Bouchet-Valat
  Details
Patch against gtkfilechooserdefault.c and gtkfilechooserprivate.h in trunk (3.89 KB, patch)
2009-03-03 23:01 UTC, Milan Bouchet-Valat
none Details | Review
FileChooser screenshot frm upcoming ubuntu 9.10 Karmic (176.22 KB, image/png)
2009-09-29 22:15 UTC, antistress
  Details
File Chooser on Karmic, "high contrast" theme (17.46 KB, image/png)
2009-10-04 23:10 UTC, antistress
  Details
Fix-path-bar-size-group-in-the-file-chooser.patch (3.51 KB, patch)
2009-10-07 20:26 UTC, Milan Bouchet-Valat
none Details | Review
Screenshot of open mode in recent and browse with patch (121.31 KB, image/png)
2009-11-25 22:50 UTC, Milan Bouchet-Valat
  Details
Screenshot of save mode in recent and browse with patch (131.14 KB, image/png)
2009-11-25 22:51 UTC, Milan Bouchet-Valat
  Details
Screenshot of save mode in recent and browse with patch (107.37 KB, image/png)
2009-11-26 10:11 UTC, Milan Bouchet-Valat
  Details

Description Sebastien Bacher 2007-10-15 14:18:45 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?"
Comment 1 Matthias Clasen 2007-10-16 18:11:47 UTC
Sounds like a good idea, in general. 
Comment 2 Emmanuele Bassi (:ebassi) 2007-10-21 13:36:17 UTC
*** Bug 488810 has been marked as a duplicate of this bug. ***
Comment 3 Emmanuele Bassi (:ebassi) 2007-10-21 13:38:56 UTC
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.
Comment 4 Emmanuele Bassi (:ebassi) 2007-10-21 15:18:03 UTC
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.
Comment 5 Milan Bouchet-Valat 2008-02-04 09:20:32 UTC
Any news on this bug? Isn't it possible to add padding around the label to solve the size issue?
Comment 6 antistress 2008-03-13 11:03:53 UTC
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
Comment 7 antistress 2008-03-13 11:05:58 UTC
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
Comment 8 antistress 2008-06-14 00:18:12 UTC
to my mind this really is a major usabilty problem : anything new about that ?
Comment 9 Carlos Garnacho 2008-06-14 12:03:42 UTC
*** Bug 538281 has been marked as a duplicate of this bug. ***
Comment 10 Milan Bouchet-Valat 2009-03-03 22:55:14 UTC
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! ;-)

Comment 11 Milan Bouchet-Valat 2009-03-03 22:56:07 UTC
Created attachment 129976 [details] [review]
Patch against gtkfilechooserdefault.c in trunk
Comment 12 Milan Bouchet-Valat 2009-03-03 22:57:33 UTC
Created attachment 129977 [details]
Screenshot of the search mode
Comment 13 Milan Bouchet-Valat 2009-03-03 23:01:16 UTC
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.
Comment 14 Milan Bouchet-Valat 2009-04-26 12:15:45 UTC
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! ;-)
Comment 15 Federico Mena Quintero 2009-06-12 00:44:51 UTC
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...
Comment 16 Milan Bouchet-Valat 2009-06-12 10:05:10 UTC
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?

Comment 17 Federico Mena Quintero 2009-06-12 16:41:34 UTC
(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.]
Comment 18 Milan Bouchet-Valat 2009-06-12 22:38:34 UTC
*** Bug 555202 has been marked as a duplicate of this bug. ***
Comment 19 Milan Bouchet-Valat 2009-06-12 23:16:41 UTC
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.
Comment 20 Milan Bouchet-Valat 2009-06-29 19:31:58 UTC
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.
Comment 21 antistress 2009-09-29 22:13:02 UTC
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)
Comment 22 antistress 2009-09-29 22:15:21 UTC
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
Comment 23 Milan Bouchet-Valat 2009-09-30 07:50:28 UTC
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.
Comment 24 antistress 2009-10-04 23:10:27 UTC
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)...
Comment 25 antistress 2009-10-05 23:19:38 UTC
shall i fill a bug against Ubuntu's theme ?
Comment 26 Milan Bouchet-Valat 2009-10-06 11:42:25 UTC
Absolutely not, that must be the file chooser's fault. I'll see what we can do soon. Thanks for the details!
Comment 27 Milan Bouchet-Valat 2009-10-07 20:26:35 UTC
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?
Comment 28 Milan Bouchet-Valat 2009-11-25 22:50:55 UTC
Created attachment 148493 [details]
Screenshot of open mode in recent and browse with patch
Comment 29 Milan Bouchet-Valat 2009-11-25 22:51:17 UTC
Created attachment 148494 [details]
Screenshot of save mode in recent and browse with patch
Comment 30 Matthias Clasen 2009-11-25 23:04:14 UTC
Out of curiosity, did you try gtk_size_group_set_ignore_hidden ?
That should have worked too, I think.
Comment 31 Milan Bouchet-Valat 2009-11-26 10:06:01 UTC
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.
Comment 32 Milan Bouchet-Valat 2009-11-26 10:11:29 UTC
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...
Comment 33 Milan Bouchet-Valat 2010-08-31 07:33:09 UTC
Federico, any chance you review this trivial patch? It's been almost a year! ;-)
Comment 34 Federico Mena Quintero 2010-09-13 19:48:56 UTC
Beautiful.  It works perfectly.  Thanks, Milan!  I've just pushed this to master and gtk-2-22.
Comment 35 Milan Bouchet-Valat 2010-09-13 20:02:16 UTC
At last! Great! Now I can find other bugs in the file chooser to dig up...