GNOME Bugzilla – Bug 773596
GtkFileChooser dialog won't fit in low screen resolutions
Last modified: 2017-08-29 23:43:17 UTC
The GtkFileChooser dialog does not fit properly in low screen resolutions. I have reproduced this on 720x480 and 640x480 pixels for the "save file" dialog. The dialog grows in size kind of unpredictably, at times, looks like a complete white window. We noticed this for one of our EndlessOS apps but later on gnome apps as well, e.g. gedit. I have spent some time dissecting the GtkFileChooserWidget and I think I spotted 3 issues in total, 2 of these issues can potentially affect any app using that dialog on low screen resolutions, and the last issue seems to be specific to our DPI setup for composite (tv) output. Issues that affect gnome apps (out-of-the-box): 1) The top GtkHeaderBar simply does not fit in 720 and 640 pixels width. 2) The bottom GtkActionBar for extra and filters, depending on how many extra widgets contains, won't fit in 720 and 640 pixels width. Issues that affect gnome and endless apps only when DPI is increased (e.g. *{-gtk-dpi: 120}): 3) The GtkPlacesSidebar takes too much horizontal space, because a) the current minimum width is 140 and seems already too big for such small resolutions plus bigger fonts sizes, and b) not all the rows labels can be ellipsized, and therefore these labels can't shrink. Quick fixes I am trying now for each of these issue: 1) Reducing the current GtkFileChooseEntry width-chars, enough so the top GtkHeaderBar can actually fit in. 2) Use a GtkScrolledWindow (vertical) to contain the action bar, and make it more resilient against this case. 3) Reduce the minimum width of the sidebar and make it so all the row labels can be ellipsized. A long term solution to replace the quick fix for 3) could be to support a "compact" mode in the GtkFileChooserWidget where the GtkPlacesSidebar would be permanently hidden or arranged differently, e.g. on top of the files GtkTreeView instead of using a GtkPaned. This could also be enabled/disabled via some property or settings key. More ideas and suggestions are welcome.
> 3) Reduce the minimum width of the sidebar and make it so all the row labels > can be ellipsized. This is part of the design, we really don't want to ellipsize the most important bookmarks. Otherwise the sidebar is kinda useless (so rather hide it entirely as you propose below) > > A long term solution to replace the quick fix for 3) could be to support a > "compact" mode in the GtkFileChooserWidget where the GtkPlacesSidebar would > be permanently hidden or arranged differently, e.g. on top of the files > GtkTreeView instead of using a GtkPaned. This could also be enabled/disabled > via some property or settings key. > I think this is a wider goal for GNOME, where sidebars could be hidden on demand and show on user gesture or so. Thinking about the new gnome-control-center design and Nautilus.
(In reply to Martin Abente Lahaye from comment #0) [...] > A long term solution to replace the quick fix for 3) could be to support a > "compact" mode in the GtkFileChooserWidget where the GtkPlacesSidebar would > be permanently hidden or arranged differently, e.g. on top of the files > GtkTreeView instead of using a GtkPaned. This could also be enabled/disabled > via some property or settings key. I think a way to hide the places sidebar without loosing functionality would be to move it to a combobox in the header bar. That way when the dialog is opened in recent view you can still navigate to other places :)
Created attachment 339032 [details] The places sidebar is hidden because both the sidebar and files treeview won't fit in together.
(In reply to Carlos Soriano from comment #1) > This is part of the design, we really don't want to ellipsize the most > important bookmarks. Otherwise the sidebar is kinda useless (so rather hide > it entirely as you propose below) I tested hiding the sidebar completely and noticed that it hurts to not be able to access bookmarks such as trash, removable drives, other locations, etc. (In reply to Juan Pablo Ugarte from comment #2) > I think a way to hide the places sidebar without loosing functionality would > be to move it to a combobox in the header bar. > > That way when the dialog is opened in recent view you can still navigate to > other places :) Sadly, as you clarified over chat, there is not much available space in the header bar in these low screen resolutions, at least not for wide widgets. I am implementing something in the middle of these suggestions, following other ideas I received from Juan Pablo later over chat. Since we can't make the sidebar and the files treeview fit in together all the time, we could make sure each one can fit in separately like this: 1) add a small toggle button to the header bar, so we can show/hide the places sidebar. 2) the places sidebar is hidden automatically when both can't fit in properly. 3) we make sure files treeview can give up space when the sidebar is shown. So the experience when using this dialog on low screen resolutions would be like this: 1) we open the dialog (the dialog verifies that both won't fit in together property and hides the sidebar). 2) then, we only see the header bar (with the toggle button), the files treeview in the middle taking all horizontal space (like the screenshot I shown above) , and the filters at the bottom. 3) but, when we need to access one of these bookmarks, we can click on the toggle button (then the files treeview will give up space while the sidebar is being shown). Not perfect, but hopefully a start, suggestions are welcome!
*** Bug 773747 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of bug 779218 ***