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).
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.
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.
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.
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.
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.
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, ...)
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.
> 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:
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.
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.)"
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":
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.
"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! ;)
>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 allocat...
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.
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.
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.
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.
> 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.
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.
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.
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 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.
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.
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 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).
Neither systemd nor wayland are actually junk just because they are "new". Wayland is the same people continuing their work, but no longer on Xorg but on Wayland and related technologies instead.
But in the long run XFCE depends on Gtk which has signaled it will drop X11 support in Gtk5. And already in Gtk4 X11 is being made a second class citizen and they're hard coding for the various Waylands. Adding support for a particular wayland just encourages them.
At some point these old style DE depending on Gtk are going to have to fork it.
It's OK, it's Linux, things will always be forked to keep some users happy which is how Mate exists. Other projects will come with the aim to keep X11 alive for that niche who wants it.
Some distros continue to avoid or navigate around systemd (Devuan or a carefully installed Debian in the former case, MX in the latter) so it seems unlikely that there will be a similar Wayland takeover. I'll dabble with Wayland if the mood or a specific need suits me.
I am guessing that people complaining about Wayland do not care that technically it is just a specification that is "much better" or "more lightweight" than X11. What they do care about is that Wayland is being forced on them before it works on the same hardware where X11 works correctly and X11 is being removed which leaves them without working system.
If you go by what is lightweight than just drop all GUI since text console is the lightest of all user interfaces.
This was just in response to Wayland being 'bloat' which is factually wrong.
Also, X11 did not disappear over night so I don't get all that complaining. I'd wager X11 will remain a viable display server for several years. The only distro discussing removal of X11 seems to be Fedora at the moment, and they where always on the bleeding edge so no surprises there.
Much as I don't like the track Wayland appears to want to take and plan to stay on X11 for a while, X11 is horrible and bloated and junk. It just appears to work because developers of apps/toolkits have had no choice but to pour in unnecessary amounts of effort to get things to function.
Here's a fun example I had to work around: move your mouse outside a window, then back in, then scroll the mouse wheel one tick, and repeat. On apps handling fractional scrolling you'll never end up scrolling anywhere - this is because.. X11/Xinput gives the cumulative distance scrolled anywhere, and so apps use the first scroll event on mouse entry to "calibrate" the current position to then be able to calculate a proper delta.
81 comments
[ 3.5 ms ] story [ 114 ms ] threadThings 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).
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.
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 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.
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.
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.
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.
I’ve been hearing for years that Wayland is the future and X is deprecated but it doesn’t match my reality.
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.
Design-wise it is exactly right: A generic remote buffer management protocol.
When we've had toolkits for 30+ years and this hasn't happened, that's called a hint.
Nobody* cares.
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
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 allocat...
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/
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.
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.
There's a reason people still prefer X11 and it has nothing to do with ideology or theory.
I do expect that to change. Someday...
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 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.
> 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?
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.
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.
I don't think it was drastically different, but at least it supported alternating row colors ;)
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).
https://github.com/blueman-project/blueman
I've tried a fair bit of troubleshooting with no luck and eventually given up on getting it running on XFCE.
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.
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.
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...
At some point these old style DE depending on Gtk are going to have to fork it.
Nothing wrong with wanting to stick to X11, but if you are doing so because you want to avoid bloat, you are probably confused.
Also, X11 did not disappear over night so I don't get all that complaining. I'd wager X11 will remain a viable display server for several years. The only distro discussing removal of X11 seems to be Fedora at the moment, and they where always on the bleeding edge so no surprises there.
Stuff you don't like is bloated/legacy.
Here's a fun example I had to work around: move your mouse outside a window, then back in, then scroll the mouse wheel one tick, and repeat. On apps handling fractional scrolling you'll never end up scrolling anywhere - this is because.. X11/Xinput gives the cumulative distance scrolled anywhere, and so apps use the first scroll event on mouse entry to "calibrate" the current position to then be able to calculate a proper delta.