Tails

#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?

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

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

#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.

#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.