Bug #12387

Drawing mask / spot removal: Bug when moving shapes

Added by Stefan Klinger 17 days ago. Updated 6 days ago.

Target version:
Start date:
Due date:
% Done:


Affected Version:
git master branch
other GNU/Linux
hardware architecture:


When trying to create a gradient for a drawn mask, or a shape for spot removal, I find it difficult to move around these shapes. A first click on the center line of a gradient, or on the “copy from” circle in spot removal, will make this shape jump away from the cursor.

Steps to reporduce: E.g. in darkroom module 'tone curve', select 'blend → drawn mask', then the gradient symbol, place gradient on photo, rotating gradient via the small hadles works, but when clickin on the center line it is displaced from the pointer. Drag mouse while keeping button pressed will move the gradient at its new position with different speed.

Similar for spot removal.

I have two demo videos temporarily available here [[]]. Should I upload them to the bugtracker? I'm concerned about the filesize.

Affected version:

$ git describe


#1 Updated by Pascal Obry 16 days ago

Can't reproduce. What DE are you using?

#2 Updated by Stefan Klinger 15 days ago

I need to correct myself: Above' I've said “Drag mouse while keeping button pressed will move the gradient at its new position with different speed.” but the speed is actually the same (I guess). But the shape is offset and impossible to move to the upper half of the image.

Pascal Obry wrote:

What DE are you using?

DE as in Desktop Environment ? None, if you're asking for an implementation of the desktop metaphor. It's only X11 and the FVWM window manager, so nothing fancy.

I compile from the `master` branch using a shell script like this:

cd /home/sk/source/dt/;

git clean -xdf;
git co master;
git pull;
git submodule update --recursive;

#git co my-mods;
#git rebase master;


disable=(flickr libsecret kwallet unity tethering);

./ -j "$(nproc)" \
           --prefix ${prefix} \
           "${disable[@]/#/--disable-}" \
           --buildtype Release

cmake --build './build' --target install -- -j "$(nproc)" 

I've just confirmed the error is still present with `master` at commit `abecd987b`:

$ git describe

Your asking about desktop environment (I guess) made me curious, and I removed `unity` from the `disable` list. The error still persists.

Anything else I can help with?


#3 Updated by Pascal Obry 14 days ago

So I could guess that FVWM is probably the culprit here. Can you test with another WM?

#4 Updated by Stefan Klinger 14 days ago

Pascal Obry wrote:

So I could guess that FVWM is probably the culprit here. Can you test with another WM?

I've tested woth Openbox, and the error disappeared.

Do you have any idea where this comes from? Is this an FVWM bug (it seems to be unknown)? Darktable is the only program I use that shows pointer offset issues.

#5 Updated by Andreas Schneider 14 days ago

Pascal, I had the same issue. When you draw a shape then try to move the "copy-shape" it jumps out of the window. Running KDE Plasma here. I can't always reproduce it.

#6 Updated by Pascal Obry 13 days ago

Don't know about KDE or FVWM as I use GNOME. As an heavy user of darktable I have never seen a jump like that. So yes, I do think this is related to the WM used. Is that a bug on the WM? Probably so, but until this is tracked down by a dev using those WM it is hard to tell.

#7 Updated by Stefan Klinger 13 days ago

Ok, so I'm also going to ask the FVWM folks about this.

I've figured out that the observed bug is linked to exactly one of my FVWM settings: I have configured FVWM to capture a left mouse click/drag on a window when the Hyper modifier (aka. Windows key or logo key) is held down. In that case, the window is raised (click) or moved along with the mouse pointer (drag).

When I disable this particular binding, the jumping disappears. FVWM allows to do so during runtime using FvwmCommand(1) on the command line:

$ FvwmCommand 'mouse 1 A 4'

When I enable this binding, the jumping appears again.

$ FvwmCommand 'mouse 1 A 4 moveOrRaise'

No other of my FVWM settings had this effect, and this is reproducible. I have made a third video demonstrating this, it's temporarily available here:

Andreas, I do not know Plasma, but could it be configured to handle the Hyper + Button 1 combination as I have described? If so, does this trigger the effect?

#8 Updated by Stefan Klinger 12 days ago

I do not know if that's related to this bug, but FVWM complains about darktable in the following way:

[fvwm][GetWindowSizeHints]: <<WARNING>> reason: 1: The hints have been ignored because the window's current size would have become invalid.  The new hints will become active when the window generates the next ConfigureRequest.

[fvwm][GetWindowSizeHints]: <<WARNING>> The application window (id 0x1200003)
  "darktable" has broken size hints (inconsistent with current size).
    fvwm is ignoring those hints.    hint override = 0, flags = 310
  min_width = 1172, min_height = 274, max_width = 0, max_height = 0
  width_inc = 0, height_inc = 0
  min_aspect = 0/0, max_aspect = 0/0
  base_width = 0, base_height = 0
  win_gravity = 1

    If you are having a problem with the application, send a bug report
    with this message included to the application owner.
    There is no need to notify

#9 Updated by Stefan Klinger 10 days ago

I have used `git bisect` to track down where this bug was introduced:

$ git bisect good
92c1733369600cb034852676124026479aa69c83 is the first bad commit
commit 92c1733369600cb034852676124026479aa69c83
Author: edgardoh <>
Date:   Sat Sep 29 07:31:06 2018 -0300

    fix cross position

:040000 040000 b76bf5ce67082ae9bf7772a447921dc05ca07c32 6e0e84d8e2ef961f8cf6ae7aaf1f541f1c8d879b M      src

This commit does a lot of things involving the terms "mouse", "event" and "mask". But I certainly do not understand how this code works.

Playing with FVWM and trying to find the bug on their side, I assume that keyboard modifier `mod4`, commonly bound to the Windows/Logo key, is involved.

Discussion is on the mailing list.

#10 Updated by Edgardo Hoszowski 10 days ago

I just entered PR bug 12387 #1812, please test it.

#11 Updated by Stefan Klinger 9 days ago

I'm sorry to say that the bug is not fixed.

I've verified the bug's effect wich commit e30c70f3d as well as with f36458080.

I've also cloned your git repo, and verified the bug exists with commit e98d935ad.

#12 Updated by Edgardo Hoszowski 7 days ago

I cannot duplicate on my environment, and by just looking at the code I got nothing. What I can do is to add a PR with some debug messages for you to run, so maybe we get more info.
Let me know if you are OK with this.

#13 Updated by Edgardo Hoszowski 7 days ago

Just entered Bug 12387 #1824

Let's continue this conversation on the actual PR, I don't mind having private messages but there may be people interested on this.

#14 Updated by Richard Askwith 6 days ago

For what is worth, I am having the same problem.

My operating system is a Linux distro; 'Elementary OS'. I am running Darktable version 2.4.2. It was installed using the Elementary OS AppCentre.

Let me know if I can give you any other info.

#15 Updated by Stefan Klinger 6 days ago

Elementary OS? So I assume that you do not use the FVWM window manager, but rather Gala. That would be the first evidence that this bug is not isolated to FVWM. Could you verify this?

#16 Updated by Richard Askwith 6 days ago

Yes, that is true. I am using the stock release of Elementary OS Juno based upon Ubuntu 18.04. No tweaks other than receiving standard updates.

#17 Updated by Andreas Schneider 6 days ago

I had that issue some days ago with KDE Plasma, however I can't reproduce it as reliably as Stefan.

Also available in: Atom PDF