GNOME's Mutter 40 Alpha Released With Big Improvements

[ssokolow]

curfew most people fail to notice how often under X11 they do a drag and drop and it magically disappears to no where(there is basically a constant 3 percent chance of this happening). Wayland to Wayland drag and drop does not have the magic disappearing problem either. The reality is X11 drag and drop is buggy that makes implementing a bridge to a new drag and drop system tricky as hell. Having to run a file manager or the like particular as X11 application under XWayland while using X11 applications in Xwayland so you can drag and drop at least will not risk you having new quirks from the bridge and having to guess is it the bridge or is it normal X11 quirkiness.

Wayland won't fix everything. I have a PyQt application I'm working on which accepts drag-and-drop and copy-paste of images and files and I have a big pile of hacks and unit test suites to make sense of what I pull out of QMimeData.

• Does the application send its URLs as text/plain but not text/uri-list? PCManFM for GTK+ 2.x's "Copy Path(s)" option does and users will still expect that to Just Work™ in my application.
• Does the application only offer "path to clipboard" in a pre-shell-escaped form meant for pasting into terminals? GQview/Geeqie does.
• Does the application use file://localhost/ instead of file:///? Comix does and QUrl.toLocalFile() maps that to //localhost/ as if it were a UNC path (which is actually consistent with a "this is implementation-defined" part of POSIX), but other code doesn't know how to deal with that.
• Does Chrome/Chromium sometimes send text/uri-list in a little-endian UTF-16 form that QMimeData resolves to QUrl(""), triggering my fallback to the UTF-8 text/plain version? Yes.
• Does the application use \n or \r\n to separate the list of URLs or file paths when it's sending them via a mechanism QMimeData doesn't normalize? Does it include or omit a terminal \n or \r\n? It depends on the application. (I believe the spec calls for \r\n and one at the end of the final line, but that's alien enough to Linux and '\n'.join(url_list) that you see a lot of apps messing it up. In fact, I think this is the quirk that breaks drag-and-drop from Audacious Media Player to Firefox.)
• Do you have to parse an HTML fragment (ie. multiple root elements) out of the text/html content type offer if you want the image data and the original URL (eg. to support both First/Prev/Next/Last buttons for local files and remote "must be logged in" images)? Firefox and Chromium's "Copy Image" do that.
• Is the text/html content in little-endian UTF-16 or UTF-8? It depends on whether you chose to "Copy Image" or Drag and Drop in Firefox... luckily, the UTF-16 text/html is accompanied by the URL offered as text/plain.
• What precedence order do I need to use in my fallback chain when a browser offers up multiple representations of a file? That took gathering output from various browsers and writing a test suite.
• Chrome sometimes randomly neglects to include the raw image data as an option when dragging and dropping a "you must be logged in to view this" image from Pixiv? I have to detect and display an explanatory dialog in the part of my code that performs network requests.
• Does text/plain contain a URL or a path? Does it percent-escape when constructing a file:// URL or construct something primarily intended for human viewing where % in directory/file names is meant to be interpreted literally?
• etc. etc. etc.

...but I suppose Wayland will at least get rid of that pre-UTF8 COMPOUND_TEXT encoding for multi-script text, given that even tools that come bundled with X.org can't be arsed to implement it and just hard-code for decoding as latin1.

If anyone wants to explore the wonderful world of mis-implemented copy-paste and drag-and-drop themselves, here's a little PyQt utility I wrote for inspecting the raw data and how PyQt interprets it while I was building my code and its test suite. I've only tested it under X11 on Linux, but it should theoretically work on Wayland, Windows, and macOS too.

(Tip: Firefox's Copy Image and Okular's option to copy the selection as an image produce an eye-opening list of offered image formats. I'm still trying to figure out what the image/pic offered by Okular is so I can generate a properly licensed dummy one for my test suite.)

[oiaohm]

Generally speaking you're about right, but then there are those few standalone apps that you have no alternative for such as Gimp and Firefox.

Especially Gimp on Gnome is a fucking pain as Gnome has no support for "open in alternative app"(*), so the only practical way to open an image file in Gimp is to drag 'n' drop it... Except that DnD on Wayland does not work with Gimp. So then you have to open Gimp, choose "Open file..." and navigate back to the folder using the file chooser dialog. Jesus christ!

(*) While such option does exist in the context menu, it will always permanently re-configure the default app for that file type and therefore is useless. I only want to open one photo in Gimp, not set it as the permanent default application for JPEG files... (And for PNGs the default remains the old one, creating an incoherent mess.)

So this is a bug you have been working around with DnD right. The issue with gnome is not straight forward https://gitlab.gnome.org/GNOME/mutter/-/issues/974

The reality is X11 applications under Xwayland can drag and drop with each other. Wayland applications under Mutter can also drag and drop with each other no problems. Everything falls to hell when when you attempt to drag and drop cross the Wayland to XWayland divide. This makes sense when you look at the wine/gtk/qt code and see how many quirks you have to implement in the X11 implementation that it works most of the time this makes doing a bridge insanely hard and risking high number of bugs.

I know it a horrible work around to suggest starting files in gnome as a X11 application for the applications are not wayland backend yet.
GDK_BACKEND=x11 usage is not ideal but its not that drag and drop to those old applications cannot be made work. Just its a very different workflow. Hopefully one day the bug gets fixed.

curfew most people fail to notice how often under X11 they do a drag and drop and it magically disappears to no where(there is basically a constant 3 percent chance of this happening). Wayland to Wayland drag and drop does not have the magic disappearing problem either. The reality is X11 drag and drop is buggy that makes implementing a bridge to a new drag and drop system tricky as hell. Having to run a file manager or the like particular as X11 application under XWayland while using X11 applications in Xwayland so you can drag and drop at least will not risk you having new quirks from the bridge and having to guess is it the bridge or is it normal X11 quirkiness.

I am not 100 percent sure if this problem is a good one to fix or if it should be just get use to new workflow of needing to run everything in Xwayland or everything in wayland that need to drag and drop with each other. Sometimes its worse to get what you are asking for.

[curfew]

Interoperability is not worth it.

Generally speaking you're about right, but then there are those few standalone apps that you have no alternative for such as Gimp and Firefox.

Especially Gimp on Gnome is a fucking pain as Gnome has no support for "open in alternative app"(*), so the only practical way to open an image file in Gimp is to drag 'n' drop it... Except that DnD on Wayland does not work with Gimp. So then you have to open Gimp, choose "Open file..." and navigate back to the folder using the file chooser dialog. Jesus christ!

(*) While such option does exist in the context menu, it will always permanently re-configure the default app for that file type and therefore is useless. I only want to open one photo in Gimp, not set it as the permanent default application for JPEG files... (And for PNGs the default remains the old one, creating an incoherent mess.)

[oiaohm]

Especially on Wayland there are already issues with interoperability between desktop environments.

That problem is true under X11 before Wayland even started. Interoperability between desktop environments have been a on going nightmare. Wine has a lot of quirks to deal with different clipboard handling and other things from different X11 DE and Windows managers.

[curfew]

They wanted to avoid exactly this and the implied major breaking changes. They want an incremental updates model where even big updates are broken down and adopted with less breakage.

...and less hopes up and expectations are a big portion of the desktop will probably remain GTK 3 for some time.

However in the new fangled world, there is not a need for every single core app to be ported on the same release and GTK4 is designed to be parallel installable.

Especially on Wayland there are already issues with interoperability between desktop environments. With the use of two separate toolkits, there will surely be interoperability issues between Gnome apps, too. Although there always have been issues between legacy (generic) GTK apps and Gnome anyways...

[You-]

Would have made more sense for GNOME 40 to be when they adopt GTK4, no?

They wanted to avoid exactly this and the implied major breaking changes. They want an incremental updates model where even big updates are broken down and adopted with less breakage.

However, GTK is aiming for a release in december and it seems pretty on target. So that is when GTK 4 will be adopted.

However in the new fangled world, there is not a need for every single core app to be ported on the same release and GTK4 is designed to be parallel installable.

[You-]

Except for the name. We're gonna give 'em hell for skipping 38 versions

When the naming discussions happened, it was noted that the next release is actual Gnome's 41st release. It was pragmatically too late at that stage to rename 3.38 to gnome 40. Next release being 41 would have been odd especially as the normal next release would have been 3.40.

They have skipped -1 releases!

[Vistaus]

Would have made more sense for GNOME 40 to be when they adopt GTK4, no?

IMHO, yes. But that line of thinking in Linux was dropped ever since KDE decided to split Plasma, Frameworks and Applications into different version numbers.

[ix900]

Wikis just suck. They tend to expand until maintainability is lost. This happened here as well.

So... just like everything else. Go figure.

[scottishduck]

Would have made more sense for GNOME 40 to be when they adopt GTK4, no?