XFCE 4.20 Aiming for Usable Wayland Support While Maintaining X11 Compatibility | Hacker News Reader

XFCE 4.20 Aiming for Usable Wayland Support While Maintaining X11 Compatibility

phoronix.com

73 pointstorstenvl78 comments

XFCE released in 2014 has significantly less bugs than XFCE today: and that's all due to Gtk3 being broken underneath.

Things are going to get much harder as the Gtk foundations keep being eroded away by the GNOME people removing features and options from Gtk. And they're basically hard coding in wayland spec now, no considerations for X.

The Gtk based DEs like XFCE/MATE/Mint/etc need to band together and fork/mantain Gtk3 if they have any hope of surviving long term or even fixing the multiple bugs introduced by progressive removal of Gtk features (like the 2014 breaking of gtkfilechooserwidget.c so you can't paste in file paths).

Waiting for the first RedHat+Gnome lawsuit against nerds trying to maintain old software

How so? It's all FOSS.

X is in maintenance mode. All new development happens around Wayland. It makes complete sense for GTK to focus on Wayland. COSMIC, MATE, XFCE, Cinnamon, Budgie, and Pantheon are all shipping at least some support for Wayland.

What features and options of GTK have been eroded by GNOME?

Do you really think XFCE, MATE, and Mint have resources to maintain a GTK fork? Why don't you maintain the GTK fork? GTK maintenance is partially paid for by Red Hat and Endless, among a few other organizations.

I think it is really interesting how every time GNOME and GTK get mentioned on this site, you are quick to post negative comments.

I never knew Endless was funding GTK development. The last time I heard about Endless OS was years ago.

Like I said partially. Other organizations include Igalia, Collabora, and the GNOME Foundation, just off the top of my head.

New is not better (wayland cannot abolutely position new windows, cannot do mouse keyboard sharing (except via non-standard libei which different waylands reject, etc). Unchanging is not broken (X11 works just fine, just because it's not constantly getting new code doesn't mean it stops working).

The primary features I'm missing focus around the way GNOME developers believe files should be interacted with. They believe the file chooser should be a search interface and making things like pathbar the only option and removing filename-entry, and the entire gsettings for it, are part of this. GNOME developers have drastically changed the GUI for file selection so that typing, pasting, or entering filepaths has been made difficult. Everything has to be done through the automagic "search" (which often bugs out) or mouse interface. This would be fine as defaults, but they've literally removed the former options in gsettings to config a gtk application's behavior. They say these are "private" and we should never have been using them all. All bugs since 2014 marked "wontfix" and community patches rejected. Basically, GNOME is anti-keyboard.

I think that the gross changes to Gtk3 over the past 10 years have been minimal and that yes, a group of a dozen people could maintain it in it's static form and prevent further eroding of features. I compile my own Gtk3 with fixes for the gtkfilechooserwidget.c that have been rejected by the Gtk team ("gtk3 is frozen" "filechooser is too much spaghetti, any change fixing one thing would break another"). Maybe even apply some of the many community fixes that the GNOME developers consistent reject and ignore (just look at the Arch Gtk3 fixes patch set). Can they develop and add new features like new renderers and support for Wayland? No, but that is not needed.

I don't appreciate you turning this into a personal issue, that's generally against HN tos.

It would be good if interested parts of the community maintained its own fork of Gtk3 and get involved with X development to keep it alive.

Perhaps it's time for someone to fork GTK+3. It's clear that the GNOME guys are beyond done with maintaining old GTK code (and I can't blame them) and the ecosystem for old applications won't move forward trying to patch code in a project that's essentially on hold.

It shouldn't be too difficult to fork the project and produce drop-in libraries for projects based on GTK+2/3 with patches applied. Through the desktop portal API, these changes would even apply completely transparently for windows like file pickers.

There's such a big online crowd clearly voicing their opposition to the direction GNOME is taking GTK and other software, I don't get why these people don't just get together, set up a website and a forum somewhere, and split off to do the things GNOME doesn't want to do.

> There's such a big online crowd clearly voicing their opposition to the > direction GNOME is taking GTK and other software, I don't get why these people > don't just get together, set up a website and a forum somewhere, and split off > to do the things GNOME doesn't want to do.

Maybe it's just because fighting against the tide is exhausting. Changing the world is young person's game - you need people with energy, enthusiasm, a vision of a better way and enough capacity for self-delusion to believe that it's actual possible. (My cynical streak may be showing here!)

I suspect the "phone first" generation's never going to understand why modern UI fads such as hamburger menus and icons with no clear delineation engender such contempt from us mouse warriors!

I'm old enough to remember the pain of moving from GTK+ 1.2 to GTK+ 2. That's when we lost tab-completion in the file picker. (Boy was that file picker ugly, but you could drive it using the keyboard much more easily than anything designed since, without the mouse being a second-class citizen.)

There were a few obscure pieces of software which took years to be forward ported to Gtk+ 2 because the original authors weren't around any more.

I wrote some software myself against Gtk+ 2 - printing-related - but since I no longer even have a printer at home, I have no interest in updating it for newer Gtk+ - and since it still used Gdk rather than Cairo (because back then Cairo would have made the colour management stuff I was doing impossible - I have no idea whether those limitations have since gone away) - it'd be painful to update anyway.

If I had limitless time, energy, and didn't need to earn a living I'd fork Gtk+ myself just to rid myself of hamburger menus (see my earlier comment about not making the mouse a second-class citizen!)

In the real world I'm jaded and burned-out enough with tech that I see too much else wrong with modern software, and desktop Linux in particular, to expend much of my life trying to hold back the tide of (what I see as) idiocy.

I believe you are referring to https://gitlab.gnome.org/GNOME/nautilus/-/issues/1157 - an incredibly longstanding issue that has been raised and re-raised by dozens if not hundreds of users over the years. As far as I can tell, the devs view it as incompatible with a design principle. Sticking to principle is one thing, but this is truly a head-in-the-sand situation.

The insane thing is how trivial it would be to support it: https://gitlab.gnome.org/GNOME/nautilus/-/merge_requests/103...

Less than 200 lines changed and they act like it would absolutely kill them to maintain it. Even if just 5% of users profited from it, it would be well worth it to support. Yes it adds additional complexity to testing but come on.

This is a clear example of "catch 22" situation:

a) we won't implement this change because it's incompatible with the design;

b) the design was set 10 years ago and never changed since then, so there's no reason to doubt it's sound.

And yet Wayland still does not work on my laptop (tons of graphical glitches, unbearable lag when hooked up to external 4k monitors) whereas X works fine.

I’ve been hearing for years that Wayland is the future and X is deprecated but it doesn’t match my reality.

Blame NVIDIA, because on Intel and AMD it's been smooth sailing for a while now.

The sad thing is that X barely sees development and will die if nobody steps up to maintain it. I hope somebody does, I like it much more than Wayland (not monolithic, first-class network transparency, extendable, ...)

> first-class network transparency

This keeps being touted but it's the only design of its kind, none of the other OSes has this design and newer UIs also don't follow this design. X is an evolutionary dead end, at best a local maxima.

Also, this functionality is used extremely rarely in my experience, 99% of remote driving happens with separate, dedicated, software.

X11 isn't even very good at network transparency. It's overly chatty, especially when dealing with things like pointer events, and it's horribly inefficient at displaying truecolor images, which make up the entirety of most applications nowadays. If a network-transparent display server were a goal, a modern design could do much better.

It works perfectly for me. Inefficiencies could easily be fixed by extensions if necessary. The main thing which is missing in practice is latency hiding. But this is supported by the X protocol just fine, only toolkits were never changed to support it.

Design-wise it is exactly right: A generic remote buffer management protocol.

> But this is supported by the X protocol just fine, only toolkits were never changed to support it.

When we've had toolkits for 30+ years and this hasn't happened, that's called a hint.

Nobody* cares.

Right, it works well even without it.

> Design-wise it is exactly right: A generic remote buffer management protocol.

That's probably a better description of VNC (aka. RFB, "remote framebuffer"). X11 is far from generic; it has a bunch of baked-in concepts for things like windows, named colors, bitmap fonts, selections, a screensaver, and an entire drawing subsystem that's only used by a few legacy apps nowadays. A glance through the protocol, with a particular eye to the "Requests" section, may be enlightening:

https://www.x.org/releases/X11R7.7/doc/xproto/x11protocol.ht...

For comparison, here's VNC. There's some extensions for more efficient ways to send bitmaps over the wire, but the essential concepts of the protocol are unchanged.

https://datatracker.ietf.org/doc/html/rfc6143

The non-generic special parts that were needed in the past can easily be ignored. At its core it is a generic buffer management protocol and it obviously has all the parts for generic buffer management.

The buffer management at X-Windows' core is anything but generic or well designed. See John Steinhart's comments below, estimating it has around 20 different databases, and could have been much better done with just a dozen API calls.

X-Windows is a dozen layers of poorly-designed, less-than-useful, leaky abstractions, systematic race conditions, and complex non-solutions to obsolete non-problems. To the core, and its extensions. Most of which nobody even uses any more. So much useless junk is still required to be there, and the essential stuff nailed on the side as an afterthought that you're still required to use (like ICCCM for example) is terribly designed. And yes, X-Windows is also extremely bad for remote applications, in spite of the fact that's exactly what it was designed for.

"X: The First Fully Modular Software Disaster (Even your dog won't like it.)"

https://donhopkins.medium.com/the-x-windows-disaster-128d398...

John Steinhart thought X-Windows could have been a hell of a lot more modular and less complex, and could have been much more simply and modularly designed and better implemented with "less than a dozen API calls":

https://news.ycombinator.com/item?id=17056516

DonHopkins on May 12, 2018 | parent | context | favorite | on: Build your own X: project-based programming tutori...

Hasn't somebody reimplemented X11 in JavaScript/canvas/websockets yet?

There was an X11 server for Lisp Machines! Not sure who wrote it, but it was probably written inside or at least nearby the X Consortium, and I remember Robert Scheifler used it regularly.

https://news.ycombinator.com/item?id=6864364

"For example the TI Explorer Lisp Machine came with an X11 server written in Lisp. On my Symbolics Lisp Machine I used the usual MIT X11 server written in C - this was possible because the Symbolics Lisp machine had a C compiler." -lispm

John Steinhart wrote XTool, a nice snappy reimplementation of X11 on top of SunView! ;)

https://web.archive.org/web/20171008204348/https://minnie.tu...

https://news.ycombinator.com/item?id=15325226

https://web.archive.org/web/20171028110659/https://minnie.tu...

>XTool was very small and fast compared to the X sample server because I wrote the server from scratch. I think that I'm the only person to write an X server outside of the X Consortium. One of the things that I learned by doing it was that the X Consortium folks were wrong when they said that the documentation was the standard, not the sample server. There were significant differences between the two.

>The only really worthwhile thing about X was the distributed extension registration mechanism. All of the input, graphics and other crap should be moved to extension #1. That way, it won't be mandatory in conforming implementations once that stuff was obsolete. As you probably know, that's where we are today; nobody uses that stuff but it's like the corner of an Intel chip that implements the original instruction set. As an aside, I upset many when working on OpenDoc for Apple and saying the same thing there.

>The atom/property mechanism allows clients to allocate memory in the server that can never be freed. Some way to free memory needs to be added.

>The bit encodings should be part of a separate language binding, not part of the functional description.

>X suffers from the same problems as the original Mac API. Scheifler et. al. didn't really do any system level design and modelling. I know this because I discussed it with Scheifler at an ANSI meeting in Tulsa, the only place that I have travelled to on business that had no redeeming qualities. He said "I don't believe in models because they predispose the implementation."

>Had he done some real design work and looked at what others were doing he might have realized that at its core, X was a distributed database system in which operations on some of the databases have visual side-effects. I forget the exact number, but X includes around 20 different databases: atoms, properties, contexts, selections, keymaps, etc. each with their own set of API calls. As a result, the X API is wide and shallow like the Mac, and full of interesting race conditions to boot. The whole thing could have been done with less than a dozen API calls.

[...]

Extremely rarely? I use it all the time. Just yesterday I wanted to develop some code on my (faster) desktop, while at a coffee shop nearby. I could have set up something like TRAMP I suppose, but just running emacs on my desktop and displaying it on my laptop was much easier.

You are rare :-)

gaslightning...

No, it's called reality.

X is going the way of the dodo despite being the former dominant GUI framework on what was at a certain point the dominant workstation OS.

That's how good and used (and valued!) this core functionality is.

https://xkcd.com/1172/

Your laptop's buggy drivers don't really change that several major GUI projects are moving towards Wayland first, X11 second. The result will be that all the "oops we didn't test this on Wayland" bugs that Wayland users have been facing the past few years will become "oops we didn't test this on X11" bugs.

Software being deprecated doesn't mean it just stops working. You can use the programs and the versions that you've installed right now and continue to use them for decades to come, but if you upgrade to newer versions you may start losing out on new features or run into bugs if you stick to X.org.

Several moving GUI projects are moving towards Waylands first. There's no such thing as wayland because the standard reference implementation does not come close to feature parity with X11. So basic features like, say, mouse/keyboard sharing, have to be implemented in non-standards external libraries (ie, libei). Some Waylands will use the libraries, some will not. It leads to massive incompatibility in features between ostensibly "Wayland" based DEs depending on which wayland is used. In practice there is no "Wayland", there are only feature incompatible Waylands almost as different from each other as they are different from X11.

So... these mentioned software projects are not all targeting the same thing. If anything X11 as the full featured reference implemenation everyone uses still gets more attention that any one of the waylands.

If you wrote this comment in 2020 you might've had a point, but the Wayland world has converged a whole lot in the past few years.

I gave a concrete example in my post of how waylands remain fragmented in 2024. Try to share mouse/keyboard between computers using sway. They have a strong position against libei for reasons but also fail to implement the functionality natively in sway as they feel it's outside the role a wayland should play.

Yes, you gave one example. I get it sucks that your pet use case isn't as well supported yet as you want but the situation is really pretty good. Unless you're specifically working on software for keyboard/mouse sharing, the libei thing isn't gonna be an issue.

2. Try to spawn an application at an exact x-y position on your particular wayland desktop.

Wayland is like fusion, it'll be ready in 20 years!

Really? So why am I using it right now without issues?

Nice! Where did you get your 4k monitors from?

Your comment doesn't make any sense

I am unsure about what you are trying to say, but I am using a 4k monitor and it works very well.

nvidia gpu?

And yet, every time I try to use Wayland, it is covered in bugs. Two recent ones I've noted: 1. alt-letter always selects the first menu in some applications, and 2. keyboard switching gets stuck so I have to use the mouse to fix it (including to be able to enter my password).

There's a reason people still prefer X11 and it has nothing to do with ideology or theory.

I'm in that boat. I don't care what the underlying tech is, but it sounds like for now, X is superior.

I do expect that to change. Someday...

> XFCE released in 2014 has significantly less bugs than XFCE today

The Thunar of today's auto-sized column behaviour irks me, I always end up with a horizontal scrollbar even though the content doesn't actually extend beyond the view. Can't think of anything else buggy. I think I first used XFCE in 2018, but it must have been spectacular in 2014.

> XFCE/MATE/Mint/etc need to band together and fork/mantain Gtk3

I'm curious if you have any reason to think that the people working on these projects have any interest in forking Gtk? They are using it (as is?), presumably they aren't that unhappy about it.

> the multiple bugs introduced by progressive removal of Gtk features

It really annoys me when software updates break my workflow, but it's easy to see how "add new shiny thing" (= progress) often wins out over "tread carefully" (= stagnation). The way you are referring to such changes as bugs is misleading though.

>The way you are referring to such changes as bugs is misleading though.

The deprecation and removal of keyboard inputs literally results in a bug that generates an error message, https://gitlab.gnome.org/GNOME/gtk/-/issues/5872

This is a microcosm for the Gtk3/4 pivot to mouse only as a whole: they don't care about the bugs caused for people who use keyboards. And DE's like XFCE/MATE/etc are unable to fix these bugs because they're Gtk bugs.

I don't see how that issue demonstrates what you are claiming. The error message is confusing, yes. Calling it a clear-cut bug is a stretch. The way you are referring to "bugs" is still misleading.

> This is a microcosm for the Gtk3/4 as a whole.

Is it? Where is the war on keyboards? Where is the resistance to working patches? Where is the ignored justification for your preferred behaviour?

>Is it? Where is the war on keyboards? Where is the resistance to working patches? Where is the ignored justification for your preferred behaviour?

On #gtk straight out of the typing fingers of the devs. In the form of the non-merged fixes in Arch for Gtk3. And in the bug tracker but you can't see all the closed and deleted bugs. As for "preferred" there's no preferences allowed by modern Gtk anymore. The gsettings for setting preferences were removed which lead to the bug.

Thunar is an optional component of XFCE.

There are various alternatives to Thunar. For instance I am using Xfe, which was much better than Thunar some years ago and I doubt that Thunar has been improved meanwhile.

Thunar has always been much buggier than other components of XFCE. About 6-7 years ago Thunar had a horrible bug. Sometimes when deleting a directory, it deleted the parent directory of the selected directory, instead of the selected one. This could easily lead to great data loss.

Except for Thunar, I have never encountered any serious bug in XFCE.

> Thunar ... must have been spectacular in 2014.

I don't think it was drastically different, but at least it supported alternating row colors ;)

I wonder if it might be time for a new “boring” UI framework.

GTK often gets selected over Qt because it’s so much easier build high quality idiomatic language bindings for, has a good selection of widgets out of the box, and doesn’t rock the boat following a plain old imperative model like has been used for ages.

With that in mind, there’s probably room for a new imperative UI framework that’s designed to be easy to bind to and is highly “batteries included”. It wouldn’t aim to be revolutionizing anything, but would let you build things with minimal fuss or churn on your terms (with allowance for well-defined “happy paths”, of course).

I was gonna say "How about EFL? It's C after all", but in my concept Enlightenment and XFCE have similar philosophies - one could dream about a fusion between those two..

I've been more and more impressed with XFCE, purely on a usability, get out of my way, support my workflow basis.

It's taken the place for LXQt/LXDE for me. The one notable negative is that I've had a lot of trouble getting bluetooth earphones to work properly.

I'm wondering if that would that be an issue with blueman tools and not XFCE, per se?

https://github.com/blueman-project/blueman

It is likely, but the same set of utilities work on Linux Mint flawlessly.

I've tried a fair bit of troubleshooting with no luck and eventually given up on getting it running on XFCE.

The versions are the same? Maybe its time for a bug report to blueman or your distro.

I mean Linux Mint is a distro while XFCE is a desktop environment... I'm sure if you installed XFCE on Mint your bluetooth earbuds would work just fine, and that bluetooth would be broken on your current distro regardless of what desktop environment you used.

Yes, and I will consider the Linux Mint XFCE edition at the next fresh install opportunity.

I hope LXQt gets cleaned up, because I think Qt is better then Gtk and would like a lightweight WM. But, last I tried it (six months ago? A year ago?), all sorts of basic things were broken, like multi-monitor support. I had "upgraded" from an old LXDE version, and the result was so unusable that I had to switch over to XFCE. XFCE is much better than I'd remembered it being though, so I will probably stick with it. Been very happy with XFCE.

Going from LXDE to LXQt was such a disappointment to me. LXDE was really good and polished (in my opinion, for the audience it targeted).

I like XFCE a lot because it is well thought out and highly customisable.

I use KDE these days largely because it was easier to get a tiling extension working. I also use a lot of KDE apps so I get the slightly better integrated too.

The thing that concerns me right now is the availability of clients supporting remote desktops of Wayland. As far as I've found, 'compatability with Wayland' means turning off Wayland.

Teamviewer seems to work, but it's pretty unstable. The APIs are all there now, but of the limited number of Linux compatible remote desktop applications, even fewer seem to be interested in adding Wayland support.

Rustdesk has Wayland support, but that project has all kinds of weird code smells. Hopefully other projects will take inspiration and implement Wayland support as well, though.

I'm not familiar with the term, "weird code smells". Do you mean that the code looks shoddy?

I'm more surprised that the versioning hell that plagues Wayland isn't mentioned usually anywhere: while in theory protocols are supposed to be backwards compatible, in practice this means that writing a new version starts with copy-pasting the previous version, and extending it - but there is no fallback mechanism in case a client doesn't support the latest and greatest.

What really bit me with wlroots (which seems to be the choice of XFCE also) is the input-method protocol: wlroots has v2 implemented, but Qt has v1, v3 and v4 implemented, which makes me laugh to this day - so Qt simply doesn't work wlroots, when it comes to this protocol (to add insult to injury, v4 specification seems to exists in a dead feature branch only that hasn't been touched since years, in the wayland protocols repo).

Oh well...

Reply on news.ycombinator.com