Project

General

Profile

Bug #16807

Impossible to maximize GIMP and see all its widgets in some screen resolutions

Added by sajolida 5 months ago. Updated about 2 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
-
Target version:
Start date:
Due date:
% Done:

0%

Feature Branch:
bugfix/16807-impossible-to-maximize-gimp
Type of work:
Code
Blueprint:
Starter:
Affected tool:

Description

In bc022ef71e I can't maximize GIMP (the "Maximize" option of GNOME is deactivated) and the window is cropped at the bottom and I can't access all the widgets in the window.

Upstream issues:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=701903
https://gitlab.gnome.org/GNOME/gimp/issues/535

Screenshot_tails-buster-3.17-20190711T2034Z-bd70bf68ef-GIMP-on-1280x800.png View (102 KB) segfault, 07/14/2019 02:57 PM

gimp.png View (129 KB) sajolida, 07/20/2019 05:59 PM


Related issues

Blocks Tails - Feature #16209: Core work: Foundations Team Confirmed

Associated revisions

Revision d506334b (diff)
Added by segfault 2 months ago

Increase left dock width in GIMP's sessionrc (refs: #16807)

History

#1 Updated by intrigeri 5 months ago

(the "Maximize" option of GNOME is deactivated)

I can reproduce this but only with a very low screen resolution that's pretty rare on hardware less than 10 years old. Otherwise the "Maximize" option is available and the corresponding square button is visible in the title bar.

and the window is cropped at the bottom and I can't access all the widgets in the window.

Ouch :/

So, I'm afraid GIMP's "Single-Window Mode" (configurable in the "Windows" menu), which is now enabled by default, does not correctly support this kind of screen resolution. What we could do:

  • In any case, ensure this is known upstream.
  • Decide that better support for rare low screen resolution is worth reverting upstream's switch to "Single-Window Mode", at the risk of losing a UX improvement for everyone else (I find the single-window mode way more usable myself).
  • Given the defaults will work fine for the vast majority of our users, and disabling single-window mode is 2 clicks, decide that sorry, too bad, folks with this kind of rare low screen resolutions will need to disable single-window mode themselves.

@sajolida, now that I've clarified what subset of our users is affected either way, what do you think?

#2 Updated by sajolida 5 months ago

I can reproduce this but only with a very low screen resolution that's pretty rare on hardware less than 10 years old.

I have 1280x800 on my Thinkpad which is... close to 10 yo indeed :)

But from the Mozilla hardware database 30% of Firefox users these days have 1366x766 displays (HD 720p) and would be affect by this bug:

https://data.firefox.com/dashboard/hardware

What made you think that is was "rare"?

I love the single-window mode of GIMP and always switch it on (with no problem) in Tails 3.x.

"Fun" fact, elouann proposed it as an improvement for Tails at the 2016 summit and we rejected it.

  • In any case, ensure this is known upstream.

Who does that?

#3 Updated by intrigeri 5 months ago

#4 Updated by intrigeri 5 months ago

  • Status changed from New to Confirmed

But from the Mozilla hardware database 30% of Firefox users these days have 1366x766 displays (HD 720p) and would be affect by this bug: https://data.firefox.com/dashboard/hardware

Thanks!!! We should definitely add a link to this tool somewhere and either way, I really should get used to looking there.

What made you think that is was "rare"?

Silly guesses not backed with any actual data :]

I love the single-window mode of GIMP and always switch it on (with no problem) in Tails 3.x.

Ah, then it's a regression in the single-window mode. I was incorrectly assuming you were using the default (non-single-window) mode in 3.x and that the only regression here was switching by default to a mode that's broken for you.

  • In any case, ensure this is known upstream.

Who does that?

FT

#5 Updated by segfault 4 months ago

I can't reproduce this with an image built from the latest buster branch in a VM with a resolution of 1280x800. I don't see any cropped widgets. Attaching a screenshot.

#6 Updated by sajolida 4 months ago

It's still the case for me on my spare X201 in a64f183bae. See screenshot in attachment.

#7 Updated by sajolida 4 months ago

I cannot maximize either on a X200 and the MacBook Pro.

#8 Updated by segfault 3 months ago

  • Description updated (diff)

I was able to reproduce this on other hardware. A quick research showed that this is a known issue since 2013, see the links I added to the description. The workaround by Nils Philippsen on the GNOME issue works for me:

Here's a workaround: After step 3, there's a handle to the right side of the tool options dockable. Drag it to the right, creating some space for the toolbar so it can use additional columns. Then you should be able to reduce the window height, or maximize it.

#9 Updated by intrigeri 3 months ago

I don't see us prioritizing this enough to fix it upstream any time soon.

So our options seem to be:

  • Decide that better support for low screen resolution is worth reverting upstream's switch to "Single-Window Mode". This reverts a UX improvement for everyone else (everybody here seems to agree that single-window mode is much more usable).
  • Keep single-window mode enabled and hope that affected users find one of the 3 workarounds (revert to multi-windows mode, hide docks as mentioned on the Debian bug report, and the one segfault pointed to) by themselves.
  • Keep single-window mode enabled and document one of these workarounds.
  • Select multi-window mode automatically on low screen resolutions, except when the user has made their Gimp configuration persistent (then we can assume that they want to control their settings themselves). That probably does not require lots of work but I'm not sure whether it's the best use of our resources in the next 1.5 month.

@sajolida, what do you think?

#10 Updated by segfault 3 months ago

intrigeri wrote:

  • Keep single-window mode enabled and hope that affected users find one of the 3 workarounds (revert to multi-windows mode, hide docks as mentioned on the Debian bug report, and the one segfault pointed to) by themselves.

When I tried to use the workaround from the Debian bug report (by hiding the docks, maximizing the window, then showing the docks again), I had the "the window is cropped at the bottom and I can't access all the widgets in the window" issue.

  • Select multi-window mode automatically on low screen resolutions, except when the user has made their Gimp configuration persistent (then we can assume that they want to control their settings themselves). That probably does not require lots of work but I'm not sure whether it's the best use of our resources in the next 1.5 month.

I don't think it's the best use of our resources.

#11 Updated by sajolida 2 months ago

  • Keep single-window mode enabled and hope that affected users find one of the 3 workarounds (revert to multi-windows mode, hide docks as mentioned on the Debian bug report, and the one segfault pointed to) by themselves.

I'm not sure if it's the same as the one segfault pointed to but a
workaround is to make the left column a bit wider so it can fit more
columns.

Could we automate this by configuring the left column to be a tiny bit
wider in Tails by default?

  • Keep single-window mode enabled and document one of these workarounds.

We should at least do this for our help desk.

#12 Updated by intrigeri 2 months ago

Could we automate this by configuring the left column to be a tiny bit wider in Tails by default?

Good question! Let's try this :)

#13 Updated by segfault 2 months ago

intrigeri wrote:

Could we automate this by configuring the left column to be a tiny bit wider in Tails by default?

Good question! Let's try this :)

The relevant file is ~/.config/GIMP/2.10/sessionrc, which contains information about the window layout. If the file doesn't exist when GIMP starts (i.e. when GIMP is started for the first time), default valued are used instead, which are chosen based on the current screen resolution. Everytime GIMP is closed, this file is automatically re-written.

The relevant line for the left dock is (left-docks-width "188").

When I create a sessionrc which only contains the left-docks-width entry (and it's parent entries), like this:

(session-info "toplevel" 
    (aux-info
        (left-docks-width "188")

then the GIMP window is empty, because the other values are missing and are not replaced by the defaults.

So in order to set the left-docks-width entry, we would have to (1) somehow generate the sessionrc file when GIMP is started for the first time, or (2) ship a sessionrc file. (1) seems like a lot of effort to me. And with (2) I also see problems:

  • We would have to choose values which work for all supported screen resolutions, because GIMP won't choose sane default values if the sessionrc file exists. The values which seem to depend on the screen resolution are:
    • window size
    • window position
    • maximized ("yes" for small resolutions, else "no")

    What we could try here is to simply set maximized to "yes", then the size and position values don't matter.

  • If upstream changes default values, we would overwrite them with the old values, so we would need a mechanism to check if the defaults have changed in upstream and then adapt our sessionrc.

#14 Updated by intrigeri 2 months ago

Thanks segfault for doing this research!

So in order to set the left-docks-width entry, we would have to (1) somehow generate the sessionrc file when GIMP is started for the first time, or (2) ship a sessionrc file.

(1) seems like a lot of effort to me.

IMO it's not worth it, by far.

And with (2) I also see problems:
  • We would have to choose values which work for all supported screen resolutions, because GIMP won't choose sane default values if the sessionrc file exists.

Wait, I see stuff in /etc/gimp/2.0/sessionrc. I did not test at all, but I would venture this guess: the per-user sessionrc, if it does not exist yet when GIMP is started, is created by copying that file into $HOME. If this guess is correct, then we could sed/perl (left-docks-width "188") at build time in a hook.

Would this be good enough? Would we also need to enable "maximized" to make things work more nicely on various resolutions?

#15 Updated by intrigeri 2 months ago

If one of these cheap fixes works and is implemented in time for 4.0, nice. Otherwise, let's document the workarounds.

#16 Updated by segfault 2 months ago

  • Status changed from Confirmed to In Progress

#17 Updated by segfault 2 months ago

  • Assignee set to segfault
  • Feature Branch set to bugfix/16807-impossible-to-maximize-gimp

#18 Updated by segfault 2 months ago

  • Assignee changed from segfault to sajolida

#19 Updated by sajolida about 2 months ago

I tested on a VM with 1280x666 and it works. I'll confirm again when running RC1 on my machine.

#20 Updated by intrigeri about 2 months ago

  • Status changed from In Progress to Needs Validation
  • Assignee changed from sajolida to intrigeri

Thanks!

#21 Updated by intrigeri about 2 months ago

  • Subject changed from Impossible to maximize GIMP and see all its widgets to Impossible to maximize GIMP and see all its widgets in some screen resolutions

#22 Updated by intrigeri about 2 months ago

  • Status changed from Needs Validation to Resolved

Also available in: Atom PDF