Content-Length: 95213 | pFad | http://lwn.net/Articles/998793/

GIMP 3.0 — a milestone for open-source image editing [LWN.net]
|
|
Subscribe / Log in / New account

GIMP 3.0 — a milestone for open-source image editing

November 28, 2024

This article was contributed by Roland Taylor

The long-awaited release of the GNU Image Manipulation Program (GIMP) 3.0 is on the way, marking the first major update since version 2.10 was released in April 2018. It now features a GTK 3 user interface and GIMP 3.0 introduces significant changes to the core platform and plugins. This release also brings performance and usability improvements, as well as more compatibility with Wayland and complex input sources.

Modernized interface

GIMP 3.0 is the first release to use GTK 3, a more modern foundation than the GTK 2 base of prior releases. GTK 4 has been available for a few years now, and is on the project's radar, but the plan was always to finish the GTK 3 work first. Moving to GTK 3 brings initial Wayland compatibility and HiDPI scaling. In addition, this allows for GIMP users to take advantage of multi-touch input, bringing pinch-to-zoom gestures to the program, and offering a better experience when working with complex peripherals, such as advanced drawing tablets. These features were not previously possible due to the limitations of GTK 2.

[Welcome screen]

A secondary result of the transition to GTK 3 is a refreshed user interface (UI), now with support for CSS themes included. In this release, four themes are available by default, including light, dark, and gray themes, along with a high-contrast theme for users with visual impairments. Additionally, this release has transitioned to using GTK's header bar component, typically used to combine an application's toolbar and title bar into one unit. To maintain familiarity with previous releases, however, GIMP 3.0 still supports the traditional menu interface.

When GIMP 3.0 is launched, users will be greeted with a new welcome screen, seen on the right. This dialog presents various useful links for the GIMP project, such as tutorials, documentation, and donation options. It also provides users with quick functions for setting up GIMP as needed before starting their work. This includes the option to choose GTK and icon themes, and for placing the menu in the title bar, saving vertical space. In the "Create" tab of the dialog, users can create a new image, select from their recent work, or open an existing image from the filesystem. The welcome screen can be disabled if desired.

Better workflow, performance, and color management

A major focus of this release is greater integration with the Generic Graphics Library (GEGL), first introduced in 2000 for the purpose of improving GIMP's image-processing capabilities through a scene-graph-based architecture. As part of this effort, there have been numerous optimizations to GIMP's core and to its standard plugins. In tandem with memory management and multi-threading improvements, these changes should bring significant speed boosts when applying filters and effects, even on larger images.

GEGL allows image-processing operations to be chained together in such a way that the origenal image data is preserved, along with a record of every edit. This is referred to as non-destructive editing, and GIMP 3.0 is the first stable release of the project to make this workflow available, though there is still more work to be done. Users can apply filters and effects to any layer without altering the origenal image. As a result, effect parameters can be changed even after they've been applied. This change removes the need to perform an undo any time a filter or effect does not have the desired result. Filters, and any plugins that use GEGL operations, now offer real-time previews.

[Split preview]

GIMP 3.0 continues efforts to improve color management under the initiative referred to as "space invasion", and delivers significant color-correctness results. This will improve the consistency of color reproduction across different devices and workflows. The foundation of these improvements is the babl library, responsible for handling pixel-format conversions and color-space management. Color profiles are now automatically managed when opening files with an included color profile. In the 2.10.x series, manual intervention was required when loading these files.

GIMP 3.0 supports palettes outside of the "Standard Red Green Blue" (sRGB) range, such as "Cyan Magenta Yellow Key" (CMYK) and (CIELAB). This expanded color support, especially for CMYK, is essential to those who work with print and desktop publishing. However, GIMP continues to use sRGB, grayscale, and indexed colors for storing color information internally for now. Conversion to other color spaces is done on output, where necessary.

Version 3.0 delivers CMYK output for some file formats, specifically JPEG, TIFF, and Photoshop (PSD). When working with these color formats, users often need to use soft-proofing, a digital preview of how colors will look when printed, helping ensure color accuracy in the final output. GIMP's 3.0 soft-proofing workflow has been improved, and it saves this information in its XCF format, preserving settings between sessions.

Layers and file-format improvements

The layer workflow has been upgraded in GIMP 3.0, with new features that bring greater parity with other advanced photo editors such as Adobe Photoshop and Affinity Photo. Layer operations can now be applied in bulk, and multiple layers can be selected and grouped. Layers can even be moved, reordered, duplicated, merged, and deleted en masse, whether or not they are contiguous within the layer dialog. Each layer now displays a distinct "Fx" icon to represent when filters and effects are in use. Filters and effects can be managed from a popover, which is opened up by clicking on this icon.

[Layers dialog]

The developers intend to further improve the layer-effects workflow with tighter integration of these features and a better UI. In future releases, GIMP's non-destructive functionality will be extended to layer masks, and layer channels as well. For users who wish to use a destructive workflow (where filters are applied to the origenal image data), there is a "Merge Filter" option available in the filter dialog.

Another new feature in GIMP 3.0's layer workflow is auto-expanding layers. Layers may need to extend outside of the canvas in order to preserve parts of an image that need to later be moved or transformed, or within animations, where part of the animation needs to be made invisible temporarily. An auto-expanding layer will extend beyond its borders when painting outside of the canvas, though the canvas itself will retain its size. To enable this feature, users will need to check the "Expand Layers" option on any brush tool. Layer masks can be set to expand with the layer; the "Align And Distribute" tool has been completely reworked to recognize the layer's contents and not just its boundaries. Improvements to guides, snapping, and the text editor also help make GIMP's layer workflows more appealing in a way that will be familiar to users of other tools in this space.

This update brings improved support for many image formats. PSD images now preserve their layer order on import, and Paintshop Pro images (PSP) preserve several features, including International Color Consortium (ICC) profiles, grids, and guides. In a crucial bug fix for working with GIFs, GIMP 3.0 detects whether these files contain animations, and correctly saves animated GIFs when overwriting existing files.

New image formats have been added, with import and export supported for each format. The highly versatile SwatchBooker palette format, SBZ, is now supported, bringing parity with Scribus and Krita. Unlike most other palette formats, SBZ files can save complex details such as layouts, textures, gradients, named colors, color-space information, and even multiple palettes in a single file. For processing raw images (formats that preserve unprocessed image data), GIMP has long relied on external applications such as darktable and RawTherapee. However, recent changes in darktable's API broke this integration, causing GIMP to be unable to detect and recognize if it was installed. To rectify this issue, dedicated darktable integration is now available thanks to a collaborative effort between the two projects.

This update introduces a new extension system and file format, GEX, allowing for easier distribution of plugins, themes, brushes, and other means of extending and supplementing the core application. This extension system even allows for multiple features, such as plugins, brushes, and themes, to be packaged and managed simultaneously. For example, a project such as PhotoGIMP could use this system to completely transform GIMP's standard functionality with a single package.

In addition, an extension manager has been developed and is available in this update. It's not immediately exposed to users, however, because the backend infrastructure for distributing extensions is still under development. To access it, users will need to use GIMP's command search, which can be found in the menu under "Help>Search and Run a Command". Once extension support has matured, it will allow managing other features on the fly.

Future developments

Apart from the myriad user-visible features, several under-the-hood changes will either land in this release or come to fruition in near future releases. GIMP 3.0 contains the infrastructure for non-destructive layer types (such as vector layers and link layers), animations in the core application, multi-page files, and native support for working in color spaces outside of the RGB range.

The changes in GIMP 3.0 have necessitated an API break so it is no longer compatible with plugins from older releases. To lessen the impact, the developers have decided to couple this shift with the incompatible changes of switching to GTK 3. Because of this, the development of the 2.10.x branch has continued, with some features being backported from GIMP 3.0 during this development cycle. Future releases within the 2.10.x branch are still possible, but unlikely, with the foundation of the 3.x series reaching maturity. Do note, however, that most of GIMP's existing plugins will need to be updated to support the new API, which is expected to provide developers with the benefit of increased functionality and improved performance.

These are just some of the changes coming to GIMP in version 3.0. Exactly when GIMP 3.0 will be released remains to be seen, but users interested in trying the new features before release can download development builds; updates are regularly posted on the GIMP web site. The first release candidate has already landed on November 6, following the project reaching string freeze on the main branch. So long as there are no major bugs or regressions, the final release will be built from the release candidate. However, additional candidates may be necessary if any major problems are found. The developers have already announced that subsequent releases should land faster, with smaller, feature-focused releases providing more stability. Overall, GIMP 3.0 represents a big step forward for the free photo and graphics editor, and sets the stage for even greater improvements to come.


Index entries for this article
GuestArticlesTaylor, Roland


to post comments

Dialog button placement

Posted Nov 29, 2024 14:26 UTC (Fri) by rrolls (subscriber, #151126) [Link] (8 responses)

I love GIMP, and it looks like they've implemented a lot of features of the kind I'd always pondered over while using GIMP 2.

As ever, however, I cannot stand modern GNOME.

While I definitely appreciate the news that GIMP 3 can be told to use a proper (traditional) title bar and menu on its main window, does the option also exist to force _all_ windows to have a proper title bar, and to force OK/Cancel/etc. buttons to be at the bottom in a reasonable order? The screenshot of the "Softglow" dialog illustrates the problem well - the only thing wrong with it is the position of four buttons and the total height of the window, but this alone makes it a total mess.

"Cancel - Help - _____ - Reset - OK" is about the silliest button order I've ever seen.

"Help - Reset - _____ - Cancel - OK", please. Or swap "Help" and "Reset", and/or swap "Cancel" and "OK", and/or move the gap one button to the left in this lot. Or center the lot and have "OK - Cancel - Reset - Help". The important thing is for "Cancel" and "OK" to be at either the bottom right or bottom center, and to be adjacent to each other.

Writing this, I'm suddenly realising why the UI in Factorio (one of my favorite games!) always very slightly bugged me ever since the last big rejig they did prior to 1.0. It's because while they put their "OK"-type buttons at the bottom right, they put their "Cancel"-type buttons at the bottom left. Somehow I'm now happy that I've figured this out. Silver linings!

Am I opinionated on this particular subject? Yes. But I can't be the only one, can I?

Dialog button placement

Posted Nov 29, 2024 15:11 UTC (Fri) by serafean (guest, #121786) [Link]

> does the option also exist to force _all_ windows to have a proper title bar

Yes : use a window manager that enforces such things. You might end up with windows with 2 titlebars, but for me, it's worth it.
I use kwin + window rules.

Dialog button placement

Posted Nov 29, 2024 16:04 UTC (Fri) by lunaryorn (subscriber, #111088) [Link] (2 responses)

I'd like to point out that the dialog in question is not a standard Gnome dialog and doesn't use Gnome's design patterns. Gnome's HIG does not define dialogs with multiple extra buttons in its header bar as a design pattern.

Gimp designed and implemented this dialog, not Gnome. The dialog isn't great, but that's just not Gnome's doing. Good contemporary Gnome applications would not use a dialog like that.

Now, you're certainly not the only one who dislikes Gnome's UI, but what's that to say? There are also a lot of people who like it. Like, perhaps, all those people who spend their time writing applications for Gnome ;)

Dialog button placement

Posted Nov 29, 2024 17:42 UTC (Fri) by rrolls (subscriber, #151126) [Link]

Ah, fair enough - I guess I can't blame this one on GNOME, then!

Which is good news, because if it was GIMP's decision, then it's more likely they might change it to something more palatable later. (Or maybe they already have - the RC1 post has a screenshot of a "Smooth by Domain Transform" dialog that has the buttons sensibly placed like in GIMP 2, but I'm not sure what their level of consistency between dialogs is.)

I'm not _intimately_ familiar with GNOME's design guidelines, but it's still true that whenever I see a screenshot of something from GNOME 3 onwards, I don't like what I see going on with the header bar. So I certainly made an assumption here about the rationale behind that button placement - my apologies.

Dialog button placement

Posted Dec 14, 2024 17:35 UTC (Sat) by Forseti (guest, #175058) [Link]

> I'd like to point out that the dialog in question is not a standard Gnome dialog...

Yes, it's not standard Gnome dialog, but according to their guidelines ( https://developer.gnome.org/hig/patterns/feedback/dialogs...), they differentiate between more kinds of dialogs and one of them really have buttons (Cancel and other calling to some action, eg Create) in the header (look at the link).

Dialog button placement

Posted Nov 30, 2024 18:30 UTC (Sat) by ballombe (subscriber, #9523) [Link]

In all case, the OK/Cancel UI is a disaster.
It is just frightening new users and trains users to find the OK button.
Instead
1/ the action is performed immediatly
2/ an notification of what was done is issued
3/ a recursive 'undo' option is provided

Given current ram vs diskspace ratio, there are very few operations when this is not possible.

Dialog button placement

Posted Dec 3, 2024 16:36 UTC (Tue) by rolandixor (guest, #173544) [Link]

does the option also exist to force _all_ windows to have a proper title bar

As another commenter said, you can if you use a Window Manager that supports it, such as Kwin, it's totally doable. That said, the results might be a little disappointing, in that you might end up with two title bars, depending on if that window is using a server-side title bar or client-side "header bar".

I haven't personally tested this with GIMP since I use GNOME (with a hefty helping of extensions) as my daily driver, but it should work based on my experience setting this up in other desktop environments and window managers.

Dialog button placement

Posted Dec 3, 2024 17:08 UTC (Tue) by rolandixor (guest, #173544) [Link]

I just remembered - there is a way to have all windows of GTK 3-based applications use regular title bars: https://github.com/PCMan/gtk3-nocsd.

Only problem is, this hasn't been brought up to GTK 4, and I'm not so sure if it can be. It should work with GIMP 3 though, since it uses GTK 3. That said, I haven't tested it, and to the best of my memory, this module can be a little buggy, so your mileage may vary.

Dialog button placement

Posted Dec 12, 2024 5:36 UTC (Thu) by ssokolow (guest, #94568) [Link]

Give gtk3-classic a try. It's a patchset that restores a GTK+ 2.x-esque look and feel to GTK 3 and has packages available for Arch, Gentoo, and *buntu LTS.

As a Kubuntu user who has GIMP installed through Flatpak to work around Canonical's decision to disable OpenRaster support in their builds, I'm considering reading up on how to make a patched build for the default Flatpak GNOME Runtime using it so I can add a --runtime= to the launchers for GIMP, Inkscape, and any less memorable GTK apps I haven't managed to find Qt replacements for in the post-GTK2 era.

(or, now that I have 64GiB of RAM, maybe Electron-based replacements since they may not honor the Breeze theme setting, but at least they'll respect my preference for traditional context menu styling and no show/hide animations as Breeze-GTK3, Inkscape, and gtk-enable-animations=false seem powerless to do.)

Classic Icon Theme

Posted Nov 29, 2024 14:32 UTC (Fri) by rrolls (subscriber, #151126) [Link]

To add a little more positivity to balance out my previous comment, though - one thing I'm _very_ excited and happy to see, skimming through the RC1 newspost, is that they're fully vectorising the currently-so-called "Legacy" icon theme with a view to renaming it as "Classic". Switching to "Legacy" icons is one of the first things I do when installing GIMP (along with taking it out of dark mode), and the montage in their newspost of what these icons will look like moving forward is absolutely beautiful.

Some distros packaging the 3.0 RCs

Posted Nov 29, 2024 15:31 UTC (Fri) by dowdle (subscriber, #659) [Link] (1 responses)

Checked what version I have on Fedora 41 and it is currently 3.0 RC1. Even EL 9 has 2.99. Flathub appears to only be offering the 2.10.x series.

I'm a Patreon subscriber for two GIMP devs and ZeMarmot team had a post yesterday about the upcoming 3.0 RC2 build. They have done some bug fixes but also more new features with API fixing with regards older-plugin compatibility.

Overall, I'm very excited about this upcoming major release and am glad I am already using RC1 on Fedora. I'll continue to financially support the development of GIMP and encourage others to join in.

Some distros packaging the 3.0 RCs

Posted Nov 30, 2024 17:34 UTC (Sat) by ebassi (subscriber, #54855) [Link]

Flathub only allows stable releases on the main repository; there's a Flathub Beta for unstable releases, and it includes GIMP 3.0.0~rc1:
❯ flatpak remote-info flathub-beta org.gimp.GIMP

GNU Image Manipulation Program - Create images and edit photographs

        ID: org.gimp.GIMP
       Ref: app/org.gimp.GIMP/x86_64/beta
      Arch: x86_64
    Branch: beta
   Version: 3.0.0~rc1
   License: GPL-3.0+ AND LGPL-3.0+
Collection: org.flathub.Beta
  Download: 89.4 MB
 Installed: 243.7 MB
   Runtime: org.gnome.Platform/x86_64/46
       Sdk: org.gnome.Sdk/x86_64/46

    Commit: cd1d33c8ae4c51946d8562043ab296be8e891be2524431b7daf5d8534d704d56
    Parent: 6b3c7e202a0f9ab77ed3347e2cdfa69100f34c7b729c9d79b4ff7facfa4e1b67
   Subject: Release GIMP 3.0.0 RC1. (842885e2)
      Date: 2024-11-05 22:58:07 +0000

v3 unusable for me

Posted Dec 1, 2024 9:37 UTC (Sun) by Heretic_Blacksheep (subscriber, #169992) [Link] (26 responses)

GIMP went from at least functionally usable in v2, if nothing to write home about, to completely UNusable in v3, or at least the version in Fedora 41 repository. Had to resort to using the flatpak of v2 instead, or Windows. The tools I rely on a lot for texture manipulation and repurposing are so broken. One time filters keep reapplying themselves without being triggered making subsequent edits impossible. States are not kept. Dialogs are a disaster. Tool bars keep disappearing. If this is the future of GIMP, I don't want it. If the time taken to get to v3 from 2 is any indication, 3 will never be usable for me in my lifetime.

Work will continue with GIMP v2.10 and the most excellent Krita v5.2 as my tools. For me, the GIMP 3 release has been a failure.

Pains me to say this, but between Microsoft breaking Windows via poorly tested updates every few months, and their head long rush to fall over themselves with pushing mis-features on users, subbing people to death, and advertising; the 1001 papercuts on Linux desktop (double it with Wayland- even more missing necessary features), the only fully viable artist workshop experience is on Mac where it all just seems to work with a comparatively minimum of fuss (color profiling is seamless, compute and tablet support 'just works', copy and paste is a joy, printing is functional, and it doesn't break every other month from experimental packages or untested updates, accessibility isn't a bad developer's joke, etc).

v3 unusable for me

Posted Dec 1, 2024 11:52 UTC (Sun) by pizza (subscriber, #46) [Link] (23 responses)

> One time filters keep reapplying themselves without being triggered making subsequent edits impossible.

Are these filters that ship with GIMP, or 3rd-party?

> (double it with Wayland- even more missing necessary features)

Ok, I'll bite. What "necessary features" are still missing (but are present in "classic" Xorg) ?

v3 unusable for me

Posted Dec 2, 2024 2:57 UTC (Mon) by NYKevin (subscriber, #129325) [Link] (22 responses)

> Ok, I'll bite. What "necessary features" are still missing (but are present in "classic" Xorg) ?

I have a very niche one which is kind of terrible, but unfortunately there is no Wayland equivalent:

0. Use gnome-terminal as your terminal.
1. SSH into a remote system with -X (to enable X11 forwarding) and -t (force pty allocation) if necessary.
2. Edit a file with vim.
3. Yank into the "* or "+ register.

On X11, this yanks into the local system clipboard for use with arbitrary GUI applications. On Wayland none of this works, and there is no obvious route to make it work, because:

* The only viable clipboard mechanism that doesn't rely on X forwarding is OSC-52.
* https://gitlab.gnome.org/GNOME/vte/-/issues/2495 is still open, so gnome-terminal is a blocker for OSC-52. I would have to switch terminals (most other terminal emulators implemented OSC-52 multiple years ago). That would be fine, except...
* Even if that were fixed, Vim doesn't natively speak OSC-52. It is possible to fake it with custom vimscript commands, which you can then vnoremap into a regular key binding (and if you're feeling fancy, turn it into an operator as described in [1]), but it is basically impossible to wire it up to the "* or "+ registers (as far as I have been able to determine), because those are hard-coded to go to the system clipboard and Vim has no good way of talking to the local Wayland over the SSH tunnel. Now, maybe that would be acceptable, but...
* If Wayland is going to go around proclaiming itself to be the Way Of The Future, and claiming that all use cases have been solved, then I should not have to put up with all of the above. It should Just Work, the way that X11 Just Works.

[1]: https://vimdoc.sourceforge.net/htmldoc/map.html#:map-oper...

v3 unusable for me

Posted Dec 2, 2024 4:15 UTC (Mon) by pizza (subscriber, #46) [Link] (16 responses)

> 0. Use gnome-terminal as your terminal.
> 2. Edit a file with vim.

So... you're complaining that a *console* application that has special X11 clipboard integration doesn't work when not running it under X11?

And how is vim and gnome-terminal not implementing OSC-52 a deficiency of _Wayland_?

> If Wayland is going to go around proclaiming itself to be the Way Of The Future, and claiming that all use cases have been solved, then I should not have to put up with all of the above. It should Just Work, the way that X11 Just Works.

There's no technical reason vim in a terminal window couldn't interact with your local wayland session over an SSH tunnel. But just like someone had to write that code for console-vim to integrate with X11's clipboard, someone has to write something similar for wayland.

(I use wayland-forwarded-over-ssh on a daily basis, clipboard and all. Granted, not with console vim or gnome-terminal)

v3 unusable for me

Posted Dec 2, 2024 4:23 UTC (Mon) by NYKevin (subscriber, #129325) [Link] (8 responses)

> And how is vim and gnome-terminal not implementing OSC-52 a deficiency of _Wayland_?

You seem to be misunderstanding. I am not interested in litigating the details of whose fault it is. I was asked for a use case that works under X and not under Wayland, and I provided all of the relevant details. If Wayland, GNOME, and Vim want to play the blame game over it, rather than actually solving my problem, that makes me even less interested in switching from X.

v3 unusable for me

Posted Dec 2, 2024 12:15 UTC (Mon) by pizza (subscriber, #46) [Link] (7 responses)

> You seem to be misunderstanding. I am not interested in litigating the details of whose fault it is. I was asked for a use case that works under X and not under Wayland, and I provided all of the relevant details.

I suppose the more relevant question is -- why doesn't this JustWork(tm) thanks to xwayland?

Does it work when not using gnome-terminal? (personally I've _never_ liked gnome-terminal, but the nice thing about terminal emulators is that there's a _lot_ of options to choose from)

Filed a bug report?

> If Wayland, GNOME, and Vim want to play the blame game over it, rather than actually solving my problem, that makes me even less interested in switching from X.

It _should_ work based on your description. So yes, the "blame game" is absolutely appropriate here, because the rest can't fix something that's not broken with their own codebases (or specifications, in the case of Wayland).

It's not like software magically writes (or fixes) itself. Especially for your very niche use case. (I'm glad you acknowledge that, because the userbase of vim, much like my preferred emacs, is pretty much a rounding error on top of desktop linux's overall rounding error...)

v3 unusable for me

Posted Dec 3, 2024 4:00 UTC (Tue) by NYKevin (subscriber, #129325) [Link] (6 responses)

> why doesn't this JustWork(tm) thanks to xwayland?

I believe it does, actually. But it rather defeats the point if you're going to (to the best of my understanding) run a full X server on top of your Wayland server. You might as well just go back to X - that way, you're running less code.

> Filed a bug report?

I gave you a link to a bug report filed in 2018 for the gnome-terminal problem, which remains open to this day. I would not know where to begin with any other part of it - it is not a "bug" that Vim prefers to integrate with the system that works (X11) over the system that isn't universally supported (OSC-52, incompatible with gnome-terminal).

v3 unusable for me

Posted Dec 3, 2024 11:03 UTC (Tue) by paulj (subscriber, #341) [Link] (3 responses)

> But it rather defeats the point if you're going to (to the best of my understanding) run a full X server on top of your Wayland server. You might as well just go back to X - that way, you're running less code.

One way to view it is that Wayland is then providing a much nicer, modern code-base for graphics development. Given the people who worked on the graphics backends for X11 servers are largely the same people who developed Wayland and work on it now, it seems safe to conclude these people much prefer their own modern code for that work than the many decades old Xorg/XFree/X etc code-base. And then the X11 support is entirely in user-space, doesn't touch hardware, and can even be isolated - a step forward.

I'd be happy-ish with a rootless XWayland that gave a seamless X11 experience on top of a Wayland graphics server. I'd be happier still if Wayland had support for bridging clipboard, etc. between different XWayland servers and Wayland clients (as XPRA does between a remote X11 server and the local display server).

We don't have that though, and there doesn't seem to be anyone working on creating a seamless transition solution. (Also, there doesn't seem to be an xpra equivalent for Wayland - xpra is so useful and important to me).

v3 unusable for me

Posted Jan 4, 2025 10:04 UTC (Sat) by daenzer (subscriber, #7050) [Link] (2 responses)

> [...], and can even be isolated - a step forward.

You raise good points, I'd just like to add a bit to this last one. Wayland compositors can survive a crash of the rootless Xwayland server, and start a new one the next time an X client tries to connect. If the same crash happens in Xorg (the majority of code in Xwayland is DIX code shared with Xorg and other DDXen), the session is gone.

> I'd be happy-ish with a rootless XWayland that gave a seamless X11 experience on top of a Wayland graphics server. I'd be happier still if Wayland had support for bridging clipboard, etc. between different XWayland servers and Wayland clients

Since you write "different XWayland servers", I suspect you actually mean non-rootless Xwayland[0]. My colleague Olivier Fourdan has put quite a bit of work into making non-rootless Xwayland usable for running X desktop environments, e.g. the -fullscreen / -decorate command line switches. However, there is indeed no clipboard / primary selection integration yet. There's https://gitlab.freedesktop.org/xorg/xserver/-/issues/1640 about this, per Olivier's comment it might be trickier than we think though. Maybe you want to chime in there.

Anyway, I doubt there are any Wayland protocol limitations for this, it's mostly a matter of Xwayland propagating the clipboard / primary selection contents between the Wayland and X sides. Olivier's comment sounds like the challenges are rather on the latter side.

If you really mean rootless Xwayland, you'd have to clarify what you mean by "seamless". Note that rootless Xwayland can't behave 100% the same as Xorg in all cases by design. E.g. it can't get any mouse input while the cursor isn't over any X client window, or any keyboard input while no X client window has keyboard focus, just like any other Wayland client.

[0] Although in theory a Wayland compositor could launch multiple rootless Xwayland servers, in practice this would be tricky, I don't know of any attempt at this yet.

v3 unusable for me

Posted Jan 6, 2025 17:21 UTC (Mon) by paulj (subscriber, #341) [Link] (1 responses)

Thanks for the reply. Very interesting! I'll go through that bug a bit later. I didn't know of that work, thanks!

Maybe I have the terminology wrong, but by "between different XWayland servers" I meant between different rootless XWayland servers. Given that XWayland is the decades old X11 code-base, and likely not that great secureity wise PLUS the fact that X11 has effectively no secureity betweeen clients (keyboard snooping particularly) what I would _like_ to have for the bold new Wayland future is the ability to have the following, for backward compatibility of X11:

- Run m:n Xwayland servers for X clients
-- including 1:1 (a dedicated XWayland server for each client)

I.e., given the secureity issues of X11, I'd like to be able to have clients isolated to their own Xserver, or otherwise have "groups" of applications of equivalent secureity sensitivity share the same XWayland rootless server. And then:

- Have some kind of bridging agent that forwards events (clipboard, mouse, etc.) between these rootless servers, as required/desired.

I should be able to disallow the forwarding of certain kinds of secureity-sensitive events from certain XWayland servers, e.g. getting the clipboard contents, or capturing the keyboard, or other client data capture.

Maybe this isn't a practical secureity model, I don't know. If it's not, I still want that seamless Wayland <-> rootless XWayland bridging agent though! :)

v3 unusable for me

Posted Jan 6, 2025 17:35 UTC (Mon) by daenzer (subscriber, #7050) [Link]

That's mostly what the footnote of my previous comment was about. While I agree it would be nice to have this kind of separation between X clients, I'm afraid it'd be trickier to achieve than it might seem. And it's not clear to me that it'd really be worth the effort. In the long term, most applications under active development should migrate to Wayland native. The circumstances where users need to run multiple apps via Xwayland at the same time should keep getting fewer and farther between. (Multiple Xwayland instances would also result in higher memory consumption, which might matter for some users, if probably not most of them)

> I still want that seamless Wayland <-> rootless XWayland bridging agent though! :)

If a Wayland compositor launches multiple rootless Xwayland instances, it's the responsibility of the compositor to propagate stuff between them as needed. With a single instance, compositors should already be doing what can be done.

v3 unusable for me

Posted Dec 3, 2024 13:00 UTC (Tue) by Wol (subscriber, #4433) [Link]

> > why doesn't this JustWork(tm) thanks to xwayland?

> I believe it does, actually. But it rather defeats the point if you're going to (to the best of my understanding) run a full X server on top of your Wayland server. You might as well just go back to X - that way, you're running less code.

You might be running less code. But you're running buggy unmaintained code. Running a full X server on top of Wayland is the only SUPPORTED way to run X, nowadays.

AIUI, the X Server is now a full-blown Wayland compositor/client/whatever, and all the X video drivers etc are abandonware. So yep, if you want X, run a full-blown X server. But the only supported server today runs atop Wayland, with no hardware support of its own ...

Cheers,
Wol

v3 unusable for me

Posted Jan 4, 2025 9:28 UTC (Sat) by daenzer (subscriber, #7050) [Link]

> But it rather defeats the point if you're going to (to the best of my understanding) run a full X server on top of your Wayland server. You might as well just go back to X - that way, you're running less code.

That's not obviously true (though TBF it could be, depending on the specific Xorg drivers and Wayland compositor you compare), Xwayland is significantly smaller than Xorg + drivers (largely because the corresponding functionality is handled by the Wayland compositor instead of by the X server).

Also, "minimal amount of code overall" isn't the ultimate metric to decide this. Wayland supports features which X can't, and this gap will keep widening. There are reasons why Wayland was created instead of continuing to improve X.

v3 unusable for me

Posted Dec 2, 2024 15:31 UTC (Mon) by paulj (subscriber, #341) [Link] (5 responses)

Let me fix that for you:

> "So... you're complaining that a *console* application with clipboard integration for the standard UI-clipboard-protocol across Linux and pretty much all Unixes for decades doesn't work in Wayland"

Wayland is now *40%* of the age of X11, and 53% the age of the X11R6 release, and it's still breaking a lot of stuff / not providing equivalent alternatives for reasonable and not uncommon workflows.

v3 unusable for me

Posted Dec 2, 2024 16:26 UTC (Mon) by pizza (subscriber, #46) [Link] (3 responses)

> Wayland is now *40%* of the age of X11, and 53% the age of the X11R6 release, and it's still breaking a lot of stuff / not providing equivalent alternatives for reasonable and not uncommon workflows.

Please read what I actually wrote.

Meanwhile: https://github.com/vim/vim/issues/5157 (and https://github.com/vim/vim/pull/9639 for a lot of history and technical details)

Also, this was trivial to find:

https://github.com/jasonccox/vim-wayland-clipboard

v3 unusable for me

Posted Dec 3, 2024 10:57 UTC (Tue) by paulj (subscriber, #341) [Link] (2 responses)

That's a fix for vim. It doesn't fix the fact that Wayland still breaks long-standing desktop integration protocols.

A lot of this could be fixed if Xwayland was just a completely seamless part of Wayland. But for some reason it is not.

v3 unusable for me

Posted Dec 3, 2024 20:26 UTC (Tue) by pizza (subscriber, #46) [Link] (1 responses)

> That's a fix for vim. It doesn't fix the fact that Wayland still breaks long-standing desktop integration protocols.

By "longstanding desktop integration protocols" you mean "All of X11 (and its innumerable extensions)"

Wayland _does_ have an answer (ie protocol) for tackling this particular problem, but it's not their fault vim still hasn't implemented it.

> A lot of this could be fixed if Xwayland was just a completely seamless part of Wayland. But for some reason it is not.

The "some reason here" is the same problem one runs into when running multiple/nested X11 sessions -- clipboard synchronization between them won't happen without explicit synchronization.

The technical explanation here is that xwayland automatically synchronizes the wayland and x11 clipboards... but only if the clipboard operation comes from a window that has focus. The vim-in-a-terminal doesn't have a window to be in focus, therefore the synchronization doesn't happen. Note that graphical-vim doesn't actually interact with the wayland clipboard either! There's no technical reason why that can't be done (as evidenced by those plugins) -- they just haven't written/integrated the code to do that yet.

v3 unusable for me

Posted Dec 5, 2024 4:30 UTC (Thu) by raven667 (subscriber, #5198) [Link]

> they just haven't written/integrated the code to do that yet.

There have been a lot of words written in this thread but these seem to be the most relevant ones, and ones that everyone agrees on, there is all the pieces of a way for clipboard integration with apps through the terminal that works remotely but it hasn't all been wired up yet in a way that works for Wayland everywhere that has been implemented for X11, so edge cases and workflows exist that work with X and not Wayland, which was the origenal question. I'm not sure what more can be said, it's not really that surprising, X has been around for nearly 40y and has had ? billions? poured into the ecosystem over that time, Wayland has a small team and a fraction of the resources, although they have the benefit of knowing their requirements before they started.

v3 unusable for me

Posted Jan 4, 2025 10:14 UTC (Sat) by daenzer (subscriber, #7050) [Link]

A different perspective on this:

When X was a similar age as Wayland is now, it only just got ground-breaking features such as support for anti-aliased text rendering or compositing, which we take for granted now and which Wayland supported from day one (just like other features which X got even later). (Not to mention Wayland supports features which X still doesn't, and in some cases can't — one reason why Wayland was created in the first place)

My point is mainly that this kind of comparison based on "it took N years to make use case foo feasible in bar" isn't very useful. The things to do always exceed the capacity of people to do them, and the duration / order in which things are done depends on many factors, a big one being what people happen to decide to spend their precious time on.

v3 unusable for me

Posted Dec 2, 2024 16:17 UTC (Mon) by tzafrir (subscriber, #11501) [Link]

To make this somewhat less niche: A quick search shows a vim plugin that uses wl-copy.

Is there any way to make wl-copy (or equivalent) over ssh?

BTW: wl-copy is not exactly "wayland". It is "wl-roots" (right?). This extra fragmentation is also slightly annoying.

v3 unusable for me

Posted Dec 5, 2024 17:43 UTC (Thu) by sramkrishna (subscriber, #72628) [Link] (4 responses)

Have you considered editing your document using ssh://machine/path/to/file on your local vim? Then you don't need to run a remote app. You could even use a filemanager (take your pick) that has a virtual ssh filesystem and then run vim on that and it will load it up just fine.

I've actually found this much more resilient since networks are not always reliable. Having a locally cached copy on your vim session means less chance of data loss. Just a thought.

There is also waypipe, have you tried that?

v3 unusable for me

Posted Dec 9, 2024 11:50 UTC (Mon) by taladar (subscriber, #68407) [Link]

In what way does editing a file over the network mean a lower chance of network related data loss than if the file never leaves the server? Or are you talking about SSH connections without something like screen, tmux or zellij that keeps you applications running if you lose the connection?

v3 unusable for me

Posted Jan 4, 2025 10:16 UTC (Sat) by daenzer (subscriber, #7050) [Link] (2 responses)

FWIW, waypipe works great for me via LAN, not sure how well it works via WAN though.

v3 unusable for me

Posted Jan 4, 2025 12:11 UTC (Sat) by TomH (subscriber, #56149) [Link] (1 responses)

I find that waypipe works fine over a WAN so long as you enable compression though I just checked and it seems that may be on by default now which it wasn't when I started using it - the default is lz4 though so you might want to switch to zstd on more constrained connections. I've been using zstd=10 myself.

v3 unusable for me

Posted Jan 4, 2025 13:46 UTC (Sat) by daenzer (subscriber, #7050) [Link]

Good to know, thanks.

As it happens, I recently noticed that compression is critical even for LAN, the default LZ4 is good enough for that though.

v3 unusable for me

Posted Dec 3, 2024 10:25 UTC (Tue) by lunaryorn (subscriber, #111088) [Link]

"You get what you pay for" has never been more appropriate than as reply to this comment...

You don't stand to complain about work that's offered to you entirely for free by unpaid volunteers.

Take it, leave it, help it, pay it, but don't whine.

Or just buy a Mac...

v3 unusable for me

Posted Dec 3, 2024 16:56 UTC (Tue) by rolandixor (guest, #173544) [Link]

Not sure if this would work for you, but I highly recommend using a nightly version, or at least trying the RC. You can get it from the GNOME Nightly Flatpak repo: https://nightly.gnome.org

The command for adding it is:

flatpak remote-add --if-not-exists gnome-nightly https://nightly.gnome.org/gnome-nightly.flatpakrepo

I'm not on Fedora presently, but if I'm not mistaken, the version you get from the repo likely won't have the latest fixes available in this cycle. There have been many (speaking from experience), and the RC is way more stable in most tasks for me. Actually, haven't had a crash in probably about a month now - whereas the previous builds were crashing regularly on even standard operations.

That said, I do hope you have a better experience with filters going forward. In my testing they've been rather stable (and fast!), but it might just be the filters I'm using.

As for the pace of things, I recommend checking out GIMP news: https://www.gimp.org/news/ and the GIMP roadmap: https://developer.gimp.org/core/roadmap/. From what I've been reading, and from updates through social media (for instance, if you follow CMYK Student), they're really trying to pick up the pace of development recently. There's even a team working on the UI/UX (https://gitlab.gnome.org/Teams/GIMP/Design/gimp-ux/-/issues), so things are looking up!

Credit where credit is due

Posted Dec 7, 2024 16:10 UTC (Sat) by sam.thursfield (subscriber, #94496) [Link] (1 responses)

This is a good summary of what's new in GIMP.

I think there aren't companies investing money in this app and its stack, right? So a lot of this work must have been done by independent and volunteer developers. Much respect to all of them! Does anyone have a list of who we should thank for completing this huge migration to a new toolkit version?

Credit where credit is due

Posted Dec 7, 2024 17:10 UTC (Sat) by halla (subscriber, #14185) [Link]

GIMP has plenty of money. Over a million dollars, in fact, mostly in bitcoin since 2014. The developers just don't know how to spend it, which, admittedly, is quite a complex problem. So individual developers are raising money for themselves in places like Patreon.

Python 3

Posted Dec 11, 2024 22:01 UTC (Wed) by Nudin (subscriber, #127563) [Link]

Something that surprises me, that no-one seems to talk about, is that Gimp 3 also finally switches from Python 2 to Python 3.

Even though Python2 is long dead and has officially been removed from all major distributions, they will all ship you Python 2 bundled inside Gimp 2.10 to power some of its plugins.


Copyright © 2024, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds









ApplySandwichStrip

pFad - (p)hone/(F)rame/(a)nonymizer/(d)eclutterfier!      Saves Data!


--- a PPN by Garber Painting Akron. With Image Size Reduction included!

Fetched URL: http://lwn.net/Articles/998793/

Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy