Clicking on color in docked palette tab undocks the palette tab

[0ion9]

Steps to reproduce:

1. Enable the 'palette' dockable
2. Dock it on the right
3. Make sure it has a palette visible, with a reasonable (32+) number of colors present
4. Click on a color panel.

Result: The color is selected (correct) but the tab is also undocked/moved into its own window (incorrect). If I re-dock it, the same thing will happen on subsequent occasions (nearly every click will

Mypaint Version

git 43c2a45: "About box: report GLib version too, on Windows"

Platform details:

• Arch Linux x86_64
• gtk+3 3.20.2
• python 2.7.11 (or 3.5.1, but I don't believe MyPaint uses Py3 yet)
• Qtile WM r2425 (git commit 0c17528; python3 version.)
• Tablet = Monoprice 12", using evdev driver.

[achadwick]

This should definitely not be happening. I can't reproduce in GNOME using libgtk-3-0 3.18.9 on Debian testing/unstable however, and I don't think anyone has reported anything like it.

First question: can you drag the colour swatches at all?

• Does switching temporarily to a different WM change things?
• Does switching temporarily to GTK 3.18 change things (I know this can be done in MSYS2 at least, and you might be able to do it in-session)

[0ion9]

Can you drag the colour swatches at all?

No, neither when docked or undocked. All drags register as tab drag (that is, the 'palette' icon appears under the cursor during the drag, rather than a color panel).
I think a similar behaviour may be occurring in Firefox, but that does not trigger on drags inside a tab, only on the tab itself.

Switching to a different WM

Haven't tried yet, will edit in result.
EDIT: Never mind, looks like it's clearly GTK related

Switching to gtk 3.18.9

Should be able to do this easily, will edit in result.
EDIT: Yes, I can drag colors -- and click on them! -- normally with 3.18.9. I've looked over the 3.20 changes, nothing obvious there. Currently looking at 3.19 changes -- 759091 notebook tab stays hovered if mouse leaves slowly is the first relevant-looking thing I've found... We also have the rather ambiguous "GTKNotebook has been converted to use gadgets". That's what I'm gonna pick on for a start; I'll try comparing 3.19.5 and 3.19.7. Most likely I'll end up reporting an upstream bug.

EDIT2: verified that 3.19.5 works fine
EDIT3: and 3.19.7 works fine too!
EDIT4: 3.19.9 exhibits the bug (in a slight variation). So it was introduced in either 3.19.8 or 3.19.9. Once I track down the exact version I'll file a bug upstream and mention the version here.
EDIT5: 3.19.8 is the first release which exhibits the bug.

[0ion9]

OK, 3.19.8 is when the bug(?) was introduced. I'm still not 100% sure that MyPaint isn't involved in the fault here, as I've had difficulty finding an GTK3 program that uses tabs similarly.

[achadwick]

Oh goody. More GtkNotebook regressions maybe. I wonder if they're related to the workspace regressions (#639, #640) we're seeing for the Windows cut, which bundled GTK 3.20.1.

[briend]

Doh, I just updated my debian sid-- libgtk-3-0:amd64 3.20.3-1
I have the same problem now. To add a bit-- this happens to any dockable color picker as well as dockable brushes, using mouse or wacom tablet. Work-around-- use popup pickers keyboard shortcuts-- these dialogs are unaffected.
Tested mypaint 1.2.0+gitexport.f62444e and 1.3.0-alpha+git.ac2688c
It might be important to note that there is NO problem with layers or the tool option sliders or other dockable dialogs. Also important-- this only happens when you "drag" the pointer while clicking. It just happens that using the mouse it is possible to click without movement, but using a stylus is basically impossible to click without moving the cursor.

[achadwick]

@briend
is it reproducible with https://gist.github.com/achadwick/1b3505beb47d65fedfd6 ?

[briend]

No, I couldn't find any problems with that demo. I also need to revise my earlier statement regarding the other tool windows-- it definitely happens there as well. While the sliders themselves on the tool options don't exhibit the issue, if you click just above the sliders it will grab and move the window most of the time. I made a video to show this-- a video is worth a thousand pictures:
https://www.youtube.com/watch?v=0Ohp1jcam_4

[briend]

I reverted to these packages and the issue disappeared:
apt install libgtk-3-0=3.18.8-1 libgtk-3-common=3.18.8-1 adwaita-icon-theme=3.18.0-2 libgtk-3-bin=3.18.8-1 gir1.2-gtk-3.0=3.18.8-1
snapshot.debian.org is great. Used http://snapshot.debian.org/archive/debian/20160301T103342Z/

[tr37ion]

I have the same issues with all dockers. Whenever I select something inside a docker and the mouse moves while the mouse button/pen tip is down the docker undocks.

Arch Linux (KDE Plasma)

[achadwick]

@tr37ion GTK version please?

[tr37ion]

libgtk-3.so.0 -> libgtk-3.so.0.2000.3

[achadwick]

@tr37ion
You can find out what it is with pacman on an Arch system:

$ pacman -Qi gtk3

Assuming I have the package name right, and assuming that Arch is anything like MSYS2.

[tr37ion]

Version : 3.20.3-3
Btw. I'm on IRC.

[achadwick]

Reproduced on Windows MSYS2 using GTK 3.21.1. Win7 in a VM, with no Aero effects.

MyPaint's colour selectors do not initiate their own drags. They let the toolkit do that with its default handler, and invoke gtk_drag_source_set() to turn on handling during the button press handler itself. This code is frankly a bit cluttered and nasty, and it can almost be expected to break.

If the button press handler in our gui.colors.adjbases returns True instead of False after doing this DnD setup/teardown (in order to suppress the default handler), the problem goes away. But then you can't drag colours around.

We should probably be initializing the drag ourself in the button press handler.

(The drag sensitivity is way too high as well. It's not respecting "gtk-dnd-drag-threshold", and starting drags at 1 pixel of movement. Of course, it's the wrong drag, so let's fix that first).

[achadwick]

Okay, both the sensitivity thing and the accidental drag-out of the tab should be fixed now, for the palette window at least. Let me know if it crops up for any other dockpanels.

[defaultxr]

Using the current git (1.3.0-alpha+git.5b86415 on Arch Linux; gtk3 3.20.3-3), this also affects the brush selection dockable for me when clicking a brush. It's better than in the 1.2.0 stable but too easy IMO to accidentally drag and undock, especially when using a drawing tablet. Personally I think it shouldn't be possible at all to move that dock by clicking on a brush; not sure if it's intentional behavior.

[achadwick]

Reopened for the brush issue too. I suspect it has the same cause.

[achadwick]

Fixed properly now, on both active branches. The earlier fix was preventing the palette panel's menu from firing 😭

[tr37ion]

Nice, looks like it is fixed now :) Thanks.
PS: you may publish a small hotfix version with this fix.