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 779218 - File chooser dialog extends beyond screen, ignores size setting
File chooser dialog extends beyond screen, ignores size setting
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Widget: GtkFileChooser
3.22.x
Other All
: Normal major
: ---
Assigned To: gtk-bugs
: 773596 773747 785181 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2017-02-25 14:36 UTC by Felix E. Klee
Modified: 2018-05-02 18:11 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Full screen screenshot, showing missing elements in file chooser dialog (156.31 KB, image/png)
2017-02-25 16:12 UTC, Felix E. Klee
Details

Description Felix E. Klee 2017-02-25 14:36:41 UTC
Instructions on up-to-date Arch as of today:

    $ export GDK_SCALE=2
    $ gsettings set org.gtk.Settings.FileChooser window-size '(800,600)'
    $ gsettings get org.gtk.Settings.FileChooser window-size
    (800, 600)
    $ evince
    $ gsettings get org.gtk.Settings.FileChooser window-size
    (1203, 902)
    $ pkg-config --modversion gtk+-3.0
    3.22.8

As can be seen, when the evince starts, then the file chooser is reset to its original size. This also happens with other applications linked against GTK+ 3.

The file chooser extends in height beyond the size of the screen. Control buttons at the top and at the bottom are not reachable. With typical window managers, it cannot be moved either. In short:

The file chooser is unusable with GDK_SCALE=2!
Comment 1 Felix E. Klee 2017-02-25 16:12:42 UTC
Created attachment 346711 [details]
Full screen screenshot, showing missing elements in file chooser dialog

The file chooser dialog is pretty much useless like this. The window manager here is FVWM with my hiwiwi configuration <https://github.com/feklee/hiwiwi>, but the issue is independent of the window manager: I also see it with TWM in default configuration, for example.
Comment 2 Paul E. (Marbux) Merrell, J.D. 2017-02-25 20:43:20 UTC
Same bug also observed on Windows only using the *GTK2* NoteCase Pro outliner and Geany text editor. In those instances, the user can drag the top of the dialog down to resize, then raise the window to show the missing buttons. Bug is not present with those apps on Linux Mint 17.
Comment 3 Timm Bäder 2017-03-01 12:04:21 UTC
The gsettings keys GtkFileChooser{Widget,Dialog} uses are just a way for the filechooser to save its size so it can restore from that size. Setting them manually won't do much good in any case.

It might be that the calculation in https://git.gnome.org/browse/gtk+/tree/gtk/gtkfilechooserwidget.c#n6157 has to consider the display scale as well (?) or at least clamp the 2 values to the widget is never bigger than the workarea size.
Comment 4 Felix E. Klee 2017-03-01 20:48:24 UTC
Thing is, it worked in the past. The file chooser dialog stopped working with a recent update of Arch.

It is possible to open files and folders by double clicking. However, the controls for navigating a level up in the directory structure is outside of the screen.

Concerning a workaround: What can I tell users? Are there any other ways to navigate, e.g. by using key combinations?
Comment 5 Timm Bäder 2017-03-02 06:39:33 UTC
(In reply to Felix E. Klee from comment #4)
> Thing is, it worked in the past. The file chooser dialog stopped working
> with a recent update of Arch.

Bisecting that would be the only way to get a grip on the problem then.



> It is possible to open files and folders by double clicking. However, the
> controls for navigating a level up in the directory structure is outside of
> the screen.
> 
> Concerning a workaround: What can I tell users? Are there any other ways to
> navigate, e.g. by using key combinations?

You can use Alt+Left and Alt+Up iirc. Or just resize the window so it fits into the screen.
Comment 6 Felix E. Klee 2017-03-03 12:50:42 UTC
> Or just resize the window so it fits into the screen.

Not possible if the resize handles are outside of the screen.
Comment 7 Timm Bäder 2017-03-03 13:57:18 UTC
(In reply to Felix E. Klee from comment #6)
> > Or just resize the window so it fits into the screen.
> 
> Not possible if the resize handles are outside of the screen.

I do that every single day. Does your WM seriously not have a way of resizing windows without grabbing it on the window borders?

Anyway, other than that: No.
Comment 8 Felix E. Klee 2017-03-03 15:52:43 UTC
> I do that every single day. Does your WM seriously not have a way of
> resizing windows without grabbing it on the window borders?

Of course, but the top and bottom window borders are *both outside* of
the screen. That’s the problem!

I could set up some additional functions, but it would be confusing for
the users of the system.

> Anyway, other than that: No.

Well, I hope the bug will be fixed soon. It's a blocker.
Comment 9 Daniel Boles 2017-08-29 23:43:17 UTC
*** Bug 773596 has been marked as a duplicate of this bug. ***
Comment 10 Daniel Boles 2017-08-29 23:43:40 UTC
*** Bug 773747 has been marked as a duplicate of this bug. ***
Comment 11 Daniel Boles 2017-08-29 23:43:46 UTC
*** Bug 785181 has been marked as a duplicate of this bug. ***
Comment 12 GNOME Infrastructure Team 2018-05-02 18:11:34 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/771.