Re: FVWM: how to escape F1?
Hi, this is an *untested* idea: There's `FakeKeypress` documented in fvwm(1), which seems to send a keypress event to an application. I assume, that for each binding you have in yout setup, like Key you would have to add something like KeyFakeKeypress \ press press release release to make myEscModifier-myEscKey escape key from FVWM and send it to the client instead. But the documentation about how `release` relates to `press` is a bit thin, and the manual explicitly states that this may ot work at all. I have no further knowledge about this, never used it. For me, I've decided to control all window manager interactions with mod4 bound to the logo keys, and the menu-key (next to the tight Ctrl on US keyboards). These are usually not used by applications. Cheers Stefan -- http://stefan-klinger.deo/X I prefer receiving plain text messages, not exceeding 32kB. /\/ \
Re: FVWM: Possible bug: Jumping pointer in Darktable
Dan Espen (2018-Dec-30, excerpt): > Okay I can confirm on my system that the circle jumps away when > I try to drag. Removing the key binding fixes the problem. [...] > Not sure what is going on or where to even look. Hi Dan, sorry for the delay. More than one week ago, Edgardo Hoszowski (Cc) was so nice as to talk me through some tests to run, in order to hunt down the jumping pointer bug. He basically spiked darktable with `printf`s in the right places to report events to stdout as they occurred. Then I've run that and sent him the results for analysis. Over few iterations he concluded that on my system somehow an additional mouse_leave event is perceived by darktable, and that probably causes the jump. This behaviour can be reproducibly switched on (or off), by binding (or unbinding) mouse-1. $ FvwmCommand 'mouse 1 A 4' # unbind $ FvwmCommand 'mouse 1 A 4 moveOrRaise' # bind So the assumption is that FVWM reports left-click events differently to an application, depending on whether there's a binding for mouse-1, or not. Maybe it needs to capture an event to check if modifier Mod4 is held down? You can find Edgardo's modified darktable source on github https://github.com/edgardoh/darktable/tree/bug_12387_2 in branch `bug_12387_2`, and it will compile just fine using the same procedure I've described to you previously. $ cd darktable $ git remote add edgardoh https://github.com/edgardoh/darktable.git $ git remote update edgardoh $ git co bug_12387_2 $ git describe release-2.6.0rc2-51-g26ccb0b31 I've compiled and tested this with (shows the bug) and without keybinding (does not show the bug). I've clicked on an existing shape, and did not move the mouse between button press and release. Attached is the complete stdout of each test. I've terminated darktable with Ctrl-Q right after releasing the mouse button, so the interesting part is towards the end of the files. I've noticed that the coordinates reported with `dt_circle_events_button_pressed` are consistently wrong (x=-1.00, y=-1.00) when the jump occurs. Edgardo's final email was: Edgardo Hoszowski (2019-Jan-03, excerpt): > This is what's creating the issue: > > [draw] begin > [draw] end > [center_leave] > [dt_control_mouse_leave] > [dt_masks_events_mouse_leave] > [center_enter] > [dt_control_mouse_enter] > [button_pressed] begin > > Between the [draw] and [button_pressed] something is generating the mouse > leave/mouse enter. I don't see anything in darktable that can be doing this > so my guess is that the WM is doing something here. For what I understand > from the mails they are capturing the button pressed, if so, then that's > why we don't see it here. > > Do you think you can get in touch with them? Even if what the WM is doing > is correct it will help to know what's going on. Fell free to copy me if > you think I can help. > > BTW, the x=-1 that you see is set on the mouse leave event, that's what > generates the jump. So, do you have any thoughts on what's going on? I'd be happy to provide more information if required. Maybe you could point me to the region in FVWMs code where events are propagated to applications (I have no idea what I'm getting myself into...)? My conversation with Edgardo extends over 16 mails, so I've tried to summarize this, but I can also send you the whole lot. Cheers Stefan -- http://stefan-klinger.deo/X I prefer receiving plain text messages, not exceeding 32kB. /\/ \ [dt_ui_container_focus_widget] [dt_ui_container_focus_widget] [dt_ui_container_focus_widget] [dt_ui_container_focus_widget] [dt_ui_container_focus_widget] [dt_ui_container_focus_widget] [dt_ui_container_focus_widget] [dt_ui_container_focus_widget] [dt_ui_container_focus_widget] [dt_ui_container_focus_widget] [dt_ui_container_focus_widget] [dt_ui_container_focus_widget] [dt_ui_container_focus_widget] [dt_ui_container_focus_widget] [dt_ui_container_focus_widget] [dt_ui_container_focus_widget] [dt_ui_container_focus_widget] [dt_ui_container_focus_widget] [dt_ui_container_focus_widget] [dt_ui_container_focus_widget] [dt_ui_container_focus_widget] [dt_ui_container_focus_widget] [dt_ui_container_focus_widget] [dt_ui_container_focus_widget] [dt_ui_container_focus_widget] [dt_ui_container_focus_widget] [dt_ui_container_focus_widget] [dt_ui_container_focus_widget] [dt_ui_container_focus_widget] [dt_ui_container_focus_widget] [dt_ui_container_focus_widget] [dt_ui_container_focus_widget] [dt_ui_container_focus_widget] [dt_ui_container_focus_widget] [dt_ui_container_focus_widget] [dt_ui_container_focus_widget] [dt_ui_container_focus_widget] [dt_ui_container_focus_widget] [dt_ui_container_focus_widget] [dt_ui_container_focus_widget] [dt_ui_container_focus_widget] [dt_ui_container_focus_widget] [dt_ui_container_focus_widget] [dt_ui_container_focus_widget]
Re: FVWM: Possible bug: Jumping pointer in Darktable
Dan Espen (2018-Dec-29, excerpt): > I want to be sure I remember how to test for this. > > I start darktable and import an image and click on it. doubleclick, yes > I then open the "mask manager" triangle to use the tools there. > If I select the circle tool, a circle appears on the image. > I can then move the circle around but when I click to drop it > it jumps somewhere else? No, it is placed where you clicked. But when you try to move it again, by dragging with the left mouse button, it will jump away from the pointer as soon as the drag begins. > The edit tool has similar issues. Most tools on the right hand pane have a "blend" option at the bottom of their dialog. Choose "drawn mask" there and you have a couple of options for creating shapes (circle, ellipse, ..., like in "mask manager"). Creating the shape works, but *moving* an existing shape afterwards shows the jumping. > I don't remember it failing when I tested it last. Note that it seems to be necessary to have a mouse binding like the following inyour FVWM setup: mouse 1 A 4 beep which simply beeps with on a button-1 click with modifier 4 (windows key) held down. I'm using mouse 1 A 4 moveOrRaise AddToFunc moveOrRaise + C raise + M move to move windows with the mouse and windows-key. Also, I've re-uploaded videos that show the effect: http://depot.s5k6.net/B53pnjQAHxnTgvTw Cheers Stefan -- http://stefan-klinger.deo/X I prefer receiving plain text messages, not exceeding 32kB. /\/ \
Re: FVWM: Possible bug: Jumping pointer in Darktable
Hi Dan, sorry to bother you again: In November I had asked you [1] to look after a bug I was observing with FVWM and darktable. At that time you were testing with darktable-2.4.4, and you did not observe the bug. I don't know whether you have tried any newer version, but a couple of days ago darktable 2.6.0 was released, and it shows the bug. I'd really like to know whether you can reproduce the that... Steps to reproduce the bug are here [2]. Thank you! Stefan [1] https://www.mail-archive.com/fvwm@fvwm.org/msg03403.html [2] https://redmine.darktable.org/issues/12387 -- http://stefan-klinger.deo/X I prefer receiving plain text messages, not exceeding 32kB. /\/ \
Re: FVWM: Possible bug: Jumping pointer in Darktable
Hi, is there any publicly accessible record of the mailing list? The one [1] linked to on FVWM's website [2] seems to not contain any messages posted after 2018/05/18. In particular, I'm missing a conversation with Dan Espen wich occurred in early November 2018. I'd like to send a link to that conversation to the developers of Darktable [3] in order to help fixing a bug [4]. Thank you! Stefan [1] https://www.mail-archive.com/fvwm@fvwm.org/maillist.html [2] http://www.fvwm.org/support/ [3] https://www.darktable.org/ [4] https://redmine.darktable.org/issues/12387 Dan Espen (2018-Nov-06, excerpt): > Stefan Klinger writes: > > > Hi, > > > > I'm using darktable [1], an open-source photography workflow > > application and raw developer, basically a free Adobe Lr alternative. > > > > Recently I noticed a bug: Darktable allows to select areas > > (aka. shapes) on a photograph, and apply operations only to those > > areas instead of to the whole image. Usually, one can drag these > > shapes around with the mouse, holding down button 1. The bug > > manifests when pressing button 1 on a shape: It jumps away (southeast) > > from the pointer, maybe even outside of the window. It is not > > possible to drag te shape to the top left area of the image. The > > effect is larger to the lower right of the screen. > > > > I've filed a bug report [2] in darktable's tracker, and also > > *temporarily* provide screencasts [3]. > > > > Pascal suggested that it's an issue with the window manager, which > > would be FVWM on my machine. He cannot reproduce on Gnome. I've > > tested the following: > > > > * The bug disappears when using Openbox instead of FVWM, and also > > when not using any window manager at all (only X then). > > > > * I have (among others) this binding in my FVWM config > > > > mouse 1 A 4 moveOrRaise > > > > Disabling this makes the bug disappear, reenabling it produces the > > bug again. This is demonstrated in the 3rd video [4]. > > > > * I have not seen this with any other application, so mabe it's > > linked to a rather exotic/brand new feature not employed often by > > X clients. > > > > Can anyone reproduce this? > > > > [1] https://www.darktable.org/ > > [2] https://redmine.darktable.org/issues/12387 > > [3] https://depot.s5k6.net/B53pnjQAHxnTgvTw/ > > [4] https://depot.s5k6.net/B53pnjQAHxnTgvTw/03-change_mouse_binding_hi.mp4 > > Nope, no luck reproducing it. > Looks to me like Fvwm thinks your mouse 1 button has the Mod 4 modifier > active. > > Have you done something to enable sticky modifier keys? > > You might want run "xev" and press mouse 1. > > -- > Dan Espen -- http://stefan-klinger.deo/X I prefer receiving plain text messages, not exceeding 32kB. /\/ \
Re: FVWM: Possible bug: Jumping pointer in Darktable
Hi, one of the darktable developers was so kind as to have a closer look at this problem. You can review our discussion here [1]. Unfortunately, we were unable to solve the problem. May you have an idea? Thanks Stefan [1] https://github.com/darktable-org/darktable/pull/1824 -- http://stefan-klinger.deo/X I prefer receiving plain text messages, not exceeding 32kB. /\/ \
Re: FVWM: Possible bug: Jumping pointer in Darktable
To make this more clear: I think it's a darktable bug. But I'm surprised to see it disappear with FVWM 2.4.20 (from 2006!). I've failed to find the code change in FVWM that changes behaviour. -- http://stefan-klinger.deo/X I prefer receiving plain text messages, not exceeding 32kB. /\/ \
Re: FVWM: Possible bug: Jumping pointer in Darktable
Stefan Klinger (2018-Nov-09, excerpt): > Now I'll start bisecting FVWM... Oh my! Well, I've figured out that the described bug occurs with the current `master` at `4e759d6f`, and also with `fvwm2-stable` at `65007a8f`. The bug does *not* occur with `version-2_4_20` at `86004a59`. Unfortunately, I've failed to compile the lowest common ancestor `version-2_4_4-pre1`, and also most of the FVWM versions between that and `master`, probably because the build system has been changed and maybe relies on older versions. I've managed to compile `fd21cc0a`, which does show the bug. That is from 2011, somewhere between version 2.6.1 and 2.6.0 — i.e., if it's a bug in FVWM, then it's an old one. I'm still surprised though, that 2.4.20 does not exhibit the bug... -- http://stefan-klinger.deo/X I prefer receiving plain text messages, not exceeding 32kB. /\/ \
Re: FVWM: Possible bug: Jumping pointer in Darktable
Dan Espen (2018-Nov-08, excerpt):
> Stefan Klinger writes:
>
> > I'll be offline for the rest of today (8h driving, yay), so no need to
> > hurry...
> >
> > Dan Espen (2018-Nov-07, excerpt):
> >> >> FvwmCommand 'mouse 1 A 4 Beep'
> > [...]
> >> Fvwm should only Beep when the modifier key is held down.
> >
> > That's what it does, sorry, should have been more clear about this.
> >
> >> So, maybe I'm not doing the right thing to see the problem.
> >> I've opened darktable,
> >
> > btw. which Version? I'm using the master branch, i.e., last time I've
> > checked out was
> >
> > $ darktable --version
> > this is darktable 2.5.0+767~gabecd987b
>
> $ darktable --version
> this is darktable darktable-2.4.4-1.fc27
Ok, I've been `git bisect`ing darktable this morning. I'm using a
script `retry` to automate the repeated compilation (attached).
The result being
$ cp /home/sk/foto/20180923-000/DSC_3932.NEF ~/tmp
$ cd ${darktable_source}
$ git clean -xdf
$ ~/prg/darktable-tools/retry master # bad
$ ~/prg/darktable-tools/retry release-2.4.4 # good
[...]
$ git bisect good
Bisecting: 2 revisions left to test after this (roughly 1 step)
[92c1733369600cb034852676124026479aa69c83] fix cross position
$ ~/prg/darktable-tools/retry
$ git bisect bad
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[35e88586d70ab87b12e6f42cbeb402f76e358f18] cross follow mouse
$ ~/prg/darktable-tools/retry
$ 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
:04 04 b76bf5ce67082ae9bf7772a447921dc05ca07c32
6e0e84d8e2ef961f8cf6ae7aaf1f541f1c8d879b M src
I do not understand this code, but I've posted this info on
darktable's bucktracker [1].
Now I'll start bisecting FVWM...
[1] https://redmine.darktable.org/issues/12387#note-9
--
http://stefan-klinger.deo/X
I prefer receiving plain text messages, not exceeding 32kB. /\/
\
#!/bin/bash
set -u -e -C;
shopt -s nullglob;
cd "${HOME}/source/dt/";
prefix="${HOME}/tmp/dt"
disable=(flickr libsecret kwallet unity tethering)
if test "${1-}"; then git co "$1" || return 1; fi;
git submodule update --recursive || return 1
./build.sh -j "$(nproc)" --prefix "$prefix" "${disable[@]/#/--disable-}"
--buildtype Release || return 1
rm -rf "$prefix"
cmake --build build --target install -- -j6 || return 1
"${prefix}/bin/darktable" --library "${prefix}/dummy-library" ~/tmp/DSC_3932.NEF
Re: FVWM: Possible bug: Jumping pointer in Darktable
I'll be offline for the rest of today (8h driving, yay), so no need to hurry... Dan Espen (2018-Nov-07, excerpt): > >> FvwmCommand 'mouse 1 A 4 Beep' [...] > Fvwm should only Beep when the modifier key is held down. That's what it does, sorry, should have been more clear about this. > So, maybe I'm not doing the right thing to see the problem. > I've opened darktable, btw. which Version? I'm using the master branch, i.e., last time I've checked out was $ darktable --version this is darktable 2.5.0+767~gabecd987b > let it import some images, then I double click > on one of them. I then click on the pencil to the left of the image Hmm, that would be under "mask manager"? > and I draw a circle on the image. Then I can use mouse 1 to move > the circle around. The circle moves smoothly and the mouse pointer > doesn't jump around. I've just tried and can observe the error when dragging line sections created with the pencil. Also when creating a circle with the circle tool (next to the pencil) and dragging that: jumps. Interestingly, when dragging *nodes* of the line segment created with the pencil, the error does not show up. Honestly, I'm not convinced that this is entirely FVWMs fault... > I'm not really familiar with Fvwm key binding matching code but I'm > willing to look. But first I think I need to be able to create > the problem. Yeah, totally agree. maybe it's a quirk in my setup but I would not know where to look. I think I'll try `git bisect` on this to see when the bug was introduced. Not before Friday... Thanks Stefan -- http://stefan-klinger.de o/X Send plain text messages only, not exceeding 32kB./\/ \
Re: FVWM: Possible bug: Jumping pointer in Darktable
I do not know if this is related (I doubt it, considering the correlation with mouse bindings), but I've found this in my `.xsession-errors`: [fvwm][GetWindowSizeHints]: <> The application window (id 0x123) "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 fvwm-work...@fvwm.org. As suggested, I'll send this to darktables bugtracker... -- http://stefan-klinger.deo/X I prefer receiving plain text messages, not exceeding 32kB. /\/ \
Re: FVWM: Possible bug: Jumping pointer in Darktable
Dan, thanks for helping me here. I have to admit: I'm confused. Dan Espen (2018-Nov-07, excerpt): > >> You might want run "xev" and press mouse 1. [...] > The part I was after is this: > > ButtonRelease event, serial 33, synthetic NO, window 0x121, > root 0x1cf, subw 0x0, time 3086503, (119,138), root:(766,139), > state 0x100, button 1, same_screen YES > ^ [...] So we both agree that xev thinks the Window key is *not* held down (which is a correct observation), since otherwise the state would contain 0x40. Right? > I did this: > > FvwmCommand 'mouse 1 A 4 Beep' > > Then I used xev to capture the press with the "Windows" key held down: > > ButtonRelease event, serial 36, synthetic NO, window 0x2e1, > root 0x24d, subw 0x0, time 1095056384, (125,80), root:(1539,1094), > state 0x140, button 1, same_screen YES > ^ [...] Yes, I observe the same, and the beep occurs where it should. I've also noted that the `ButtonPress` event, which should have occurred just prior to this `ButtonRelease` is not listed by xev anymore, because it is captured by FVWM to make the Beep. I've verified that the jumping effect also persists with the binding to `Beep`. And pushing this further, also when binding to `nop`, the no-operation. I.e., *all* of the following lines exhibit the error: $ FvwmCommand 'mouse 1 A 4 Beep'# beep $ FvwmCommand 'mouse 1 A 4 moveOrRaise' # bind $ FvwmCommand 'mouse 1 A 4 nop' # no-op And only if there is *no* binding, i.e., after $ FvwmCommand 'mouse 1 A 4' the error does not occur. So it is related to having the binding, not to what the binding refers to. But anyways, since you've asked: AddToFunc moveOrRaise + C raise + M move > So, I'm unclear why Fvwm is reacting to mouse 1 on your system > as if modifier 4 is active. [...] That's what I don't understand: What is it that makes you say FVWM would act as if mod4 (linked to my Windows key) is active when pressing Button 1? Note that, when interacting with darktable, I do *not* hold down the Windows key. I can imagine that your statement comes from the reasonable assumption that any binding to `mouse 1 A 4` could only have an effect if FVWM sees mod4. Maybe that binding to `mouse 1 A 4` triggers a bug that manifests only later, in a pretty funny way, and only with Darktable? -- http://stefan-klinger.deo/X I prefer receiving plain text messages, not exceeding 32kB. /\/ \
Re: FVWM: Possible bug: Jumping pointer in Darktable
Dan Espen (2018-Nov-06, excerpt):
> Looks to me like Fvwm thinks your mouse 1 button has the Mod 4 modifier
> active.
If so, then why does FVWM not try to move the window around, unless
the Super key is actually held down?
> Have you done something to enable sticky modifier keys?
Not that I'd be aware of. If “sticky modifier keys” means the feature
to press and release a modifier, and preserve the modifiers effect for
the next keypress, then no, I do not have such a feature. Also,
{num,scroll,caps}lock are off.
> You might want run "xev" and press mouse 1.
Okay, but I'm a little overwhelmed by the output. I've used
$ FvwmCommand 'mouse 1 A 4 moveOrRaise' # bind
$ xev > bound.txt
and
$ FvwmCommand 'mouse 1 A 4' # unbind
$ xev > unbound.txt
to create the attached files. The ButtonPress, ButtonRelease, and
KeymapNotify events look pretty similar to me.
I have even restarted X with all my keyboard and mouse settings (via
`xkbcomp` and `xinput`) disabled, but that has no effect on the error.
--
http://stefan-klinger.deo/X
I prefer receiving plain text messages, not exceeding 32kB. /\/
\
Outer window is 0x121, inner window is 0x122
PropertyNotify event, serial 8, synthetic NO, window 0x121,
atom 0x27 (WM_NAME), time 3081770, state PropertyNewValue
PropertyNotify event, serial 9, synthetic NO, window 0x121,
atom 0x22 (WM_COMMAND), time 3081770, state PropertyNewValue
PropertyNotify event, serial 10, synthetic NO, window 0x121,
atom 0x28 (WM_NORMAL_HINTS), time 3081770, state PropertyNewValue
CreateNotify event, serial 11, synthetic NO, window 0x121,
parent 0x121, window 0x122, (10,10), width 50, height 50
border_width 4, override NO
PropertyNotify event, serial 14, synthetic NO, window 0x121,
atom 0x141 (WM_PROTOCOLS), time 3081770, state PropertyNewValue
MapNotify event, serial 15, synthetic NO, window 0x121,
event 0x121, window 0x122, override NO
ConfigureNotify event, serial 21, synthetic NO, window 0x121,
event 0x121, window 0x121, (0,0), width 178, height 178,
border_width 0, above 0x800262, override NO
ReparentNotify event, serial 21, synthetic NO, window 0x121,
event 0x121, window 0x121, parent 0x805184,
(0,0), override NO
ConfigureNotify event, serial 27, synthetic YES, window 0x121,
event 0x121, window 0x121, (647,1), width 178, height 178,
border_width 0, above 0x805183, override NO
PropertyNotify event, serial 28, synthetic NO, window 0x121,
atom 0x17a (_NET_WM_DESKTOP), time 3081773, state PropertyNewValue
PropertyNotify event, serial 28, synthetic NO, window 0x121,
atom 0x1a8 (_NET_WM_ALLOWED_ACTIONS), time 3081773, state PropertyNewValue
PropertyNotify event, serial 30, synthetic NO, window 0x121,
atom 0x1a6 (_KDE_NET_WM_FRAME_STRUT), time 3081773, state PropertyNewValue
PropertyNotify event, serial 30, synthetic NO, window 0x121,
atom 0x1a7 (_NET_FRAME_EXTENTS), time 3081773, state PropertyNewValue
ConfigureNotify event, serial 32, synthetic YES, window 0x121,
event 0x121, window 0x121, (647,1), width 178, height 178,
border_width 0, above 0x805183, override NO
MapNotify event, serial 32, synthetic NO, window 0x121,
event 0x121, window 0x121, override NO
VisibilityNotify event, serial 32, synthetic NO, window 0x121,
state VisibilityUnobscured
Expose event, serial 32, synthetic NO, window 0x121,
(0,0), width 178, height 10, count 3
Expose event, serial 32, synthetic NO, window 0x121,
(0,10), width 10, height 58, count 2
Expose event, serial 32, synthetic NO, window 0x121,
(68,10), width 110, height 58, count 1
Expose event, serial 32, synthetic NO, window 0x121,
(0,68), width 178, height 110, count 0
PropertyNotify event, serial 32, synthetic NO, window 0x121,
atom 0x13f (WM_STATE), time 3081773, state PropertyNewValue
EnterNotify event, serial 33, synthetic NO, window 0x121,
root 0x1cf, subw 0x0, time 3084567, (130,177), root:(777,178),
mode NotifyNormal, detail NotifyAncestor, same_screen YES,
focus NO, state 0
KeymapNotify event, serial 33, synthetic NO, window 0x0,
keys: 68 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
MotionNotify event, serial 33, synthetic NO, window 0x121,
root 0x1cf, subw 0x0, time 3084568, (130,177), root:(777,178),
state 0x0, is_hint 0, same_screen YES
FocusIn event, serial 33, synthetic NO, window 0x121,
mode NotifyNormal, detail NotifyNonlinear
KeymapNotify event, serial 33, synthetic NO, window 0x0,
keys: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
FVWM: Possible bug: Jumping pointer in Darktable
Hi, I'm using darktable [1], an open-source photography workflow application and raw developer, basically a free Adobe Lr alternative. Recently I noticed a bug: Darktable allows to select areas (aka. shapes) on a photograph, and apply operations only to those areas instead of to the whole image. Usually, one can drag these shapes around with the mouse, holding down button 1. The bug manifests when pressing button 1 on a shape: It jumps away (southeast) from the pointer, maybe even outside of the window. It is not possible to drag te shape to the top left area of the image. The effect is larger to the lower right of the screen. I've filed a bug report [2] in darktable's tracker, and also *temporarily* provide screencasts [3]. Pascal suggested that it's an issue with the window manager, which would be FVWM on my machine. He cannot reproduce on Gnome. I've tested the following: * The bug disappears when using Openbox instead of FVWM, and also when not using any window manager at all (only X then). * I have (among others) this binding in my FVWM config mouse 1 A 4 moveOrRaise Disabling this makes the bug disappear, reenabling it produces the bug again. This is demonstrated in the 3rd video [4]. * I have not seen this with any other application, so mabe it's linked to a rather exotic/brand new feature not employed often by X clients. Can anyone reproduce this? Thanks! Stefan [1] https://www.darktable.org/ [2] https://redmine.darktable.org/issues/12387 [3] https://depot.s5k6.net/B53pnjQAHxnTgvTw/ [4] https://depot.s5k6.net/B53pnjQAHxnTgvTw/03-change_mouse_binding_hi.mp4 -- http://stefan-klinger.deo/X I prefer receiving plain text messages, not exceeding 32kB. /\/ \
