Project

General

Profile

Bug #11387

Mask tools don't work/block the UI in fullscreen mode

Added by Christian Stussak over 2 years ago. Updated over 2 years ago.

Status:
Fixed
Priority:
Low
Assignee:
-
Category:
Darkroom
Target version:
Start date:
12/25/2016
Due date:
% Done:

100%

Affected Version:
git master branch
System:
all
bitness:
64-bit
hardware architecture:
amd64/x86

Description

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.

darktable.log Magnifier - darktable -d all >darktable.log 2>&1 (557 KB) Christian Stussak, 12/25/2016 02:16 PM

ellipse_mask_tool_affects_window_size_20170101.mp4 - Screen recording showing how the ellipse mask tool affects window size (1010 KB) Christian Stussak, 01/01/2017 07:50 PM

Associated revisions

Revision 09f2c4e8
Added by Tobias Ellinghaus over 2 years ago

masks: Make ellipse help text 2 lines

Fixes #11387

Revision a1d8af3b
Added by Tobias Ellinghaus over 2 years ago

masks: Make ellipse help text 2 lines

Fixes #11387

(cherry picked from commit 09f2c4e8a144cdc35bc432edda113ebef6a59ef7)

History

#1 Updated by Christian Stussak over 2 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).

#2 Updated by Christian Stussak over 2 years ago

Can anyone at least confirm that this is a bug?

#3 Updated by Christian Stussak over 2 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 over 2 years ago

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.

#5 Updated by Tobias Ellinghaus over 2 years ago

  • Affected Version changed from 2.2.0 to git master branch
  • System changed from Mac OS X to all
  • % Done changed from 0 to 20
  • Status changed from New to Triaged

It's the help text in the header which is just one giant line.

#6 Updated by Tobias Ellinghaus over 2 years ago

  • % Done changed from 20 to 100
  • Status changed from Triaged to Fixed

#7 Updated by Christian Stussak over 2 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 over 2 years ago

Maybe setting 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 over 2 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.

#10 Updated by Roman Lebedev over 2 years ago

  • Target version set to 2.4.0

Also available in: Atom PDF