Linux, amazingly, has some of my favourite UIs right now. It used to be different. I used to hate the Linux UIs, and preferred Windows 7 or OS X. Now that Win 10 is dominant, and I can't justify a new MBP (though I still love my 2015 MBP), I've jumped to Linux Mint. The UI is clean, easy to use, uncluttered, has obvious affordances. It isn't quite as polished as Win 7 was, but it's better than this new crap.
The main issue with UI on Linux is that toolkits have a higher churn than in Windows - this is because there isn't really "Gtk", "Qt" or whatever, but "Gtk2", "Gtk3", "Gtk4", "Qt4", "Qt5", etc (and i'm sure that if i mentioned "Qt3" i'm sure someone would point out that nobody uses that anymore :-P).
Writing something in Win32 will ensure it will run in 10 years from now and chances are it'll also run 20 years from now. As a user you have a very high chance of finding applications that work regardless of when they were made. As a developer you can focus on your tasks without wasting time to "upgrade" to the latest fad (Microsoft does release new toolkits, but the old stuff keep working and Win32 is the stablest of them all). And your knowledge will still be perfectly valid, no need to waste time learning how to do the exact same stuff in a different way.
Writing something in Gtk3 (the current stable one) will ensure... well, once Gtk4 is stable, Gtk3 will be deprecated and the one to avoid. Qt can't even remain stable in the long term if they wanted (though they do not seem to want to - after all Qt is middleware targeted to application developers, not a platform component regardless if KDE pretends that it is) because of C++. As a user you are limited in the applications you can find and have to keep around all sorts of different toolkits - which wouldn't be that great of an issue (hard disk space is cheap) if those toolkits were still supported and compiled. Except the only distribution i'm aware that provides -say- Gtk1 is Slackware and Qt4 is already on its way out by most distributions. Gtk2 will soon follow (and perhaps some distributions will already have it dropped). As a developer you have to chase after the brokenness that Gtk and Qt developers introduce (though TBF Qt seems a bit better here, probably because they are getting paid by selling Qt licenses and they cant annoy the developers using Qt too much) and waste time "keeping up" just so that your existing application will keep working.
Above X there aren't any stable UI APIs (unless you count Athena but that hasn't received any updates since the 80s - even the updates 3rd parties made during the 90s to improve its look a bit never became part of the "official" distribution). And people want to get rid of X's stability too with Wayland.
Yeah, it is kinda amusing that one of the stablest ABIs for GUI applications on Linux is the Windows one :-P.
Sadly the Wine GUI controls, while they work, always felt off to me and have multiple minor issues. But at least they work. I think a big reason is that despite libwine being usable as a general purpose toolkit for (ELF) Linux application, it never saw much use as that so these issues were never paid much attention.
Vulkan would make things more complicated and wont really fix anything (if anything it'll make things worse because that added complication will make it harder to fix things and most likely will break compatibility with anything not supporting Vulkan - e.g. older and/or weaker devices and other OSes like macOS) since it isn't really rendering that is the issue but behavior (there are also some drawing issues but those are at the GDI level and you do not want to break GDI).
> Qt can't even remain stable in the long term if they wanted (though they do not seem to want to - after all Qt is middleware targeted to application developers, not a platform component regardless if KDE pretends that it is) because of C++
> So, what did we learn? It did not take that much effort to port tutorial 14 from Qt 1.0 to Qt 5.11. It probably took me longer to write this blog post.
Qt 1 was released in 1995, Qt 5 has been released in 2012 (and did not break ABI / API since then).
I think it's not unreasonable to spend a few days every 7 years to update your app to the new Qt major version... especially when the hardware evolves and you have to update to follow that anyways (touch screens, hidpi, permission requesting).
This shows exactly what i mean (and i did note that Qt is at least better than Gtk here).
An application written in 1995 against the Qt1 API will not work on Qt5 because both the API and the ABI has been broken. A user who wants to run such an application (not necessarily released in 1995, Qt1 was in use into the very early 2000s, even though Qt2 was already out) is not able to do so. A developer who wants to modify such an application has to become familiar with both Qt1 and Qt5.
In contrast an application written in 1995 that uses Win32 will run out of the box in Windows 10 without any changes. A user can run such an application perfectly fine (and personally i have several applications like that that i'm using) and a developer who wants to work with the code will be able to focus on the application itself (since chances are he already learned Win32 at the past if he worked in any other Win32 program). As an example, some time ago Microsoft released the source code of File Manager which dates back to ~1990 - i was able to navigate that code easily and added the ability to filter a window's contents using multiple wildcards.
(note that in both cases i am assuming the applications do not do anything stupid that happened to work at the time but doesn't work nowadays)
An application may not even be maintained any more. Or it may be maintained but the user(s) might dislike the changes (e.g. i like Paint Shop Pro 7, released in 2000, but i never liked the UI overhaul that PSP8 got and nowadays after Corel bought the software they have severely... well... gimped it :-P - similarly i do not like the changes introduced in Blender 2.8 so i stick with 2.79 and i know a very talented artist who still uses Photoshop 5 - not CS5, plain 5).
Those few days are also very optimistic and really depend a lot on the software in question. AFAIK Lazarus, for example, took ages to update form Qt4 to Qt5 (same story, but much worse due to all the breakage Gtk introduced, with Gtk3 which still isn't really usable). And as i wrote above, most of the time, they are a waste of time. Adding support for touch screens and hidpi (not sure what you have in mind with permission requesting, so i ignore that) doesn't require breaking your API nor your ABI.
EDIT: BTW, it isn't impossible to have Windows-like backwards compatibility on Linux, here is a screenshot[0] from a toolkit i used to work on at the past showing the same binary working in both 32bit Red Hat from 1997 and 64bit Debian from 2017 - essentially 20 years of backwards binary compatibility (the colors are off because i didn't bother to implement indexed color support). It is just that the toolkit maintainers do not care, but it is perfectly possible to do that if you care.
So to some extent this just reflects my prior ‘commitment’ (it doesn't feel like one at this point, because it follows from many, many preferences about what I like to use) to a Linux/free software life, but I just... don't use unmaintained software and the idea of doing so kinda disturbs me.
Maybe art stuff is kinda special here?
On the ‘disk space is cheap’ side of things, packaging strategies like those of Nix and Guix can go a long way toward solving the human-level problem here; I can install packages that have long been removed from NixOS on current NixOS systems just by pointing to the old copies of the package definitions. That means that if I want a Qt3 application and Qt3 has been removed, I can install it just by pointing my package manager to a copy of the package definitions from way back when that application and its toolkit dependencies were still included. App containerization stuff like Flatpak also seems like another good way to mitigate this issue without committing distros to eternal maintenance of each major version of each GUI toolkit.
What do you think? Is the future for backwards compatibility of end-user applications on Linux brighter than its past despite the persistence of the API-and ABI-level churn problem?
Honestly i do not think that bundling everything to a container is really a solution - more of a hacky workaround for a problem that shouldn't exist. It does solve the "old program doesn't run" issue, but doesn't solve anything else.
For example your old program doesn't receive new features through the shared libraries it uses - a simple example i gave elsewhere was old Windows applications receiving the ability to input emoji in recent updates to Windows 10 even though emoji wasn't a thing (outside Japan at least) when most of them were written.
It also doesn't solve the issue at all from the developer's side. A developer who comes later to an application still has to find old development libraries and make sure they work on his modern system and/or update all the code (perhaps without even knowing how the original program worked). And developers who maintain an application still have to waste time and resources in keeping up (see Xfce as an example).
FLOSS doesn't really solve this - if anything your average (big) distro repository is full of programs using several different "versions" of toolkits and other APIs. At "best" (from the distro maintainers perspective, not necessarily form the users' perspective) the distro drops applications. It does help with having the potential of fixing things, but that is all that there is to it - the actual effort (and thus time) needed largely depends on how much things have broken.
As a personal example, a few years ago i decided to try one of the very first web browsers made, MidasWWW. I downloaded the code and tried to compile it. But of course it didn't compile out of the box, having the source wasn't much of a help here. Now, i am a bit persistent, so i decided to fix it and after a while i ended up with this:
This is an example of what i mentioned in my comments here: the browser was written in Motif and Motif has generally been API and ABI stable over the years (it'd be nice if its theming support was improved - without breaking backwards compatibility of course - as i think that would make it more popular among developers) so i didn't had to do almost anything. But at the same time MidasWWW was written in some old Unix workstation that had a modified version of Motif which was incompatible with the mainline Motif - the result is the panel at the top being inside the content area instead of on top of it. I didn't knew about that, i actually realized after i made that shot :-P and i couldn't fix it because i am not really familiar with Motif and especially not familiar with the modified version that the workstation used - but i'd need to at least know something from both to figure out what changes i need to make.
And see, that was just a little breaking incompatibility between versions. Having access to the source and Motif being backwards compatible helped to get it compiling, but didn't help with having it work properly because there was a breaking change somewhere in between. And since the original developers aren't around, it was up to me alone to figure things out - to do it properly, i'd have to spend considerable time. Time that i didn't want to bother spending, so i didn't :-P
> In contrast an application written in 1995 that uses Win32 will run out of the box in Windows 10 without any changes. A user can run such an application perfectly fine (and personally i have several applications like that that i'm using) and a developer who wants to work with the code will be able to focus on the application itself (since chances are he already learned Win32 at the past if he worked in any other Win32 program).
I'm sorry but your definition of "works fine" is likely very uncommon. Old applications won't even have @2x pixmaps which leads to everything being a blurry upscaled mess.
If it were that easy we wouldn't be getting regular requests to port MFC applications to Qt at the company I work at ;)
If it's not a high-DPI screen, then it will look the same.
If it's a high-DPI screen, then it will be upscaled to look the same as it did on the old low-res screen, so it's not any worse than it has been before. It's only a "blurry mess" when contrasted to an app with high-res text and graphics, making use of that new screen.
So it won't magically become a high-DPI app, of course, but it will still run perfectly fine, if your baseline is "runs the same as it always did". High-DPI support is a new feature, so it stands to reason that it requires app to be updated.
As a sidenote, it does look worse with bilinear upscaling, sadly. This is why both Windows 10 in recent versions as well as new GPU driver offer the option for nearest-neighbor integer scaling where possible.
For example my laptop has a 1080p monitor - not exactly hidpi, but the monitor is small enough for Windows to suggest a 150% scale. But this makes anything that doesn't support scaling look blurry (and also break several games, but that is another matter) so i prefer to use 100% even though it makes things a bit harder to see.
I do not know why you are getting requests to do that but keep in mind that people who are fine with your MFC applications are not going to contact you - what you are seeing is only people who have issues, not all people (EDIT: also i'm certain you can make MFC applications work in hidpi monitors, you do not need to port them to Qt for that).
Old applications will certainly not support "@2x pixmaps" (though many do support hidpi monitors if you use the "Override high DPI scaling behavior" to let the application do it - however the majority do not, which is why this isn't the default) but despite being blurred they'll still work (and that is assuming you are using a hidpi monitor, in practice nowadays hidpi monitors are still a very tiny minority so chances are you wont even notice it). Though FWIW i personally do not use hidpi monitors and one of the reasons is that (the other is that i play games a lot and i do not feel the slightly higher crispiness is worth the massively reduced performance).
However breaking the ABI wont work at all, blurry or not.
(also note that Windows 10 will not use bilinear filtering for integer scaling so in -e.g.- 4K monitors running at 200% scaling you shouldn't get blurriness)
To be fair, that churn also means the system you get when you install Fedora Workstation or Ubuntu is almost entirely Gtk3 or something built with Gtk3 in mind. You don't get this weird combobulation of utilities built with different UI toolkits with different kinds of scrollbars (and different levels of support for high dpi, touch screens and scroll events) because the old stuff "works" and we lost the event viewer source code ten years ago.
I guess the other chunk of this is the development model seems to prevent that sort of fragmentation within these larger products. The broader app ecosystem is a separate story, and I realize that's most of what you're bothered by, but having that core system be consistently modern is a big thing on its own. And to get there it seems like you kind of have to sacrifice one for the other.
But that isn't very helpful nor really that useful. Computers aren't single purpose appliances (even if some people treat them like that but even in that case, they tend to have different opinion about what sort of appliances they are). Ubuntu (and i guess Fedora) out of the box isn't that useful and the moment you install anything that wasn't made with, say, Gtk3 in mind things start to crack. Actually i think in Ubuntu you do not even need to install anything, just open the web browser and things start to not mesh that nicely.
And IMO if anything, the reason you get all those different behaviors is exactly because things break. If Gtk3 was backwards compatible with Gtk2 (in a fantasy world where the Gtk developers did learn from the mistakes of Gtk1 to Gtk2 breakage and designed their Gtk2 APIs to avoid it in the future) then all Gtk2 applications would gain, if not all, then at least some of the new functionality in Gtk3. Programs that were abandoned would still get some of the new stuff while programs that are under development would be able to keep using whatever they are using and upgrade in their own pace only the minor differences that were needed for the new functionality.
Writing something in Gtk3 can break even in minor releases, apparently. I remember there was an update that broke a lot of themes, and apps that did custom theming for their own purposes.
I recently installed Fedora 32 and I am extremely happy with it. I was not a big fan of Gnome 3 for a long time, but now it seems that the project is mature enough. All the Gnome apps look gorgeous and very clean. The whole interface is responsive and quick.
I tried Windows 10 with WSL 2 for a few months, but the experience is far from being good. WSL is slow and the new Windows terminal needs a lot of polish.
Windows 10 it self is a subpar experience. The UI in general is a mess, all from explorer to control panel and settings. You often find windows and text that look awful on high dpi displays. And I'm not talking about third party apps, I'm talking about Windows itself and some MS apps like Skype. Windows also is not as responsive as I would like. Hitting the windows key to quickly open an app, which is the most repeated action by me, is sluggish.
The only reason I was using Windows was because my Thinkpad had issues with the microphone and speakers on Linux, but now that Fedora 32 is out with a new kernel, hardware works like a charm, so good byE Windows!
There are UIs on Linux (& *BSDs) that you cant get anywhere else - tiling window managers. I'd argue that a tiling WM is the greatest UI for a poweruser/programmer/devops. There is a learing curve, but once you memorize a few hotkeys you wont be able to go back to a floating windows mess.
Why a tiling wm instead of tmux? The only thing I want to tile is my terminal anyways -- tiled GUIs generally don't work well and alt-tabbing through them is a better UX.
You probably answered your own question there. They might want to tile things other than a terminal.
I used to use Ion3 on a tiny Fujitsu Lifebook P1510D to divide the screen into quadrants containing things like a terminal (mostly used for IRC), Pidgin, a browser, and whatever videos I might be watching.
Quadrants with the same stuff are easy to do in Windows (with Win+arrows). The tricky part is in various autolayouts &c. But that is also where usefulness diminishes for non-terminal stuff. GUI apps usually expect stacking.
As soon as you are tiling mouse-driven GUIs your having to do more work to traverse your screen with the mouse vs a stacking wm where your stacked GUIs can be flipped through with keyboard shortcuts.
I guess it makes sense if you have a bunch of apps you're predominantly reading from instead of interacting with but in my experience those are predominantly terminal UIs anyways.
Why not? I use a tiling wm and I love it. I'm able to make my desktop act exactly the way I want it to act. I don't appreciate my windows being rambunctious.
If I'm on a machine without a tiling wm I generally using everything maximized and alt-tab like you say. But that's still usually an extra click after opening an application.
I also love tmux, but I have a coworker that doesn't see the point.
So, having options is nice. I want to be able to work the way I want. I also want you and my coworker to be able to work your way.
I guess it depends on your setup but being able to attach to an existing tmux session from another machine is something a tiling wm won't be able to offer.
> Linux, amazingly, has some of my favourite UIs right now.
Of which as a desktop app developer it is harder and more complicated to test.
I have to test if my GUI app works properly before someone on whatever Linux distro complains that it doesn't work on either of their GNOME, KDE, Xfce, Cinnamon, LXDE or Mate setup or worse yet, if the problem is found deeper in the distro stack which could be the user's incompatible configuration or if it is the distro itself.
Windows and macOS have a default desktop environment and windowing manager that I can test against which is very predictable and stable unlike the complexity of the Linux desktop stack and its distros.
If you have a problem that manifests itself under one DE but not under another, you are doing something very wrong - unless you are doing something very deeply integrated with specific DE.
Seriously, for a normal, user-facing app, all you should care about is at the level of the framework you used.
> If you have a problem that manifests itself under one DE but not under another, you are doing something very wrong - unless you are doing something very deeply integrated with specific DE.
I see. So you're saying it's the "app developers" fault when a Linux user changes any system component of the Linux desktop stack i.e. display manager or desktop environment and the app fails to start or crashes because it only runs on GNOME, KDE or its X11 or Wayland-specific. It is actually an entire distro problem. When someone decides to make the switch to full blown Wayland or some other configuration, all bets and guarantees are off on stability and they start finding alternatives for other apps because the apps they tried don't work on their setup. [0] There's a reason why they say "UNSUPPORTED".
For example, Firefox couldn't start on SwayWM and the number of issues and combinations of people not running it on their distro setup was mounting. [1]. Such issues are easy to test on Windows and macOS but very difficult in Linux distros, resorting to trail through the whole desktop stack to find the issue as demonstrated in this ticket [2]. Such issues like this still exist in many Linux apps not just Firefox.
> Seriously, for a normal, user-facing app, all you should care about is at the level of the framework you used.
Like I said, no guarantees are made if the user ends up changing system components or old frameworks and the app crashes on their setup when it is specifically made to work on a default install of XYZ distro. The point is that the freedom to mix and match subsystem components makes it complicated to test your app or trace a bug which could at worst be a regression in one part of a Linux subsystem component, which is why some see it as a blessing and a curse here.
I mean you're free to release an app and say it's only supported in GNOME or KDE on $distros. What the parent is getting at is that in most cases when developing with GTK or QT you have to make an effort to tie yourself to a specific DE. And as long as you don't do that the crashing is a bug in the DE/WM/User Error, not your app.
Basically if you don't try to be super fancy you make it other people's problem if your app crashes.
Imo, the key difference between these two worlds (which you hint at in your analysis of the ascription of fault at the very beginning) is that when most or all elements of an operating system's stack of essential software is fixed, that leaves the capacity (and responsibility) of deciding the nature and quality of users' experiences with a piece of software in the developer's hands alone. But when an operating system is flexible and its components are somewhat interchangeable with alternatives, or the target platform is actually a whole family of operating systems, developers can't and don't have such sole responsibility or capacity. Distro and package maintainers especially do crucial work in sharing that burden and making sure those end-user experiences are coherent and pleasant, and in general they do a great job of it.
When there are problems, I think it's equally useful to consider them as logistical and social problems among community members (developers, distro maintainers, package maintainers, and end users) in managing that shared control and responsibility. Some examples:
• End users who are used to navigating the alternative world of mostly-uniform platforms may not understand that not everything is up to the developer, which can misdirect their frustrations (and their bug reports).
• By the same token, advanced users and smalltime contributors form a crucial layer of these ecosystems wherever they are healthy, by not only running up against integration issues themselves so that they can be identified, but by figuring out how and where to report them and how to mediate information between the authors of applications and people who work to integrate them into their operating systems (distros). Developers who want wide support are faced with the task of seeking or building those relationships somehow (or just rolling the dice).
• Developers of new pieces of software may find themselves faced with a social bootstrapping problem: they need people using their software, or at least excited about it, in order to generate the interest in their software required to get someone working on integrating it with a particular distro.
• Users who change out major system components in a distro (like the init system or the display server) take on (or create a need for) a new role in doing so: they become integrators of the system just like that advanced layer of users I mentioned, or distro maintainers. A clearer understanding of that might ease a lot of frustration for users and developers about things ‘not working’. (This is reflected in Gentoo's self-description as a ‘meta-distribution’.)
I'd like to see more of this acknowledged explicitly, maybe by two official standards of support: original development target and explicitly co-supported. A lot of F/OSS projects sort of already do this by pointing to the program's inclusion in various distro repositories on their official pages, sometimes with a word of warning about especially experimental cases (i.e., packaged but not co-supported).
Supporting more distros will always require more work from developers, but such work doesn't always have to be intensive development work. It can just be a working relationship between a developer and a motivated user of some distro who the developer agrees is more or less competent to figure out the technical boundaries of integration problems and work with them in a reasonable way to solve them equitably. I know it _can_ happen because I see it play out all the time when it comes to packaging software for my favorite Linux distro¹, which because of the distro's weirdness can require some hints or even minor source code changes from application developers. When the motivations are communicated clearly, application developers are often willing to incorporate minor compatibility changes for the sake of some boutique distro's compatibility, with very little fuss.
Idk what really can be done to communicate this to users, or how to better manage the sort of clusters of related configurations that exist on meta-distros like Arch or Gentoo, but both seem in principle doable to me.
1. You compare dev version of linux compositor to stable versions of the other OSes
If the app fails to start or crashes when it runs under one WM or another, then following happens:
- app is using something/talking to something/assumes something in a way it is not supposed to -> bug in the app
- the WM or compositor doesn't take some message or poking in a way it is supposed to take -> bug in the WM or compositor.
The example you posted is sway, during the time it was in development. I stress again, it was in development, it was not supposed to be bug-free, and no distro shipped it. Applications do crash under dev version of macOS and Windows too; you just don't see that because the respective bug trackers are not public, and the respective dev builds of the os are not very public either. In Linux, you have access, but then you have to break something, with the implicit understanding that when that happens, you get to keep the broken pieces.
Nobody sane would consider that supporting development versions of any package on any OS is something you are supposed to do.
Related: Switching to Wayland is mostly non-issue. If your app previously used X11, it will continue run using X11 under Xwayland. If anything, the Wayland developers made it too seamless. Unlike Apple, which made XDarwin eye-sore, so the users would be aware and demand updates.
2. You compare different layers in the stacks
In Windows, you have to use MS provided UI toolkit (whether Win32 or UWP, doesn't matter). In macOS, you have to use Cocoa. Neither of these vendors would allow you to talk directly to their respective compositor, no way around it.
In Linux, just because you can - everything is transparent - doesn't mean you should. If you want to play at the same level as you do on Windows/macOS, use it at the same level: use a toolkit, that will abstract the same things for you, as the vendor supplied frameworks on the other OSes do. Gtk, Qt, Electron, doesn't matter, they do the heavy lifting for you. Do not talk to compositor directly - then you do not even have to care, whether it is X11 or Wayland, the toolkit will arrange it for you.
By inserting yourself on the different level in the stack, you assume on yourself solving all the problems that are being solved there. If you want add your workload, you are welcome, but then be honest at least to yourself and admit, that it is easily avoidable self-inflicted pain.
---
I understand, that there is no system-wide SDK with a given ABI, and that can be frustrating sometimes. I understand, that ABIs that distributions provide are semi-stable. There are solutions for that:
1. Pick a distribution you will support. Blackmagic supports RHEL/CentOS, nothing else. GoG supports Ubuntu. If it runs anywhere else, cool, but you are on your own. Similarly, you can even support several of them, but when someone decides to do X, where X breaks other apps, he is on his own. When the user is competent of breaking something on his own, surely he is competent of fixing it too. You don't support users who hex-edited their system libraries in Windows either.
2. Use flatpak. You choose the runtime, you choose when your app switches to newer runtime. Most runtimes have defined support periods and document, what can change during that support period (i.e. freedesktop one allows for security updates and updated OpenGL drivers). This has the advantage, that nobody is going to try using their self-compiled libraries as a replacement for the runtime-supplied ones.
> Pick a distribution you will support. Blackmagic supports RHEL/CentOS, nothing else. GoG supports Ubuntu. If it runs anywhere else, cool, but you are on your own.\
I'll take "reasons it still isn't the year of the Linux Desktop" for $1000 Alex.
Well, for Blackmagic products you usually need to attach hardware that is well beyond most home budgets. What distributions they do or do not support is immaterial for the linux desktop, but they were provided as an example of their approach.
For GoG, they run very well everywhere; they just explicitly support Ubuntu.
The point was, that WMs are not even a factor in the support matrix. They either manage windows or don't, but your app doesn't care, it just paints its window. How the user places it on the screen is his problem.
I'm a long-time Mac user who is planning a gradual transition to Linux and FreeBSD. However, I have used various desktop environments over the years in the context of installing Linux and FreeBSD on older hardware and in development VMs, and so I'm familiar with the Linux desktop ecosystem even if Macs are my daily drivers.
One of the things I appreciate about the Unix ecosystem is the wide amount of choice of window managers and the broad support for themability. This means that users are less affected in Linux by current design fads. For example, the reason we have MATE and Cinnamon is because some people didn't like the changes made in GNOME 3. Now there are at least four well-supported GTK-based desktops: GNOME, XFCE, MATE, and Cinnamon.
If Apple or Microsoft makes a UI change and I don't like it, I generally have to grin and bear it unless I switch platforms. If KDE, GNOME, Windowmaker, or another desktop environment/window manager makes a UI change that I don't like, then there are a lot of options I have to change things to my liking. That's the power of the Unix desktop ecosystem.
I too am a big fan of the UI that comes with Cinnamon DE(the one that comes with Linux mint). I sometimes install other UIs just to see how they've evolved over the years but keep on coming back to Cinnamon for daily use.
I’m using Gnome in dark mode and I agree for the most part, although I find LibreOffice looks absolutely dreadful in recent versions. I’m not sure whether it’s a regression or something wrong with my setup.
