Pinta 1.8-dev crash when New Screenshot is used on Wayland

[grofaty]

Pinta 1.8 latest development from github on Ubuntu 20.04 using Wayland:
1. File | New Screenshot and click on OK.
2. After time passes and screenshot should be taken Pinta crashes with:

System.DivideByZeroException: Attempted to divide by zero.
   at Pinta.Gui.Widgets.CellRendererSurface.RenderCell(Context g, Int32 width, Int32 height)
   at Pinta.Gui.Widgets.CellRendererSurface.OnRender(Context g, Widget widget, Rectangle background_area, Rectangle cell_area, CellRendererState flags)
   at Gtk.CellRenderer.Render_cb(IntPtr inst, IntPtr cr, IntPtr widget, IntPtr background_area, IntPtr cell_area, Int32 flags)

See attachment for full terminal output.

If at Ubuntu login screen I select X-org session (name: Ubuntu) then Pinta works fine, without a problem.

Just a note Ubuntu 21.04 that will be released in two weeks time it will use Wayland by default.

[grofaty (grofaty)]

Pinta 1.7 snap package on Ubuntu 20.04 using Wayland with the same steps as above and Pinta does nt crash on Wayland, but produces very strange and useless output. See attachment.

Pinta 1.7 snap package on Ubuntu 20.04 using X-org has no problem using New Screenshot functionality.

[Cameron White (cameronwhite91)]

I'll try to get a VM set up to test this out.

[Javier Steinaker (jsteinaker)]

I can reproduce it under Wayland using latest gtk3 branch from git. I'm on Arch Linux, I'm the maintainer of the pinta-gtk3-git package on the AUR in case anyone wants to try it.

I took a look at the source code, I'm not a developer by any means but... just an idea. Maybe Pinta can't get the screen size under Wayland, the variables holding those values remain at 0 and thus the division by zero occurs?

[Javier Steinaker (jsteinaker)]

I forgot to add: I'm running Wayfire as the compositor. Wayland doesn't allow apps to see other apps windows, so most of the screenshot utilities doesn't work. Plus, seems there's no standard for this under Wayland and so every compositor has a different method for taking screenshots, making it a pain in the *ss for apps like Pinta, supposed to run under different environments. Ahhh, the lovely Linux world...

[Cameron White (cameronwhite91)]

Thanks for the info! It sounds like it might be tricky for Pinta to keep supporting this functionality under Wayland, but it should at least produce a more friendly error message in this case.

[grofaty (grofaty)]

There is default Gnome application Screen that has very similar functionalities as Pinta's File | New Screenshot. Just saying screenshots are working in Wayland.

In my humble opinion this "New Screenshot" is not vital functionality of Pinta, so may i suggest for the first step to just try/catch the division by zero problem and produce friendly message instead of crash.

[Cameron White (cameronwhite91)]

I've added some error handling in https://github.com/PintaProject/Pinta/commit/8922a64fe46760a01f1a2aa3adccae2c6927e5d4

[James Carroll (james-carroll)]

For Linux/Wayland, the/my recommended approach here is to make use of the XDG Desktop Portals screenshot interface.

The portals are simply a scoped DBus API that's considered safe to use in the context of Snap/Flatpak packages, but they still work in unconfined environments. Specifically regarding the screenshot API, it ideally acts as a wrapper API around any compositor-specific screenshotting API's. It likely won't work everywhere (considering niche environments exist), but it should give a workable solution on the most common setups.

Because of its design, it would open an out-of-process application window that would allow the user to pick what they wanted to select themselves, so you'd need to supress the Pinta native UI in this instance.

You could rely on this API even in X11 contexts, if desired.

The general flow of using the DBus API would be to make a DBus call, and wait for it's return; whereby it will either fail (user cancelled/unsupported/etc) or return a filepath which contains the screenshot for you to use.

https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot

[Cameron White (cameronwhite91)]

Thanks! I think that seems like a reasonable approach since we wouldn't have to re-implement a screenshot utility in Pinta :)

Looking into it a bit, it seems like GtkSharp is missing some of the glib / gio bindings for dbus stuff, so this might involve submitting some patches upstream (or just using another library like https://github.com/tmds/Tmds.DBus)

[Cameron White (cameronwhite91)]

I've filed bug 1955841 for this