Mask tools don't work/block the UI in fullscreen mode
When I switch to fullscreen mode on macOS X, I am unable to edit some of the masks. It works in windowed mode, but it looks like selecting the ellipse mask tools blocks the UI, i.e. the UI is not updated anymore. When I go back to windowed mode, I can see, that masks have been added and that other changes I did by accident are applied as well (e.g. when I click on buttons in the not responding UI). But in fullscreen mode, nothing really changes. Fullscreen is my default mode of operation.
I noticed problems with mask in earlier versions of darktable. The brush masks previously showed the same/similar behavior, but now the ellipse masks seem to be effected. Circle and path masks seem unaffected as well (I never hat problems with these). Since I rarely used brush masks, I didn't report earlier.
#1 Updated by Christian Stussak almost 3 years ago
I just tested again in windowed mode and I noticed, that when I create a new ellipse mask and then hover over the area between the dashed and the solid line of the mask, the size of the darktable window changes. It resizes in horizontal direction only and becomes larger than the size of my screen. This doesn't happen with the other mask tools.
My guess is that this becomes a problem in fullscreen mode because the window size cannot be enlarged further. My screen resolution is 1680x1050 (native MacBook Pro ~2012).
#3 Updated by Christian Stussak almost 3 years ago
I did a couple of additional tests. The behavior is related to screen resolution. My MacBook has a native resolution of 1680x1050. If I attach an external FullHD (1920x1080) monitor and put darktable in fullscreen mode on that screen, the bug goes away.
I am also downloading a Linux ISO right now (Lubuntu 16.10) and will try if I can reproduce the bug there because my feeling is that bugs in the macOS version don't get a lot of attention.
#4 Updated by Christian Stussak almost 3 years ago
- File ellipse_mask_tool_affects_window_size_20170101.mp4 ellipse_mask_tool_affects_window_size_20170101.mp4 added
Ok, this was easy. I have a fresh Lubuntu 16.10 ISO running in Live mode in a VirtualBox VM + darktable 2.2.0 via this ppa: https://launchpad.net/~pmjdebruijn/+archive/ubuntu/darktable-release
In live mode, there is no dedicated graphics driver for VirtualBox and therefore, I am stuck at a low screen resolution of 1024x768.
I go to darkroom mode, select "drawn mask" for one of the modules and add an ellipse mask to the image. Whenever I move the mouse within the area covered by the ellipse, the size of the darktable window flips back and forth.
I attached a short screen recording to show what happens.
Even though the consequences are different for different platforms, I would argue, that this bug affects all platforms, not just macOS. On macOS, the UI is frozen after darktable tries to change the window size in fullscreen mode. In Linux, you can't use the ellipse mask tool either due to the permanent window size flipping. Maybe someone can change the "system" tag of this issue from "MacOS X" to "all" and adjust the title.
#6 Updated by Tobias Ellinghaus almost 3 years ago
- % Done changed from 20 to 100
- Status changed from Triaged to Fixed
Applied in changeset darktable|09f2c4e8a144cdc35bc432edda113ebef6a59ef7.
#7 Updated by Christian Stussak almost 3 years ago
I tested with recent 2.2.x branch (a1d8af3b244120686afc6a9d2ae821cc81a2dff8) and it works again on macOS. Thank you very much. I wouldn't have been able to figure this out by myself.
Translation to German is missing for the mask, though, but this will probably be fixed after the next string freeze, right?
I see that your solution is an immediate fix for the problem at hand, but is it really a robust long-term solution? Shouldn't the UI be immune to overlong strings or somehow handle them by itself, e.g. via truncation, automated line wrapping or self-scrolling text (like a ticker).
If I put darktable in windowed mode and play with the ellipse mask, I can still see the window size changing slightly. Probably, there are other strings that are too long or almost too long. If a strings causes a problem also depends on the width of the sidebars. I was able to trigger the bug again by choosing wider sidebars. A small change in one of the strings can also trigger the bug again. On macOS, this is a blocker (UI freeze) and I am not sure about other platforms (what happens on wayland?). I would argue, that this problem will pop up randomly in the future if the UI doesn't provide a general way to deal with such cases properly.
#8 Updated by Christian Stussak almost 3 years ago
gtk_label_set_ellipsize (GtkLabel *label, PANGO_ELLIPSIZE_END) on all problematic labels could be a long-term workaround. Part of the help text might be missing then, but that's still better than having a frozen UI or permanent window size changes on every mouse movement.
#9 Updated by Tobias Ellinghaus almost 3 years ago
Yes, ellipsizing them would have been the next step but fixing the problem at hand was more pressing than the real fix. Especially as breaking the line would be needed even with the ellipsis added.
I am not aware of a marquee like widget in GTK so regular ellipsizing is the best we can do.