Bug #16807

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

Added by sajolida 2019-06-12 15:29:43 . Updated 2019-09-20 09:37:00 .

Status:
Resolved
Priority:
Normal
Assignee:
intrigeri
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:
Deliverable for:

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


Files


Subtasks


Related issues

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

History

#1 Updated by intrigeri 2019-06-17 09:29:14

> (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 2019-06-17 15:29:51

> 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 2019-06-17 16:00:47

#4 Updated by intrigeri 2019-06-17 16:01:38

  • 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 2019-07-14 14:57:25

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 2019-07-20 17:59:22

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

#7 Updated by sajolida 2019-07-20 18:48:31

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

#8 Updated by segfault 2019-08-29 17:22:10

  • Description updated

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 2019-08-30 09:02:54

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 2019-08-31 01:22:55

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 2019-09-04 09:40:49

> * 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 2019-09-04 09:55:02

> 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 2019-09-05 11:09:05

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 2019-09-12 12:24:23

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 2019-09-12 12:59:06

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 2019-09-12 16:58:02

  • Status changed from Confirmed to In Progress

Applied in changeset commit:tails|d506334be93d56b54428654d784782e17bc4212a.

#17 Updated by segfault 2019-09-12 16:59:05

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

#18 Updated by segfault 2019-09-15 13:43:26

  • Assignee changed from segfault to sajolida

@sajolida, could you test if this image fixes the problem on your devices?

https://nightly.tails.boum.org/build_Tails_ISO_bugfix-16807-impossible-to-maximize-gimp/builds/2019-09-14_16-47-01/archive/latest.iso

#19 Updated by sajolida 2019-09-19 19:53:07

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

#20 Updated by intrigeri 2019-09-20 06:27:46

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

Thanks!

#21 Updated by intrigeri 2019-09-20 09:01:45

  • 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 2019-09-20 09:37:00

  • Status changed from Needs Validation to Resolved