MyPaint UI freezes on any popup with GTK 3.24 on Fedora 29 GDE

[garynthompson]

Description of the problem

I installed the latest MyPaint, brushes and libmypaint on my system from GIT.

Upon opening MyPaint in Demo mode (setup.py demo), I was happily inking away with my WACOM stylus (On a Dell XPS 9365 2-in-1) and as soon as I opened the brushes popup the application stopped responding to touch, keyboard and stylus events. I couldn't close it or access any menus. I noted that if I pressed shift or alt, the caption at the bottom of the window would update, so the program was responding to something. I couldn't find any open dialogues.

I noted that in my console I was seeing a Gdk deprecation warning:

(mypaint:13739): Gdk-WARNING **: 10:28:33.453: Window 0x5614a2da1b10 is already mapped at the time of grabbing. gdk_seat_grab() should be used to simultanously grab input and show this popup. You may find oddities ahead.

Since I was experiencing oddities, I continued to investigate. I have fixed it temporarily on my system now (details to come) but I haven't tested it.

Basic system details

MyPaint version: 2.0 Alpha, commit: 4490f06
Operating system: Fedora 29, latest updates
Desktop environment: Gnome 3
Gtk3 Version: 3.24.1-2.fc29

Steps to reproduce

To Repeat and test, I would:

1. Open MyPaint
2. click on the Brushes shortcut on the bottom right (popup)
3. Select a brush
4. No more response to touch.

Backtraces or error messages

Log messages around the issue:

DEBUG: gui.preferenceswindow: Set 'toolbar_icon_size_large_radio' active
DEBUG: gui.tileddrawwidget: configure-event received. Invalidating transform
DEBUG: gui.tileddrawwidget: configure-event received. Invalidating transform
DEBUG: gui.device: Device change: name='Wayland Pointer' source=GDK_SOURCE_MOUSE
DEBUG: gui.freehand: Processing at 32 events/s (t_avg=1.492s)
DEBUG: lib.command: Stopped recording <Brushwork 0x7fd556cec5d0 0.000s None>: tiles_changed=False
DEBUG: gui.freehand: Processing at 25 events/s (t_avg=0.185s)
DEBUG: lib.command: Stopped recording <Brushwork 0x7fd556cec5d0 0.000s None>: tiles_changed=False
WARNING: py.warnings: /tmp/demo-HjHekY/lib/mypaint/gui/windowing.py:358: DeprecationWarning: Gtk.StyleContext.get_direction is deprecated
  rtl = (style.get_direction() == Gtk.TextDirection.RTL)

WARNING: py.warnings: /tmp/demo-HjHekY/lib/mypaint/gui/windowing.py:277: DeprecationWarning: Gdk.Device.grab is deprecated
  time_ = time,


(mypaint:13739): Gdk-WARNING **: 10:28:33.453: Window 0x5614a2da1b10 is already mapped at the time of grabbing. gdk_seat_grab() should be used to simultanously grab input and show this popup. You may find oddities ahead.
DEBUG: gui.windowing: grab: acquired grab on <__gi__.GdkWaylandDevice object at 0x7fd556ea5eb0 (GdkWaylandDevice at 0x5614a19efa20)> successfully
WARNING: py.warnings: /tmp/demo-HjHekY/lib/mypaint/gui/pixbuflist.py:344: DeprecationWarning: Gtk.StyleContext.get_background_color is deprecated
  bg_color_gdk = style_context.get_background_color(state_flags)

WARNING: py.warnings: /tmp/demo-HjHekY/lib/mypaint/gui/windowing.py:289: DeprecationWarning: Gdk.Device.ungrab is deprecated
  device.ungrab(time_=time)

DEBUG: gui.windowing: ungrab: released grab on <__gi__.GdkWaylandDevice object at 0x7fd556ea5eb0 (GdkWaylandDevice at 0x5614a19efa20)>
DEBUG: gui.brushmanager: Loading <ManagedBrush u'classic/coarse_bulk_3' p=None>...
DEBUG: gui.brushmanager: Loading <ManagedBrush u'classic/pointy_ink' p=None>...
DEBUG: gui.brushmanager: Loading <ManagedBrush u'classic/marker_small' p=None>...
DEBUG: gui.brushmanager: Loading <ManagedBrush u'classic/marker_fat' p=None>...
DEBUG: gui.brushmanager: Loading <ManagedBrush u'classic/ink_eraser' p=None>...
DEBUG: gui.brushmanager: Loading <ManagedBrush u'classic/smudge+paint' p=None>...
DEBUG: gui.brushmanager: Loading <ManagedBrush u'classic/charcoal' p=None>...
DEBUG: gui.brushmanager: Loading <ManagedBrush u'classic/pencil' p=None>...
DEBUG: gui.mode: BrushworkModeMixin: checkpoint()
DEBUG: lib.command: Stopped recording <Brushwork 0x7fd556cec5d0 0.000s None>: tiles_changed=False
DEBUG: gui.mode: BrushworkModeMixin: checkpoint()
DEBUG: gui.windowing: crossing: inside=False
DEBUG: gui.windowing: grab: acquired grab on <__gi__.GdkWaylandDevice object at 0x7fd556ea5eb0 (GdkWaylandDevice at 0x5614a19efa20)> successfully

Patch Details

I'm still testing, but as per the deprecation warnings I've replaced device.grab with seat.grab, see the following links:

• https://developer.gnome.org/gdk3/stable/GdkSeat.html#gdk-seat-grab
• https://developer.gnome.org/gdk3/stable/GdkDevice.html#gdk-device-grab

I'll need advice on issuing a PR, since the seat class has only been around since Gtk 3.20 and the dependency listed in the building docs (https://github.com/mypaint/mypaint/blob/master/BUILDING.md) is for >=3.12

I'm also noting a number of other deprecation warnings floating about with Gtk. I'm happy look at some of these, but I know nothing about how to use GTK or how their classes interact (I know how to code, read API docs and guess).

It's currently working for me, I'll test and run automated tests shortly before issuing a PR for this one item.

[briend]

I believe Fedora 29 defaults to wayland. Have you reproduced this problem with X11?
https://docs.fedoraproject.org/en-US/fedora/f29/system-administrators-guide/Wayland/

(I know how to code, read API docs and guess).

Would you like to be a MyPaint dev? These are exactly the skills we need!

[garynthompson]

Thanks for the response.

Yes, I believe the issue is brought to the surface from being on Wayland, as other users on Fedora using X11 on the latest GIT commit aren't reporting an issue.

I'm not sure if it's necessarily a Wayland bug specifically, as I think it's probably a backwards-compatibility breakage with the Device Class that doesn't exist in the Seat Class. The bug disappears when moving away from the GTK deprecated functions, although I'm still having other strange issues (still testing / investigating).

I'd be happy to be on the team and to contribute code changes back, although like the rest of us I'm uncertain as to how much time I can commit. One thing I'd like to do is start with GTK deprecation warnings in the log, just as a maintenance task, but my concern is that will require a dependency update (GTK > 3.20). I'm not sure if that's such an issues since 3.20 was release early 2016, but that's an architectural decision that I'm assuming the dev team would need to approve. Gnome have a bit of an old reputation for not maintaining backwards-compatibility (although, I'm hoping that their updated APIs still equally support X11 and Wayland).

[jplloyd]

@garynthompson

Unfortunately it seems that simply replacing the get_device, grab and ungrab calls to use the corresponding GdkSeat functions is not enough to fix the quirks when running on Wayland.

If you have time to do more detective work and can figure out how to fix the freezes without breaking the dialogs (it seems like we end up with the wrong window coordinates, among other things), it will be much appreciated. It's fine to make a patch/PR that requires gtk 3.20 - if it solves the problems I can adapt it for backwards compatibility before merging.

In the meantime MyPaint now sets GDK_BACKEND to "x11" by default at runtime, which will solve the problems as long as XWayland is available (which I think is the case on most systems w. Wayland).

edit: I'll close this since the problem is now technically solved (it will no longer freeze on fedora 29, 30 and other Wayland systems w. XWayland available). We'll probably have to revisit this in the future however.

[garynthompson]

I'm slowly catching up on various projects and will do some more testing on this soon. In my dev version, I did get it limping along but as you've seen, GDKSeat is not enough. If I come up with related patches I'll issue a PR through and test with and without XWayland.

Thanks.