LWN: Comments on "GIMP 3.0 — a milestone for open-source image editing"

v3 unusable for me

daenzer — Mon, 06 Jan 2025 17:35:06 +0000

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

paulj — Mon, 06 Jan 2025 17:21:14 +0000

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 security wise PLUS the fact that X11 has effectively no security 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 security 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 security 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 security-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 security model, I don't know. If it's not, I still want that seamless Wayland <-> rootless XWayland bridging agent though! :)

v3 unusable for me

daenzer — Sat, 04 Jan 2025 13:46:25 +0000

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

TomH — Sat, 04 Jan 2025 12:11:16 +0000

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

daenzer — Sat, 04 Jan 2025 10:16:57 +0000

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

v3 unusable for me

daenzer — Sat, 04 Jan 2025 10:14:45 +0000

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

daenzer — Sat, 04 Jan 2025 10:04:07 +0000

> [...], 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

daenzer — Sat, 04 Jan 2025 09:28:35 +0000

> 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.

Dialog button placement

Forseti — Sat, 14 Dec 2024 17:35:45 +0000

> 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

ssokolow — Thu, 12 Dec 2024 05:36:06 +0000

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.)

Python 3

Nudin — Wed, 11 Dec 2024 22:01:28 +0000

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.

v3 unusable for me

taladar — Mon, 09 Dec 2024 11:50:13 +0000

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?

Credit where credit is due

halla — Sat, 07 Dec 2024 17:10:53 +0000

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.

Credit where credit is due

sam.thursfield — Sat, 07 Dec 2024 16:10:40 +0000

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?

v3 unusable for me

sramkrishna — Thu, 05 Dec 2024 17:43:05 +0000

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

raven667 — Thu, 05 Dec 2024 04:30:10 +0000

> 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 original 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

pizza — Tue, 03 Dec 2024 20:26:38 +0000

> 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.

Dialog button placement

rolandixor — Tue, 03 Dec 2024 17:08:41 +0000

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.

v3 unusable for me

rolandixor — Tue, 03 Dec 2024 16:56:48 +0000

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!

Dialog button placement

rolandixor — Tue, 03 Dec 2024 16:36:32 +0000

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.

v3 unusable for me

Wol — Tue, 03 Dec 2024 13:00:03 +0000

> > 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

paulj — Tue, 03 Dec 2024 11:03:13 +0000

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

paulj — Tue, 03 Dec 2024 10:57:17 +0000

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

lunaryorn — Tue, 03 Dec 2024 10:25:49 +0000

"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

NYKevin — Tue, 03 Dec 2024 04:00:24 +0000

> 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

pizza — Mon, 02 Dec 2024 16:26:58 +0000

> 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

tzafrir — Mon, 02 Dec 2024 16:17:45 +0000

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

paulj — Mon, 02 Dec 2024 15:31:21 +0000

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

pizza — Mon, 02 Dec 2024 12:15:09 +0000

> 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

NYKevin — Mon, 02 Dec 2024 04:23:34 +0000

> 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

pizza — Mon, 02 Dec 2024 04:15:31 +0000

> 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

NYKevin — Mon, 02 Dec 2024 02:57:47 +0000

> 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

pizza — Sun, 01 Dec 2024 11:52:31 +0000

> 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

Heretic_Blacksheep — Sun, 01 Dec 2024 09:37:46 +0000

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).

Dialog button placement

ballombe — Sat, 30 Nov 2024 18:30:31 +0000

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.

Some distros packaging the 3.0 RCs

ebassi — Sat, 30 Nov 2024 17:34:07 +0000

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

Dialog button placement

rrolls — Fri, 29 Nov 2024 17:42:04 +0000

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

lunaryorn — Fri, 29 Nov 2024 16:04:48 +0000

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 ;)

Some distros packaging the 3.0 RCs

dowdle — Fri, 29 Nov 2024 15:31:15 +0000

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.

Dialog button placement

serafean — Fri, 29 Nov 2024 15:11:46 +0000

> 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.