From Gtk+libadwaita to Qt+KDE Frameworks: Easyeffects rewrite
Posted by ExaHamza@reddit | linux | View on Reddit | 227 comments
Easyffects is a Limiter, compressor, convolver, equalizer and auto volume and many other plugins for PipeWire applications.
santtiavin@reddit
I'm happy seeing how people are starting to grow out of GTK, Adwaita and the whole GNOME attitude towards server side decorations, theming, wayland standards, etc. This people hold the Linux desktop back.
AntLive9218@reddit
It's an improvement, but unfortunately Qt also comes with its own significant problems, mostly in the form of carrying ancient bad design choices.
Typical significant examples which are quite relevant for KDE:
UTF-16 is used for text, even though the Unicode wars are over, and even Windows offers UTF-8 support which is what's used elsewhere. This results in a ton of unnecessary UTF-8 <-> UTF-16 conversions, and bloats text memory usage to typically close to double.
Serialization defaults to Big-Endian (BE), even though Little-Endian (LE) "won" a long time ago. This results in communication involving LE -> BE -> LE conversions, which is especially silly when it's happening all on the same host which just can't have an endianness mismatch to begin with (at least before Intel introduces it with another odd decision).
Combine just these two, and this results in KIO often spending most of its time on completely unnecessary work.
Getting a file info through a KIO plugin mostly involve:
Getting LE + UTF-8 info from the kernel
Storing result as LE + UTF-16
Serializing info as BE + UTF-8
Deserializing info as LE + UTF-16
If the kernel needs to be involved again, then convert to LE + UTF-8
And that's just the return path.
Still, I embrace progress, so Qt + KDE is the way, and I really like the KDE approach of focusing on functionality first, but damn it's carrying some heavy baggage with Qt.
Vivid_Valkyrie@reddit
Except for as long as these UI toolkits refuse to play nice with each other on desktops built on opposing UI toolkits, NEITHER is "the way" unless you want to pigeon hole all Linux desktops into using a single UI toolkit, styling and effectively desktop until the end of time and turn it into the next Microsoft Windows.
Linux NEEDS diversity in things like UI toolkits but these UI toolkits also need to play nicer with each other for things to keep going
Kevin_Kofler@reddit
Big Endian is the standard network encoding on the whole Internet.
Ontological_Gap@reddit
And most of my desktops apps bitbang raw packets down my network stack
AntLive9218@reddit
I was thinking of pointing out how unfortunately designed several decades old standards we have to follow aren't that relevant, but your response is better.
Unironically even programs directly dealing with the network wouldn't care too much about endianness aside from satisfying standards compliance with header contents which have reasonable (hardware) acceleration methods anyway. Would be interesting to see hundreds of Gb/s being pumped around if most programs would still have endian-conveting serdes.
stevecrox0914@reddit
I have looked after various Java and Python stacks. Once something gets popular enough they normally raise the need to support multiple languages.
With Java the entire effort is focussed on the inputs/outputs for the stack (e.g. rest calls), checking the correct charracter sets are handled and ASCII and UTF8 exist no where. Its all translated to UTF16 in Java and then just works.
The Python Devs put everything in UTF8 and you quickly end up in complete rewrite territory.
If you ever want you application to be truely international it needs to be UTF16
IgKh@reddit
Minor nit - Python, both 2 (during its later years at least) and 3, uses UCS-4 as the working encoding for Unicode strings. The big 2 -> 3 migration pain was not a change in encoding but changing the default string type from an arbitrary byte string (that applications just pretended was some sort of 8-bit text encoding) to the unicode string.
For the main point - you don't have to use UCS-2/4 or UTF-16/32 encoding to correctly work with international Unicode text. It can be somewhat more efficient for many operations because you could then treat strings as a continuous array of fixed-width codepoints, and index/slice the string in constant time. Though for UTF-16 that was only really true in the 90's/early 00's - because nowadays we have more than just the BMP, and upper/lower surrogates are a thing.
Rust natively operates on UTF-8 strings, so it can absolutely be done. But the (safe) API for that looks significantly different to your typical unicode-aware string type from Java/ICU/Qt/Python/MFC/Cocoa. Much so that any of those migrating is a not very realistic prospect.
AntLive9218@reddit
The end result is that operations on UTF-16 strings aren't constant time as once they were (expected to be), so it's the worst of both worlds with non-constant time and increased width.
The constant time upside didn't end up working out for UTF-32 either, because compute power keeps on increasing, while memory access is still a problem, so the more efficient memory (and therefore cache) usage of UTF-8 is often preferred.
IgKh@reddit
Oh, absolutely! The status quo is not optimal. I was trying to pinpoint more accurately why most of the major frameworks are based on UTF-16 or UCS-2 and why migrating to UTF-8 as the working encoding is probably not practical and may make the Python 3 migration look like smooth walk in the park.
(BTW dropping the constant time access charade isn't the only thing, there's also the fact that in UTF-8 transformations like changing case can change the byte length of the string, and CJK languages where UTF-8 ends up taking more space).
I occasionally fantasize about a Qt7 which is UTF-8 based, but then look at all the very complex, very old and very correct text rendering code and quickly drop the fantasy...
AntLive9218@reddit
Just because one language also carries legacy baggage, doesn't mean that everything else should be forced to share the same burden.
Java is quite free to use UTF-16 internally with or without Qt, that really doesn't change anything. Quite ironically it would also serialize to UTF-8 when using Qt, so it's capable of what's needed, and it would be free to stay bloated, true to the reputation it still has for a lot of people.
UTF-16 is not required to be international, and it's a dead end. Just consider that almost the entirety of the web is UTF-8 (and even the tiny remaining rest is mostly ASCII), with web technologies like JSON even requiring UTF-8. The vast majority of computers is also Linux based, and the kernel didn't even entertain the inferior Unicode options for syscall. Even Windows has syscalls taking UTF-8 parameters now with Microsoft conceding that it was actually the right way.
The quickest way to understand why was UTF-16 is just a bet on the wrong solution is to look into why UTF-32 exists, and why almost the whole world just agreed on UTF-8 after realizing how much was invested into the worst of both worlds.
sibelaikaswoof@reddit
Attitude towards Wayland standards, what about them? X11 is dead dude, it's now a legacy platform which barely supports modern hardware (no true support HiDPI displays, especially multiple, no VVR, no HDR, no 1:1 trackpad gesture support, the list goes on and on and on...). It's not even GNOME's pretentious philosophical decision to push Wayland, KDE has made Wayland the default session and put all its focus there too. COSMIC is Wayland only and other DEs are moving towards it as well, they just don't have the resources to keep up with the big guys.
santtiavin@reddit
Maybe you misunderstood my comment, I'm 100% on Wayland, just not on how GNOME devs slow things down for the rest of the DEs, a lot of standardization could have been done for the protocol but they either contribute in making it harder to implement, or they just block it because they don't like it. This force certain features being implemented first in KDE Plasma and then used by the rest of the programs.
InfiniteSheepherder1@reddit
Can you point to the issues that GNOME is alone in blocking, I have read through plenty of stuff on the wayland protocols and it is pretty rare for GNOME to be the single person disagreeing. The Windows positioning stuff people have been talking about recently while GNOME was also critical the first nack on that came from KDE IIRC.
LigPaten@reddit
Gnome has been the major blocker in window placement protocols.
Zettinator@reddit
You can argue whether they make the right decisions, but GNOME and FDO developers are trying quite hard to standardize and simplify things. The client side decoration (CSD) vs server side decoration (SSD) discussion is actually a pretty typical one. Early on in Wayland development, it was decided: CSD it is - it's more flexible and everyone else that matters (namely Windows and macOS) are doing it too. But then people asked for SSDs, people wrote specifications and now live is universally more complicated for everyone as both options exist and applications and compositors ideally need to support both.
IMO, kwin should have put down their feet and not have added support for SSDs. Instead we would have needed a standardized service/library to handle drawing the CSD (like libdecoration, but better).
Kevin_Kofler@reddit
KWin has actually put their feet down and refused to not add support for SSDs as GNOME people asked them to do, because there are strong technical reasons why SSDs are superior, and every other operating system in the world supports SSDs. Both Windows and macOS support SSDs and show SSDs by default, requiring the developer to set an extra flag to disable that, just like KWin.
Eccentric_Autarch@reddit
There are no strong technical reasons for why SSDs are superior, and neither Windows nor Mac use SSDs they are CSD... they are not drawn by the compositor. Can't even argue there is one true way of drawing windows either, for Windows you have various different tool kits with different looking title bars from Microsoft as they have transitioned.
Kevin_Kofler@reddit
There are. SSDs are faster (i.e., more responsive), remain responsive even if the application has crashed (and, e.g., on KWin, you can click the close button, and if after 10 seconds the application has not replied, KWin will bring up a dialog box offering to kill the application), look, feel, and behave consistently across all applications (and in particular always offer the same controls), and can be centrally themed.
They are not drawn by the application either, and that is what matters to the application. In what process they are actually drawn is an implementation detail that the application developer does not need to care about. (For the user, it may make a difference though, for the reasons described in the first paragraph.) What the application developer sees is that the window decorations are drawn by the operating system and are off limits to the application (unless the developer explicitly opts in to fully client-side decorations).
But only one of them (or actually two, since you can opt in or out to the XP+ theming system that affects not just the title bar, but also the widgets/controls) is the standard title bar provided by Windows. The other ones (such as the Microsoft Office one) are implemented in the respective Microsoft toolkit. How they do it is that they simply opt out of the Windows window decorations and draw their own CSDs, exactly as libadwaita applications do it.
AnsibleAnswers@reddit
Gnome is avoiding decisions that would slow development down further down the road. KDE is doing its usual and is taking on technical debt for instant gratification.
Kevin_Kofler@reddit
What technical debt are you talking about?
Traditional_Hat3506@reddit
When all your information on Wayland are from a slop drama youtuber who gets paid through clickbait and outrage:
santtiavin@reddit
Honestly I don't get what YouTuber you are talking about because I don't consume any distrotube anymore and I have been using KDE Plasma since 2019 which is where they started developing the Wayland session and this has happened more than once over the years
Zettinator@reddit
Until The Qt Company will close down Qt development entirely to further monetize it. It's only a matter of time now, I guess. Their financials don't look good. Plus you have the weird split between classic Qt Widgets and Quick/QML and the heavy focus on embedded systems as opposed to desktop... I see more serious problems on the Qt side, both on the technological as well as management levels.
Qt development is not in KDE's hand, so if Qt Company they fumbles with Qt, they're basically fucked. Qt is a liability for KDE, not an asset.
KnowZeroX@reddit
KDE has a contract with Qt that forces Qt to always release in open source license. KDE can also fork Qt if things fumble.
LvS@reddit
KDE doesn't have the developers to develop Qt.
2rad0@reddit
Maintaining is much easier than developing.
LvS@reddit
But that would mean KDE would stagnate and not progress anymore in their core system.
2rad0@reddit
What more needs to be done, they've moved on to adding crazy features like 3d rendering, and physics simulations. All of that can be thrown in the trash IMO.
LvS@reddit
Does Qt do HDR properly yet?
2rad0@reddit
It has support for various image formats which is probably enough, I didn't dig around too much to see further details but looks like >8bit color components is supported since at least Qt 5.4 with Format_BGR30, and deeper colors added since https://doc.qt.io/qt-6/qimage.html
KnowZeroX@reddit
Qt merged wayland color management 2 days ago
https://www.phoronix.com/news/Qt-color-management-v1
Zettinator@reddit
Some people think the agreement has a loophole. Plus, forking isn't easy - maintaining a large framework like Qt is hard. So that's only possible in theory, KDE simply lacks the manpower to maintain such a behemoth.
Kevin_Kofler@reddit
One loophole is what they now use for the LTS releases, delaying the FOSS release for a whole year to make it basically useless.
KnowZeroX@reddit
Even if it does, they are unlikely to do it anyways. It is pretty much Qt's selling point of being cross platform, open source and widely adopted. Locking things down is only going to make them feel more pressure from the coming competition (like Rust frameworks that offer better memory safety)
And KDE doesn't lack manpower to maintain Qt, I mean have you seen how many KDE applications there are with all kinds of settings? And they can dump some platforms they don't need like embedded and wasm. They can focus on linux primarily fixing windows and mac issues when they have time. It isn't like they are starting from scratch. Even if development would slow down, there is no reason why they can't maintain it.
Not to mention be aware that if you go closed source, KDE is not the only user of Qt. Others would likely support the KDE fork. So KDE will gain support, while Qt would lose all their contributors.
We already saw what happened to OpenOffice and how it got forked into LibreOffice
CrazyKilla15@reddit
What are you talking about.
Even in this hypothetical world where this happens, okay? And? Then what? All the existing Qt code is still there and still Free Software GPL, they cant retroactively re-license it, its all already been released as LGPL. The current version that are already used wont suddenly stop working.
The only consequence would be slower Qt development as the community forks, but thats already the case with existing projects. Both KDE and Gnome depend on lightly if at all maintained projects within and outside of their respective organizations. KDE and SDDM for example.
What if GTK suddenly stops being developed, or Gnome decides to abandon libadwaita and go an entirely different direction again? More distros and forks to use the old GTK versions and styles, XFCE, etc? Nothing different happens if Qt stops being developed openly for any reason.
IchVerstehNurBahnhof@reddit
To the Qt Company's credit, this has been a concern for decades and the big Qt rugpull that was feared just never happened. It's not impossible that they'll change their mind in the future but given their (by now) very good track record I can't really fault devs for choosing it either.
Zettinator@reddit
Yes, but only more recently the Qt Company started to behave erratically.
viliti@reddit
GNOME developers are responsible for a majority of ecosystem-wide improvements to the Linux desktop. GNOME was the first DE to implement Wayland and make it the default when other DEs were still skeptical of it. Along the way, it helped refine and develop a lot of the early protocols needed for desktop use. Flatpak, Flathub and XDG Desktop Portal were developed primarily by GNOME contributors and they are responsible for most of the ongoing maintenance. GNOME Foundation has invested significantly in ecosystem-wide improvements as well—such as using STF funding to improve Orca, develop Newton and Spiel and develop new portals such as notifications and USB portal.
Most of these projects were developed in a way that accommodated other desktops from the start. XDG Desktop Portal was designed to be compatible with Qt and thus KDE. Most other DEs just do their own thing and rarely make improvements that directly benefit all desktops.
Kevin_Kofler@reddit
I am still not convinced that that is an improvement. X11 still has its advantages.
Those are also not without issues. Flatpaks compete with native distribution packages, Flathub with native distribution repositories, and there are lots of drawbacks of the Flatpak approach over the native packages. XDG Portals have been designed for and are mainly useful with Flatpak, though they have now been repurposed also for other uses, such as screenshots or screencasts under Wayland (working around missing Wayland protocols). They are by design very high-level APIs with very strict access control (because they were designed for containerized applications) and do not have the level of flexibility of lower-level APIs. E.g., the screencasting portal gives you a direct pointer to a Pipewire stream, you cannot work on the data with any other framework without first piping it into that from Pipewire.
The accessibility improvements, at least, are appreciated.
That accusation, though, does not sound fair to me at all. KDE has always tried to build cross-desktop standards and libraries, and some of the main freedesktop.org standards originate from KDE. Smaller desktop environments have also done their part with the limited resources they have available. The most frequently hit roadblock there, though, is the uphill battle to get GNOME to actually adopt those standards. There is a strong Not Invented Here syndrome at GNOME.
Getting plumbing layer libraries adopted by GNOME is particularly hard, and basically only possible by using GNOME technologies (C and GLib) for those libraries. Every time KDE has tried getting a C++ library adopted by GNOME, they have failed. Instead, GNOME has often ended up reimplementing the same thing in an incompatible way.
But even standards (that they are free to implement with their own code) are constantly ignored, vetoed or watered down by GNOME, usually with the argument "does not fit our design" that does not really allow for any discussion. The StatusNotifierIcon specification even has a working GTK implementation (libappindicator) that most GNOME applications refuse to link to (and where they optionally support it, distributions often do not enable it at compile time), and GNOME Shell still refuses to support the specification without a third-party extension. The server-side decoration specification for Wayland is "implemented" by GNOME Shell in the most ridiculous and useless way possible, just reporting that it does not support server-side decorations. There are many more such examples.
The reason most successful standards these days come from GNOME is that those are unsurprisingly the only ones that GNOME will definitely not obstruct or veto. Blaming the other desktops for that situation is extremely unfair.
snippins1987@reddit
Wayland is just moving the insecurity from all apps having rights to a bunch of compositors with their own vulnerbilities anyway.
It really isn't that great of an upgrade if you think about it. If your concern is about security then you should work on a permission models, not by restricting what a programs can do with its windows.
All the abritrary barriers that are in placed and the endless discussion and time wasting on respecting some arbitrary barriers remined me of a time where I just started learning programming and embarrassingly tried to make everything OOP, feeling so smart about all of it.
Looking at the state of Wayland, the common sense conclusion is that there has to be a better way for all of this. It just the sunk cost fallacy is way too high now to go back now.
If you look at the implementation of some power users tools, most just work around the compositors by hooking into deeper layers with sudo rights, running as daemons.
Know you have to grant even more rights to these tools, and they still offers less features than before because some features and information is available only in the compositor. Not mentioned the lower level hooks leading to these tools easily conflict with each other. Such a great overall experience! LMFAO.
The more commn sense but "boring" way should be that certain binaries with signature can be grant some rights to do thing with certain windows of certain other apps. But I guess that such a low intelligence challenge and now we have to deal with the Wayland protocol instead. Sigh.
Kevin_Kofler@reddit
Like the Xnamespace extension that has a proof-of-concept implementation in XLibre?
Fit_Author2285@reddit
I would point out that GNOME has a company that plays a significant role in development and funding, whereas KDE is entirely a community.
Jegahan@reddit
KDE did get funding from Valve, and KDE contributor have mentioned in other thread that "they do sponsor a handful of major code contributors to work on KDE".
On top of that, they have the app framework that KDE uses is entirely made and maintained by a for profit company (the QT company) while Gnome maintains GTK themself.
And my point is not that this is bad per se. It's great if Open Source projects get more funding and support, even from for profit companies. But it is hypocritical to pretend like "KDE is entirely a community' compared to Gnome.
Fit_Author2285@reddit
A few minutes ago I looked at the last 50 commits of Gnome shell and Plasma shell. For Gnome, there's clearly a Red Hat developer and a Canonical developer contributing heavily, whereas for Plasma I don't see any.
Jegahan@reddit
Weirdly, I don't find your quick vibe check particularly convincing.
LvS@reddit
KDE has a company that develops their platform library - Qt.
Gnome does that whole part itself.
the_bighi@reddit
Yes, I really hope more apps abandon Gnome stuff. Every time a community grows, there’s someone that eventually becomes a progress blocking innovation and progress in that community. When it comes to Desktop Linux, it’s Gnome.
Cry_Wolff@reddit
r/I amverysmart Linux users hating Gnome since 2010.
snippins1987@reddit
This feels quire ironic to me, isn't the r/iamverysmart archtype basically what the community perceives some gnome devs/designers.
And several blog posts from the Gnome team would fit that sub perfectly.
CrazyKilla15@reddit
Maybe Gnome shouldnt have a decades worth of history of being a problem.
Preisschild@reddit
IMO you are wrong. CSD are clearly superior to SSD and SSD is holding the desktop back.
Kevin_Kofler@reddit
They are not. They are sluggish because of all the extra roundtrips. And if the application freezes, so do the CSD. They are inconsistent between applications. When they can be themed at all, it has to be done multiple times for different applications (if they happen to use different toolkits). They also do not consistently contain the same controls. So, e.g., good luck maximizing or "restoring" (unmaximizing) a window that is missing that control in the title bar. And good luck knowing what application that window even belongs to if the title bar no longer even contains the actual title (as was the case in Easy Effects before the rewrite).
Not at all. The main annoyance to application developers is actually GNOME Shell refusing to support SSDs, forcing toolkits like Qt to ship and maintain a fallback CSD implementation even if they do not actually want to use it, and smaller toolkits or toolkitless applications to link a canned solution like libdecor. Applications that do not do that end up completely broken on GNOME Shell, whereas they work on all other desktop environments out there.
There is a reason why both macOS and Windows default to SSDs and require applications that want CSDs to explicitly turn the SSDs off, just like KWin does it.
Cry_Wolff@reddit
Ladies and gentlemen, this is why Linux desktop will never happen. Y'all too focused on infighting and shitting on each other to actually focus on something productive.
AnsibleAnswers@reddit
Stop flaming.
Epsilon_void@reddit
All the people complaining that it now looks out of place on their GNOME system now experience what everyone else that doesn't use GNOME experiences with a libadwaita program. KDE tries to make GTK2/3 programs match as much as possible, while GNOME doesn't care. GNOME also went out of their way to make theming a royal pain with GTK4 and libadwaita.
Vivid_Valkyrie@reddit
This ain't it. The issue is neither UI framework plays nice with desktops built on the other UI framework and that is an issue, doesn't matter who it is, the experience is rubbish. This isn't a KDE vs GNOME thing, this is an issue basically everyone runs into at least once if they use desktop Linux. As long as these UI Toolkits refuse to function nicely on the opposite desktop, this will remain a problem for EVERYONE
Interesting_Put8754@reddit
At this point, shouldn't Gnome users be already reconciled to the fact that most apps, including most of the ones you actually need, will NEVER visually integrate with Gnome? The only way to integrate your app with gnome is to rewrite the whole thing in GTK, apply libadwaita to remove any cross-platform compatibility, then redesign the freaking interface top to bottom around Gnome's one-of-a-kind HIG.
Tough-Smile8198@reddit
the GTK version of easyeffects looked great on KDE. This piece of shit doesn't even look good on KDE.
xSael_@reddit
Except I'm not on GNOME but it still wont follow my QT Themes.
Jegahan@reddit
You do realize that QT apps have existed before Easyeffects transitioned to it, right? By your own admission QT don't fit on Gnome the same way that Libadwaita apps don't fit on KDE. But somehow its only a huge problem when Gnome does it, right? Or maybe... maybe its just completely normal that app devs chose a framework and design they like and that not every design will fit every DE.
Epsilon_void@reddit
You can use qt5ct/qt6ct to theme any QT program on GNOME to match your system however you desire, or however much GNOME allows it to match. GNOME intentionally goes out of their way to be a pain to other distros as they only care about themselves.
Jegahan@reddit
No you can't. It never looks right. It turns out design is more than just changing some colors and shapes.
And if you think colors and shapes are enough, then you can do just as much with gtk ([1], [2], [3], [4] and you can find many more examples on places like Unixporn). Or [here](https://imgur.com/a/aghE5pa) is one I quickly installed in a VM that makes Libadwaite look like Mac.
n0kyan@reddit
I really don't get why this is getting downvoted, most Qt apps are fundamentally designed differently than most libadwaita apps. Colors might just about match, but that doesn't change the design and flow of the app.
The only Qt app that I use on my GNOME desktop is Prism Launcher and while the UI colors do match libadwaita's colors, its general UI design still sticks out like a sore thumb compared to all the other apps that I use that are mostly libadwaita.
Jegahan@reddit
Some of the people on reddit have spend years acting like Gnome apps not fitting on other DE is a crime against free software. So admitting that the same is true for KDE apps would go against their narrative.
In fact I'd argue the situation is worse for KDE apps given that not only it doesn't fit, but its also at times broken. Here is Dolphin on different DEs in Dark mode. Gnome is the only DE where dark mode wasn't broken and even in light things didn't look great (look at the weird widget in the bottom right corner, I think it's supposed to be a bar that fills up)
ThatOneShotBruh@reddit
Welcome to how it feels it use a libadawaita app if you aren't on GNOME :)
AnsibleAnswers@reddit
It never looks like Gnome.
ColorfulPersimmon@reddit
The point is, it's way easier to style Qt to make it fit your system than theming GTK 4.
tristan957@reddit
GTK4 supports the same CSS styling that was supported in GTK3. Your comment doesn't make sense.
the_abortionat0r@reddit
Bro gnome team literally tells you NOT to theme their stuff. They even wrote a cringe blog about it. So yes now you can use actual themes.
Isofruit@reddit
Unless you are a distro, they aren't telling you jack. They also wasn't GNOME, but various GTK app developres. This lie gets brought up over and over. The blogpost was and still is directed at distros to protect app developers from bug-reports, because users can't know that they're getting a themed app from a distro and if they encounter an issue, whether that is because of the theme or the OG app. In that case they'll always blame the app, leading to unnecessary bugreports and work on the app developer side.
tristan957@reddit
You can use themes for GTK4 and libadwaita if you want. You completely misunderstood the point of the "stop theming my apps movement". It called on distributions to stop theming by default.
Zettinator@reddit
It really isn't. There are many ways today to make Qt apps, and they all look different. You can easily have three Qt applications that use the same basic framework and they will still look wildly different on the same system. So Qt isn't even consistent in itself!
The only thing that actually can be themed well are legacy Qt Widgets applications. Qt Quick Controls? Theming support is crap. Custom Qt Quick apps? Of course not, as everything is fully custom. Kirigami apps (this is the component library used by EasyEffects)? It uses a fixed QQC styl and only colors can be adjusted... which unsurprisingly similar to libadwaita!
Kevin_Kofler@reddit
Kirigami actually ships a QtQuick Controls desktop style that uses the drawing methods of the QtWidgets QStyle, so it can look like any QtWidgets style. It might not be the default on your distribution because it is slightly less efficient than the hardcoded QtQuick Breeze style and makes QtQuick depend on QtWidgets, but it is there.
Jegahan@reddit
I have never seem a QT theme that made KDE apps fit Libadwaita. Changing a few colors and shapes is not enough, the whole structure of the app doesn't look right.
And if you think colors and shapes are enough, then you can do just as much with gtk ([1], [2], [3], [4] and you can find many more examples on places like Unixporn). Or here is one I quickly installed in a VM that makes Libadwaite look like Mac.
ColorfulPersimmon@reddit
Catppuccin has 441 active ports, but they dropped GTK support because it's too much hassle to maintain, so I don't think styling GTK is trivial source
Zettinator@reddit
This is for GTK3, which still used traditional theme engines, which were indeed a PITA and this is why GTK4 doesn't have the anymore in favor of CSS-based styling. It sounds less powerful in theory, but as the previous poster has shown, you can do quite a lot with it.
FWIW, Kirigami is basically the same in this regard.
Vittulima@reddit
This is so Reddit
AnsibleAnswers@reddit
I don’t really see people complaining so much as they are correcting some misinformation. We’re used to shitty looking QT apps. They’ve always existed and they always look like shit.
ilikedeserts90@reddit
Truth nuke here. GNOME has been playing dirty with practically every other desktop project for years. What goes around comes around.
manobataibuvodu@reddit
That's a shame, I really liked how it looked with libadwaita. But I don't need fancy features so maybe I can just keep using the old version.
Kevin_Kofler@reddit
And I think the Kirigami version looks much better: more colorful, more efficient space use (less useless whitespace), no more title bar abuse.
Preisschild@reddit
Client Side Decorations have become standard in prety much every operating systems. Because they are just better.
Kevin_Kofler@reddit
Nonsense. Server Side Decorations are consistent across all applications, centrally themable, more efficient (so less lag when interacting with them), and contain the same controls and information everywhere (whereas the "title bar" in the old version of Easy Effect did not even contain the actual title!). Client Side Decorations just suck and only GTK developers think they are the way to go. Pretty much every operating system supports and (if not explicitly requested otherwise by the application) defaults to Server Side Decorations. GNOME-based ones are the only exception.
Preisschild@reddit
Also saw you defending X11 recently, you are stuck in the past.
I dont nee the title in the bar, I need actions that I actually use.
Kevin_Kofler@reddit
The title is not just useful to show the title, it also offers a good grab for moving the window. In the crammed libadwaita "top bars", you have to actually hunt for an empty space that you can grab somewhere between all the toolbar controls.
manobataibuvodu@reddit
You can drag over the buttons too, it's fine
Interesting_Put8754@reddit
What happens if you're not using a Gnome app? Can you drag over the buttons? Does it have shadows? Does it have shadows consistent with other applications? Is the windows shape consistent? Are the window buttons consistent? Does it attempt to use GTK3 drawing routines only to end up looking like buggy shit (e.g. Firefox)? Literally nothing about Gnome's implementation of CSD works in the real world and it's been nearly two decades.
manobataibuvodu@reddit
Then you don't expect the app to follow GNOME's HIG.
Depends on the toolkit and/or HIG the app is using. If they don't then I would suggest for them to add this feature because it is convenient. Now that I think about it, it would be interesting to see if Windows or Mac apps do this too but I don't have a machine with either of them currently.
But it's not really GNOME's fault if some app chooses to use another toolkit with bad design choices.
Having 100% consistent shadows would require them to be drawn by the compositor. I've seen somewhere that GNOME designers would like to see that happen. It's just that no one has took it up to implement that.
No. Again, you don't expect the app to follow GNOME's HIG. Unless you want to theme it, then maybe it does. I've seen cool looking Adwaita themes for Firefox and Steam online but I've never personally tried them.
No clue what you're talking about here, I've been using Firefox for ages and it looks fine.
I've been using GNOME for over a decade "in the real world" and it's working fine.
Interesting_Put8754@reddit
> Having 100% consistent shadows would require them to be drawn by the compositor. I've seen somewhere that GNOME designers would like to see that happen. It's just that no one has took it up to implement that.
Maybe if they didn't spend whole decades angrily dismissing any suggestion of ANY server-side or other centralized involvement in decorations, then we'd have an implementation by now. This is something that should've been done as step 1 of Gnome's CSD and wasn't. Glad they're finally seeing reason but the damage is done and you'll never get anything remotely approaching consistent decorations on Gnome, something every other platform takes for granted.
> No clue what you're talking about here, I've been using Firefox for ages and it looks fine.
Firefox had corner bugs for ages, in the course of trying to mimic (still unsuccessfully lol) whatever window shape Gnome is going with at the moment.
manobataibuvodu@reddit
I don't think that's true. It's been ages since I used Windows but there used to be non-native looking apps on it too (well, those that used different toolkits I guess). Also in general Windows isn't known for it's design consistency.
I almost exclusively use Firefox maximized so that might explain why I didn't see problems with that. Either way I don't really see why they should be trying that hard to mimic GNOME, it's not like I expect it to follow the HIG.
Interesting_Put8754@reddit
Inconsistency on Windows is mainly a consequence of developer negligence, not the platform's failure to provide consistent decorations. On Gnome, it's a platform issue.
Kevin_Kofler@reddit
Yet, KWin implements exactly that. As part of SSDs. Might not work properly with GTK CSD apps, but that is then not KWin's fault.
manobataibuvodu@reddit
It won't work with any CSD apps, not only GTK (for example - VS code can use CSD to save space, I use that). And it's not really Kwin's fault currently really - there needs to be a wayland protocol for it first.
Interesting_Put8754@reddit
Having apps with literally no standardization of shadows, window shapes or titlebar behavior across toolkits, or even GTK versions is NOT standard. This a Gnome innovation. Moreover, there's not even any way of implementing it.
Zettinator@reddit
And I think it looks fugly. "More colorful" is not better by principle. In particular, it's really bad that the tab buttons do not actually look like tab buttons and how the spacing between those tab buttons at the top and bottom is missing. They're touching the separator lines, which just looks wrong.
You certainly can make good looking and intuitive UIs with Qt, but this is a bad example.
Kevin_Kofler@reddit
Neither do the ones in the libadwaita version. They are just flat. With Qt Quick and Kirigami, you can actually have tab bars both with the flat buttons like libadwaita and with actual skeuomorphic tabs, not sure why the application has chosen to use these buttons instead.
The spacing is not missing, it is not necessary and hence not present.
Zettinator@reddit
I guess we can agree that both the GTK as well as the Qt version are bad examples of how to design a UI.
deikatsuo@reddit
agree, gtk version look better
Nereithp@reddit
I also think it looked much better before, but you might still want to switch if you need global shortcuts. Granted, I never actually had a usecase where I wanted to use global shortcuts with EasyEffects (I mostly just use it for a small EQ tweak for my headphones), but still, the option is there now.
Kevin_Kofler@reddit
All the apps currently using libadwaita should really do this. Kirigami is much more flexible, both for the developer and for the user (theming). Libadwaita goes out of its way to enforce a very particular GNOME look&feel, take it or leave it.
You can compare the screenshots:
What I can see:
And what the screenshots do not show is that Kirigami is designed to be themable by the user, so you can make it look different than in the screenshots if you do not like the default look&feel, whereas libadwaita is designed to look exactly as in the screenshot.
AnsibleAnswers@reddit
You can absolutely apply different color schemes within libadwaita apps. See Resources for a good example. https://flathub.org/en/apps/net.nokyan.Resources
Interesting_Put8754@reddit
You can't theme theme them as a user either, not practically.
AnsibleAnswers@reddit
https://github.com/SwordPuffin/Rewaita
TiZ_EX1@reddit
Nice, two whole color schemes, light and dark! And don't forget the hand-selected accent colors and nothing else.
You can say "Please Don't Theme only targeted the distros", but that's a lie that gets parroted back over and over and over. Users don't have any meaningful theme control, and that's always how they've wanted it.
AnsibleAnswers@reddit
I’m talking about the different color schemes for each section of the app. You actually don’t have to design an app to be monochrome. That’s just what EasyEffects did. All of the color available in the QT version could have been applied to the GTK version. It’s incorrect to suggest otherwise.
The reality is that QT poorly supports theming as well. It routinely breaks applications. If you want to play with applications instead of use them, I can see why you might be upset. Most people just want the application to work as expected and most developers don’t want a bunch of unnecessary bug reports. Not having theming options in Settings is a compromise most users are more than willing to make.
TiZ_EX1@reddit
Don't know what reality you're talking about. Qt supports alternate widget styles, as well as the more impactful and widely-useful ability to create and use custom color schemes. Even applying a custom accent to existing color schemes. And not the handful of hand-selected ones GNOME allows. Any accent color. GNOME could have had this too. GTK2 did have this, and early versions of GTK3 did too.
Ah yes, the tired accusation that customizers don't actually use their computers. I can tell you definitely signed the Don't Theme letter. Everyone who signed it has that sort of contempt for customizers.
LvS@reddit
GTK2 and early GTK3 themeing is laughably bad compared to what you can do with late GTK3 and especially GTK4.
If that isn't obvious, just remember that there's a live theme editor built into GTK these days.
The problem with that is that it allows coming up with fancy designs with intricate themeing details, which is essentially what Adwaita has done. It's a whole project of its own that's compiled to almost 5000 lines of dense CSS.
Such a design is so complex that you can't easily allow hacking on without it causing breakage all over the place when the next update happens.
So basically you have 2 options:
Make a medium-sized theme API that is well-defined and allows implementing many themes. And then force all applications to only use that API. If they want to do something else, they can't or it will break themes.
That's the KDE (and old Gnome) approach.
Make one single very complex theme that allows all sorts of things and allow applications to go crazy with it. Then you will have lots of interesting applications that all seem to share the same design even though they have rather different UIs.
That's the Gnome approach.
Kevin_Kofler@reddit
Yet the Easy Effects rewrite proves that one can replicate pretty much everything one can do in libadwaita in the much more themable Kirigami. What libadwaita developers are doing is confusing logic with optical design. The purpose of a library like Kirigami is to provide logic. The purpose of a theme engine is to provide optics. But libadwaita wants to be both at the same time, which breaks themability without adding any value over themable alternatives such as Kirigami.
LvS@reddit
Obviously you can draw the same thing with both toolkits, they both can draw pixels, so you can somehow produce the same pixels with both.
The question is how hard it is to produce those pixels, and that's where the theming gets relevant.
And the statement about "logic" vs "optics" makes no sense. There's no way to describe a visual interface without talking about how it looks. All the components have relationships to each other and that puts constraints on what you can do.
Buttons need to be larger than text for example so they can contain text. So you can't demand that 5 buttons are smaller than 4 lines of text.
Or for another example, backgrounds and foregrounds need enough contrast so you can tell them apart (shoutout to Looking Glass!) So you need to define if the warning color and the user's accent color must have enough contrast or not so theme designers and application developers know if they can be used that way and accent color selection can avoid colors that won't conform to those requirements.
Kevin_Kofler@reddit
If you think a library of controls (widgets in the traditional sense) is just (or even mainly is) about "drawing some pixels", you are missing the point completely.
A library of controls (e.g., QtQuick Controls or Kirigami) defines, e.g., a tab bar. That is all the application should (need to) care about: I want to show a tab bar allowing the user to choose a tab. (That is what I mean by "logic".) A theme defines how that tab bar is actually presented to the user: Should the tabs look skeuomorphic, as in a physical tabbed organizer? (And if yes, should they be rounded? Should they be beveled to look 3D? Etc. Lots of different ways the tabs can look even within this category.) Should they be flat buttons as in libadwaita and in several mobile styles? Should they be skeuomorphic radio buttons? Should the tab bar look as in some versions of macOS: one fused rounded button, with vertical separators between the tabs, and the portion corresponding to the active tab highlighted in the highlight color? Should they use a completely new design? (That is what I mean by "optics", though a good theming API also allows tweaking the "feel" to some extent, not just the purely optical "look".)
If the application directly knows about the exact pixels that will end up on the screen, that is a loss of abstraction that makes things harder both for the application developer (who has to micromanage all of this) and for the user (who will have a hard time theming the application to integrate into their desktop environment, at least if it does not happen to be the same one the application developer uses).
LvS@reddit
As I said above, that abstraction limits application developers to a fixed set of controls. If they want a frobnicator with a thagomizer, the theme will have no idea what to paint.
It also makes the app look like a bunch of lego blocks that can't really interact, because each control is defined by itself.
It's why dragon player puts the control elements into a bar above the video, while Shotime puts them on top.
Kevin_Kofler@reddit
Dragon Player is a QtWidgets application. Haruna would be the Kirigami application. But your point still stands, because that puts the control elements in a bar below the video.
That said, controls above the video are a frequent pattern on websites, and I consider that an antipattern. Those controls keep obscuring parts of the video, e.g., if I want to pausing the video to watch a still picture closer, after pausing the video, which brings up the controls, I have to wait for the controls in the middle of the video to disappear, if they even disappear at all. It is also not constantly visible how much of the video I have already watched and how much is left, and when it is visible, it again covers part of the video. So I think copying that bad design in a desktop application is a bad idea, I would rather want the websites to stop doing that. The Showtime screenshot also shows an additional issue that the websites do not have: Due to the rounded window corners, the corners of the video are chopped off! So I think the way Dragon Player or Haruna do it is the right way.
cwo__@reddit
Not anymore, it was ported a few months ago and is now a Kirigami application as well since Gear 25.08.
FWIW, it has the controls as an overlay, but as a bar at the bottom rather than in the center of the screen (and if the video ends up letterboxed due to the aspect ratio being lower than the video's, it'll appear in the letterboxed part).
Traditional_Hat3506@reddit
the video keeps its aspect ratio, if you increase the height it fill the empty space with black bars
Kevin_Kofler@reddit
That just makes the interface even more ridiculous: instead of having an undisturbed video and controls above and/or below, you have unused black bars and an overlay. I guess parts of the overlay will be in the black bars, but there are overlay controls even in the middle of the video (and awful antipattern that web video players have introduced at some point and that this desktop application is now copying).
AnsibleAnswers@reddit
Stuff always breaks with custom themes. Just look at any theme’s issue tracker. It is added complexity. That means added bugs.
I’m not a developer. I really just tend to think theming is a waste of my time. It’s valued by very few people and creates headaches for developers. I’d rather developers fix more important bugs and add actual useful features to their applications.
Kevin_Kofler@reddit
You are largely underestimating the amount of users who are upset about how alien a libadwaita application looks on, e.g., a KDE Plasma desktop. Theming does not just mean being able to pick "Joe's fluffy unicorn theme", but also applications by default auto-detecting the underlying desktop environment and matching the theme the user has set there to the extent possible (at the very least, the default theme of the desktop environment needs to be supported).
AnsibleAnswers@reddit
You can just stick to KDE apps and deal with the fact that most of them are an unmaintained, buggy mess. The two issues are related.
You can either have themes or a disk management/partition app that uses UUIDs in /etc/fstab.
Kevin_Kofler@reddit
UUIDs are not the panacea that solves all problems either. All methods to address partitions have their drawbacks. In the UUID case, if you
ddan entire disk, you end up with duplicate UUIDs, so your UUID fstab becomes Russian roulette for your data. So you actually have to bring up a partitioning tool to regenerate the UUIDs on the cloned disk to avoid nasty surprises. (But the other methods also have their problems. LABEL has the same issue withddand is even more likely to be accidentally duplicate. Raw device names are problematic if the order the devices are detected is not deterministic.)AnsibleAnswers@reddit
That’s very predictable, unlike kernel block device names that change all the time now.
Kevin_Kofler@reddit
Blame the kernel for that.
And if you want KDE Partition Manager to use a different scheme for fstab, feel free to submit a pull request implementing that. :-) You will discover in the process how much easier it is to develop with Qt/C++ than with GTK/GLib/C.
AnsibleAnswers@reddit
I’m good using Gnome Disks.
Kevin_Kofler@reddit
Most people want the application to look&feel like all their other applications, which is usually the look&feel corresponding to the desktop environment. That is why we have themes such as Breeze-GTK. Users also expect the distribution, or even better, the toolkit itself to set that up automatically, without having to manually tweak configuration files. The fact that GNOME has never accepted that reality (so both the GNOME theming for Qt and the KDE theming for GTK have always come from Qt/KDE developers, never GNOME/GTK ones) and is now actively fighting it with "Stop Theming My App" is a big obstacle for interoperability.
AnsibleAnswers@reddit
QT apps never blend in with Gnome no matter how hard you try to theme them. This is because QT apps don’t follow the HIG. You don’t see Gnomies complaining. You’re actually more likely to see them porting apps to libadwaita.
“Don’t theme” is 100% about decreasing bug reports. It’s not about being hostile to users, it’s about having priorities.
Kevin_Kofler@reddit
No, it is because GNOME has bizarre HIGs that do not match the industry standard, with crazy ideas such as merging the toolbar into the title bar, which necessarily leads to GNOME apps feeling completely weird on any other desktop environment, and non-GNOME apps feeling completely weird on GNOME.
AnsibleAnswers@reddit
Header bars are also standard on browsers and pretty much every electron app in existence.
Jegahan@reddit
Don't you understand? If we exclude everything that Kevin declares to be bad, then whatever he considers good is the only thing left and is therefor "Industry standard".
Kevin_Kofler@reddit
Just because Google designers came up with a strange idea and Mozilla decided to copy it in Firefox (because they copy all the bad ideas from Chrome) does not mean it makes sense to put into the HIG for a desktop environment and desktop applications.
Electron is a horrible hack abusing browser (Chromium) and server (Node.js) technologies to develop desktop applications. The fact it exists at all is because someone noticed that Chromium and Node.js happen to use the same JavaScript engine (V8) under the hood. Since it is basically Chromium, of course it has the same broken design elements as Chrome.
Traditional_Hat3506@reddit
apple has been doing this for the last decade+
windows introduced it with their ribbon ui https://en.wikipedia.org/wiki/Ribbon_(computing)
it is an industry standard, unless the industry you are talking about is frozen in the year 2000.
Kevin_Kofler@reddit
Microsoft Office has been widely criticized for that ribbon "Fluent UI", which went against Microsoft's own HIG at the time and which made Microsoft Office basically unusable for all users of previous versions. (In fact, it was much easier for them to switch to LibreOffice, which closely resembles the old Microsoft Office UI, than to the ribbon-infested version of Microsoft Office.) The controls in the title bar are just one of the insanities there.
Even on Windows, this is far from being a consistent design standard. The only applications using it either come from Microsoft or have been specifically designed to look like Microsoft Office. And even then, those applications' version of the ribbon UI does not necessarily include the controls in the title bar.
Windows is also pretty much a negative example in that there is no consistent look&feel (anymore – it was different up to around Windows 95). Proprietary software vendors, including Microsoft itself, using the application theme as a branding element have ruined that. I do not think this antipattern (every application looking different) is a good example to follow.
I want my applications to all look the same, no matter whether they use Qt, GTK, FLTK (etc.), or some random developer's custom toolkit. I miss Red Hat Bluecurve that was impressively good at that (and in fact I had maintained a Qt 4 port of Bluecurve called "Quarticurve", but porting that to Qt 5 and 6 and GTK 3 and 4 was too much work for one person, so I had to give up on it) and find it sad that Red Hat has given up on that. (Their latest attempt at a consistent look&feel, QAdwaitaStyle, has also been discontinued and never updated to the new libadwaita Adwaita look&feel. Though I would not want my Qt to look like that anyway. ;-) )
Fit_Author2285@reddit
KDE is fully aware of this problem, and it's one of the main goals of Union (the new KDE theme engine) presented at Akademy 2024:
https://invent.kde.org/plasma/union
AnsibleAnswers@reddit
I get that. It’s just… as someone who’s extensively worked with Windows, Mac, and Linux, it seems “themability” as a feature is really a niche case that creates a lot of complexity where it isn’t needed. It seems primarily suited to those who actually want to spend time configuring their DE to look the way they want. I think most computer users want to spend as little time possible configuring their DE.
Such a use case also seems ill suited to multi-user environments in which one user might need to show another how to do something without them getting confused by theming.
julicenri@reddit
Aside from customisability allowing people to personalise their personal computers' software looks, accessibility is also a major reason in favour of theming.
I have run often into folks with vision problems who struggle with most modern interfaces, due to UI elements becoming very hard to distinguish from each other. In some cases, adding outlines isn't enough and changing to a non-flat theme is necessary.
On the other hand there are people who need as minimal UI chrome as possible, since too much can become debilitatingly distracting for them to actually do work.
While KDE developers and designers do try to cover as many groups of people as possible with Breeze, realistically it isn't possible to cater to everyone and it has to be possible to change the theme outright when needed. After all, accessibility is a spectrum and flexibility is paramount to good accessibility.
Kevin_Kofler@reddit
Arbitrary themability is mainly useful for a small niche, though one that should not be ignored either because they are the most prolific screenshotters. But what many users expect is a consistent experience, where GTK and Qt applications both pick up the chosen desktop's look&feel, not GTK ones looking the GNOME way and Qt ones looking the KDE way.
AnsibleAnswers@reddit
The most prolific screenshotters? Oh we definitely have to introduce mountains of bugs into software code bases in order for them to be happy! Or we can choose not to be hostile to developers and get more apps with less bugs and more features.
Kevin_Kofler@reddit
Screenshots is what users discover applications from, or even entire operating systems. If your software does not appeal to the people making screenshots, it instantly loses a lot of potential reach.
AnsibleAnswers@reddit
🙄
Druben-hinterm-Dorfe@reddit
Arguments as to why 'themability' is so desirable tend to boil down to vague, hand-wavy accounts as to why 'customizability' is always good. 'Customizability', though, can pertain to function or appearance; the 'themability' debate obscures the former by creating a pointless controversy on the latter.
What would really help Linux desktop apps is scriptability; & properly populated dbus interfaces, that is, 'customizability of function'. That's the one area in which I wish more Linux desktops would imitate macOS, not the rounded corners.
Jegahan@reddit
Wow... the dishonesty on display is actually quite baffling...
First you know full well that other color schemes exist, as I'm pretty sure we already had a similar discussion in the past. Amberol for example colors the windows based on the Cover art of the played music. Other apps like the Text Editor and Ptyxis have build in option to use other color schemes.
Again with the lies. Here are a few theme I fund on r/Unixporn with 3 sec of search [1], [2], [3], [4]. Or [here](https://imgur.com/a/aghE5pa) is one I quickly installed in a VM that makes Libadwaita look like Mac. But again, I'm pretty sure this type of themes have already been shown to you in the past.
This is just so insidious. The open letter specifically say so, but you declare that you know better and invent whatever "evil" intentions fit your narrative.
Kevin_Kofler@reddit
You, too, do not seem to get the concept of a consistent systemwide look&feel:
Those options to use color schemes are application-specific and not something that can be applied globally to all libadwaita applications, which would be the point of a system-wide color scheme.
Also, all the customizations to libadwaita you show there are just color schemes and not actual themes. Even the one you claim "looks like Mac" seems to be just a color scheme (though your screenshot does not show many actual controls that one could compare to a modern macOS screenshot).
And "Stop Theming My App" also asks distributions to not default to something like Breeze-GTK. Complying with that significantly degrades the default user experience for KDE Plasma users. Defaults matter.
Jegahan@reddit
Blaming Gnome for a lack of "consistent systemwide look&feel" is extremely hypocritical, given that KDE apps also don't fit other DE. Not only that but, they can often just be straight up broken. I just tried Dolphin on different DEs and only on Gnome did the dark mode work. All the other stayed in light mode and some even had no icons or white text on white background.
I sure user can fix this with a little bit of work but: 1. Apps shouldn't come broken out of the box and user shouldn't have to fix them 2. You can only fix the look. KDE apps will still feel like KDE app and the layout will still not fit completely 3. As I showed in the previous comment, you can still theme Libadwaita apps
You say "Defaults matter" and I agree. But by default KDE apps tend to be broken on other DEs and I would have much rather have the app look and feel like it does on Plasma. You can complain about Libadwaita apps not looking like other apps on other DEs but firstly, you can adapt the look if you want to, secondly at least the look and work the way they where design to and are usable out of the box.
No they are not. Some of the examples I gave literally changed the shape of buttons, the padding or the window corners. Here is another example where the theme offers the two version, with one being more compact.
You know systemwide coloring is possible, given that you replied to another user pointing out the existence of Rewaita: "That is just recoloring, not theming". Why are you being dishonest?
On top of that, I was replying to somebody who was pretending that only "two whole color schemes, light and dark [...] and nothing else" where possible in Libadwaita and was pointing out that this wasn't true.
I'm sorry but I'm not buying this. Significantly degrades? Really? What about Steam, Heroic game launcher, most of the IDEs, any electron app, every single website under the sun and I could go on? People have never and will never have a consistent design through out the entire system. It has never worked like this. Acting like some apps not adapting "significantly degrades" the user experience is way over the top.
Kevin_Kofler@reddit
Qt tries hard to match the design of the underlying desktop environment out of the box. In fact, Qt has even implemented a QGtkStyle that uses GTK 2 drawing primitives to draw the widgets, so it matches pretty much any GTK 2 style. Unfortunately, newer GTK 3 versions have completely changed how theming works in GTK, so making a QGtkStyle for GTK 3 or 4 would basically require a complete rewrite. I believe that there was an unofficial QGtk3Style GTK 3 port of the GTK 2 QGtkStyle at some point, but that it no longer works with the current GTK 3. The best you can get is Adwaita-Qt, but that would require constantly catching up with Adwaita changes, which is no longer going to happen because Adwaita-Qt is no longer maintained. The reason being that GNOME users just kept complaining (loudly, not in normal bug reports) about every minor graphical glitch instead of appreciating the consistent look&feel.
That said, KDE Frameworks or individual KDE applications sometimes do hardcode some theming aspects by default, to work around that "But by default KDE apps tend to be broken on other DEs and I would have much rather have the app look and feel like it does on Plasma." issue you mention. Ideally, we would fix the Qt desktop integration theming instead. (But ideally, the GNOME developers would help with that, just like KDE developers are the ones working on Breeze-GTK. Sadly, GNOME does not care.)
The Dolphin dark theme issue is a clear bug. It does not really help that GNOME Shell defaults to dark whereas most other desktop environments default to light, but that really just makes the bug more visible. It needs to be fixed either way.
OK, I understand now (though without a side-by-side comparison, it is hard to really tell the difference). The tweaks are so subtle that they are barely noticeable. I still wonder whether a radically different look, e.g., making a libadwaita application look like a Windows 95 application, is even possible.
Rewaita is a third-party application that works by directly writing CSS files to change color settings there. (I would consider that pretty much a hack.) This is not a built-in or officially supported feature of libadwaita.
Out of the box, without third-party applications writing custom theme CSS, that is all you get. The usual issue with GNOME where you need third-party "tweak apps" to change even very basic settings.
Proprietary applications tend to always stick out like a sore thumb, because proprietary vendors want to be noticed and display a branding, at the expense of the user experience. But not everyone uses them. I do not.
Jegahan@reddit
First Adwaita-Qt didn't provide "consistent look&feel", it just made QT app look really bad. And thats a shame given that (even though it's not my favorit design) I think that KDE are well made. But you only get to appreciate that on Plasma. Secondly It's almost as if, contrarily to what you are pretending, user don't care as much about "consistent look&feel" and would rather have functioning apps.
This bug has been there for at least 2 years, given that in a discussion in sept 2023 I did the same check. Its is perfectly for you to feel like full on theming buy default is worth it but at the very least this is proof that it also comes with some significant challenges and that there are good arguments for being against it.
It's not other DE's job to fix other peoples apps. And why single out Gnome and not all the other DEs? At least with the quick check, I didn't find a single one where dark mode worked.
So you don't know yet you still make broad statements about what possible in other comments?
And? The same applies for the majority of themes on KDE. It's still possible to competely change the look of Gnome apps if you want. Being "built-in or officially supported" doesn't change much, particularly when the result can be so broken as shown in the previous post. And as far as I know Rewaita, Gnome Tweaks or Extensions haven't yet deleted their users home directory, contrarly to themes from the KDE store.
You just jumped to a conclusions without checking again. This isn't just proprietary apps and I already gave you examples that aren't. Heroic Game Launcher is open source, same with many IDEs. Also Signal, Knime, Freetube, Zotero, tutanota and these are only the ones I could think of quickly. You also ignored website (some of which are also open source). You say "But not everyone uses them. I do not." I doubt you don't use the internet, particularly given that we are writing this on reddit.
And this all still doesn't even address my point. Even if you actually were able to only use stuff that fits your theme, in practice that vast majority of people don't. In most cases people will have app with different styles, because they do use thing like the open source apps I pointed out, but also like steam, discord, other messengers, the internet etc.
Kevin_Kofler@reddit
It did what it could within the technical constraints. Of course it cannot magically move controls into the title bar. (Because, well, which ones?)
It is a concious decision by GNOME to not care about the technical constraints of cross-platform applications when designing their HIGs, so it is not fair to blame the cross-platform toolkits for that.
If it is an issue only showing up on your desktop environment, then why would it not be that DE's job to at least help fixing it?
Because they are the only DE not caring about how foreign applications look on their DE. KDE developers consider it their reponsibility to make third-party applications work well and look good on Plasma, and are willing to work with toolkit developers on that, and even to design themes such as Breeze-GTK.
KDE does not require a third-party application to change the systemwide color scheme. There is a page in Plasma System Settings for it.
For QtWidgets styles, some badly-written user-contributed SVG-based themes that do not use the recoloring support that is available might not honor that color scheme, but the high-quality themes all do.
For QtQuick applications, at least the themes provided by Kirigami (Breeze QML and QQC2-Desktop-Style) honor the color scheme too.
For Plasma themes (for the desktop itself, not for applications), while it is unfortunately true that many do not support recoloring according to the color schemes, the current default Breeze theme supports it just fine, and there are also some other themes that support it. (The first one was the Aya theme.)
Hopefully, the planned unified KDE Union theme will make this even more consistent.
The Breeze QtWidgets style also ships with a configuration application that allows you to tweak even more settings, a level of flexibility that you will almost certainly never get with libadwaita.
I have Reddit open in Falkon right now. Falkon has a standard SSD title bar, a standard menu bar (which I think is off by default, but easy to enable), and then I can choose whether I want the tab bar above the toolbar (the default, slightly non-standard compared to other applications, but how most browsers do it nowadays) or the toolbar above the tab bar (matching the other applications). At the bottom, there is a standard status bar. And Falkon even allows me to replace the Chromium scroll bars with native Qt scroll bars (which does not work for things such as frames or iframes, those always use the Chromium ones, but for the main scroll bars, it looks really well). So the only ugly controls are actually the ones drawn by the website itself, such as the Comment and Cancel buttons.
Jegahan@reddit
I'm not blaming KDE, I'm saying that there is no good solution to get everything consistent. You seem to just declare that the design that you like is "the default" and that therefor any design that differs is to blame, instead of recognizing that different people will create and like different designs. Why should Gnome be blamed for not being able to be adapted to the design you like, and not KDE for not doing so to the design I like? Or maybe we shouldn't try to blame anyone and just accept different preferences and let different designs coexist?
To be honest, I should just stop there. You literally didn't read what I said and just flew over anything that didn't fit your preconceived conclusion. I literally said and gave you screenshots showing that Gnome is the only DE where Dolphin isn't broken in dark mode. On all the others (Cinnamon, Xfce, Mate, Patheon, Cosmic) Dolphin is either staying in light mode (2 out of 5) or is outright broken (3 out of 5). And again, it's not the DEs job to fix this. KDE should make sure their apps aren't broken out of the box.
You went into a full tangent and completely ignored my point. I don't care if theming is officially supported or not. If I have to download an app or a theme to change the look of the apps, so what? Being officially supported didn't prevent KDE apps from being broken on other DEs. This level of theming has always been a fragile hack. And arguing that its everybody else job to do additional work to make sure it doesn't break isn't reasonable.
You again managed to write a full paragraph while still not addressing my point. So the small frame that the browser forms around the website is consistent with other KDE apps. Good for you. In the quote you replied to, I was literally talking about everything but the browser interface, the websites that make up about 90% of the browser window and in the vast majority of cases won't fit the look and feel of the DE. You also completely ignored all the other examples of apps I gave and also ignored that most user will not stick to QT apps and will need apps with differing designs at some points.
Kevin_Kofler@reddit
You are still ignoring the reality of technical constraints that make the GNOME design only possible to implement globally in a consistent way if you control the whole stack, as GNOME does with GTK/libadwaita applications. A design that relies on custom top bars instead of default title bars simply cannot work in a cross-platform toolkit that adapts to the current desktop environment's native look&feel. Either you do away with the concept of cross-platform toolkits (accepting to only use libadwaita applications with your GNOME setup and to only use libadwaita applications on GNOME and nowhere else), or you are stuck with toolkits imposing their look&feel identically everywhere, no matter how out of place it looks (which is what libadwaita does by default).
Jegahan@reddit
Yes and a design that relies on "default" title bars cannot "work" in a DE that has on "custom top bars". Again you just declared your favored design as "default" and conclude that therefor everything else is wrong. Even calling title bar "default" is funny given that all the major OS have been using "custom top bars" for their apps for a while now.
Fine by me. I would rather get the original theme when I download a Qt app, as this is what it was tested for. It would look and work better than the broken mess I'm currently getting. Qt has never been able to completely fit the "look and feel" of other DEs and this is unlikely to ever change, given that KDE has a specific design and UX they like that clashes with other DEs, same as Gnome. And that's fine. You will never have a UX that makes everybody happy. At some point, people should accept this.
Also you completely ignored 70% of what I wrote... again. You didn't even address the fact you obviously had not read my post before answering and therefor made factually wrong points. Can you at least respond to this:
Why should Gnome be blamed for not being able to be adapted to the design you like, and not KDE for not doing so to the design I like? Or maybe we shouldn't try to blame anyone and just accept different preferences and let different designs coexist?
Preisschild@reddit
Also see Rewaita
https://flathub.org/en/apps/io.github.swordpuffin.rewaita
Kevin_Kofler@reddit
That is just recoloring, not theming.
Kevin_Kofler@reddit
A color scheme is not a theme. Making controls look like Breeze, like Windows 11, like macOS, like Windows 95, like Motif, or in some new original design is. But libadwaita restricts even color schemes.
Isofruit@reddit
The counterpoint here would be that the Kirigami version is "busier" than the Gnome version. Your eyes get pulled to the green shut down button, the blue app icon, the center and the bottom, where you have a red-accent also being eye-catching.
The only important thing is the center though, with the rest supposedly being there for to focus on when you need it, not the rest of the time.
The titlebar takes scree-space away from the important things with little benefit I can see and all it does is add buttons I do not need and a mildly eye-catching distraction in the top-left corner in the form of the app-icon.
Objectively correct. In this case the center of the libadwaita version is badly styled, entirely agree. I'm not fully convinced they couldn't have done away with some of the padding, seeing as they weren't following Gnome's HIG anyway. But the density in this case on the KDE side is absolutely an improvement.
Libadwaita allows the exact same (I believe the Widget ist AdwOverlaySplitView), if they had bothered to use it. Bazaar famously does this for their download-section on the right-hand side.
somethingrelevant@reddit
Sorry but, what. It adds one extra button (the pin) and every other element is there in the GTK version as well, even the "eye-catching distraction" in the top left corner
Preisschild@reddit
A huge downside imo
Better-Quote1060@reddit
I use kde
That's upgrade for me...sorry gnome users
Now the app feels perfect in my desktop like it's part of it
Tough-Smile8198@reddit
I have a KDE install on my second disk, and it looks dog shit.
Interesting_Put8754@reddit
Yeah it does but how don't most apps on Gnome look like dogsh*t and inconsistent DS at that? There's no way even half the apps you use are libadwaita.
Tough-Smile8198@reddit
Everything I use is Libadwaita besides Firefox, Gnome-disks, Spotify, Telegram and some other apps. 90% of apps are Libadwaita, idk what you talking about.
Better-Quote1060@reddit
Ui itself is eh..but it now shows in status bar witch made way more comfy insted of just disappering not knowing if it's running or not
ZuraJanaiUtsuroDa@reddit
Indeed and now it looks amateurish and out of place on my system. Doesn't feel like an upgrade to me. Plus I got no sound when using the flatpak at the moment but that's not UI related.
In the end the author does whatever he wants with his app. If he's happy with his decision and brings joy to KDE users, then kudos to him. He's the one doing all the work after all.
People can fork it if they really care about Libadwaita.
Epsilon_void@reddit
In what way is it amateurish?
oh no, that must suck.
ZuraJanaiUtsuroDa@reddit
It looks off-putting on Gnome now. Some stuff is written in bold you don't really know why, colored icons that looks like power/close buttons look out of place to me when all other icons are monochrome. Feels like design was an afterthought.
Stuff used to be integrated in the topbar. Now there's a useless titlebar with nothing in it. People complain how Libadwaita apps usually come with a waste of space but I don't know what I gained by losing \~40 pixels at the top of an app that now looks exotic on my computer.
It's hard/impossible to please Gnome users with QT apps and KDE users with Libadwaita apps. It's a good day for KDE users.
Tough-Smile8198@reddit
Man, I thought EasyEffectsin fact made this change to look better, infact it looks even worse now, with glitches one every corner of the application. Awesome decision!
ExaHamza@reddit (OP)
This is the first release after being completely rewritten with a new toolkit; if you don't pay a penny and don't even contribute with patches, at least give the project some productive feedback or shut up.
Tough-Smile8198@reddit
Lol the original worked just fine, what was the point of releasing a new QT version if that shit just made it work worse and get a glitchful experience?
FryBoyter@reddit
https://github.com/wwmm/easyeffects/issues/3521
https://github.com/wwmm/easyeffects/blob/master/CHANGELOG.md#800
The two links should be a little more informative than just the link to the project itself.
abbidabbi@reddit
And here are some screenshots from before and after the GTK->Qt transition:
Before:
https://github.com/wwmm/easyeffects/blob/v7.2.5/README.md
After:
https://github.com/wwmm/easyeffects/blob/v8.0.0/README.md
AnsibleAnswers@reddit
TBH, the libadwaita version is bad. Not because libadwaita is bad, but because the developer didn't make use of its features (e.g. full sidebar that integrates into the headerbar). The QT version looks pretty terrible, too. It fits right in with other terrible looking QT apps, though.
Tough-Smile8198@reddit
At this rate, I can just uninstall EasyEffects. As a GNOME user, EasyEffects looked terrible, but now it is just even worse.
IC3P3@reddit
That's how I see that change as well. I don't know what the goal with it was, but now it doesn't only feel bad because of unused features, but it also looks bad because it looks and looks like software stuck in 1990 or something
Unclear-Direction@reddit
While I agree with the fact that the libadwaita version is "bad", it's obviously better than the Qt version.
The Qt version is worse in pretty much every respect from those screenshots.
ZuraJanaiUtsuroDa@reddit
It really hurts the eyes on Gnome now.
myoldacchad1bioupvts@reddit
Use case for eyes?
Zettinator@reddit
Yeah, it had a confusing user interface before and now it's even worse. In particular the two nested tab bars top and bottom aren't great. And with the Qt version you cannot recognize visually how it's supposed to be nested anymore.
Overall, Qt/KDE apps have a far worse track record when it comes to visuals and overall consistency of the user interface. Qt just suffers from development sprawl. There's a few high level component libraries that are competing (Kirigami isn't the only one), there are apps that use basic Qt Quick Controls that ship with the framework, then there are apps that use custom Qt Quick based UIs and finally the old widgets are also still in wide use.
iCapa@reddit
it looks so much worse, nice
abbidabbi@reddit
The biggest problem IMO is the extensive usage of frames within frames, which KDE Plasma for example has removed for the most part in its past releases. And then there's the issue with font sizes, as well as UI element paddings, which makes it look bad.
But considering it's their first release after a GUI toolkit change, this isn't too bad.
Kevin_Kofler@reddit
That is not an issue, it is an improvement. Much more efficient space use.
abbidabbi@reddit
I was not comparing against the Adwaita design choices and the love for wide gaps, which is indeed non-ideal.
Have a look again at the frequency numbers or the "Hz" unit text at the top. Or the buttons which have uneven sizes/widths and are thus "GUI-noisy".
Talking about noise, see the font sizes on the second screenshot. They are all over the place, with additional colors and weights too. I can count at least 6 different font styles, maybe more.
DankeBrutus@reddit
I like the coloured volume levels at the top much more than the white bars.
Dminik@reddit
It looks much more usable. Nice.
ExaHamza@reddit (OP)
Thank you!
Cuwute_@reddit
Idk i think it doesn't matter i use it only to set up custom configuration for my headphones.
CleoMenemezis@reddit
No disrespect to the project, but the UI is still bad. In both GTK and QT, the UI is cluttered and feels out of place.
The dev has its motivations and that's fine, I just hope it makes use of what QT offers as opposed to what it did with GTK/Libadwaita.
Astrinus@reddit
I'd say the UI is not cluttered at all. It has its functionality right out there.
I'd take it anytime over any dumbed-down application with only two giant buttons and a text field, with extremely limited functionality because "users are stupid", or switching between 25 dialogs/panes/tabs whatever each time I need to do something. Density is good.
MessyMuryokusho@reddit
ah yes the classic "not to be that guy" then proceeds to be "that guy"
ExaHamza@reddit (OP)
talk is cheap send patches
DeadlyGlasses@reddit
Or you do it? I love KDE and open source and all but asking users to send patches means you have zero interest in developing your own software or making it better. You just want something for yourself which is not an issue but then why are you even posting your software if you don't want it to be used by anyone?
Why are you even posting this here if you think talk is cheap?
Ontological_Gap@reddit
Send patches
ExaHamza@reddit (OP)
He's not an ordinary user. He's a prominent GNOME developer who never contributed to easyeffects, but mysteriously now appears trashing the project. If he thought the project was ugly even before the rewrite, why didn't he contribute when he was capable? And why is he only now exposing this?
CleoMenemezis@reddit
I have never contributed to GNOME Shell; I only contribute very little to a few projects that I use in my day-to-day life. I have only published 2 small GTK programs.
I want to make it clear that I did not mean to disrespect the project or you as a person. I emphasized this in my original comment, and I’m sorry if you felt attacked.
My intention was simply to share my opinion on the interface and suggest improvements, utilizing the resources that the KDE tool offers for the UI. I was not criticizing how the application works—which, by the way, is excellent, and I have used it. I wasn't trying to undermine your project. To be honest, I didn't even know that the author of the publication was the maintainer, who, in this case, is you. Therefore, my comment was not directed at you.
I apologize if you felt that I offended you or your project. It was merely an opinion as a user, not as a developer.
QuickSilver010@reddit
Classic QT W
Kevin_Kofler@reddit
This is Kirigami, not QtWidgets (which is what I would call "classic Qt"). Also, it is spelled "Qt", not "QT".
Jegahan@reddit
I don't think they were talking about QtWidgets. Saying something is a "W" (said double-u) means its a "win". They probably just meant "this is a win for Qt".
Isofruit@reddit
Does this make you feel old because you're explaining slang, or young because you're with the crowd enough to still know what that slang means :-P ?
Jegahan@reddit
Right in the middle XD
blackcain@reddit
The easy effects maintainer has every right to move to whatever makes their job easier to maintain their code sustainability and if QT+KDE Frameworks is where it is then that's great. They should thrive. Pick what you need for your project to thrive.
Isofruit@reddit
Full agreement here. The more FOSS, the better. What ticks me off is that every, and I mean every opportunity must be taken by the peanut gallery to immediately crap all over their perceived enemies in the open source community. For a huge chunk of this thread, it's impossible to just be "This is nice, dev did a decision they like". It must be "This means that GTK/Gnome bad!". That I take offense with.
lh6205@reddit
Who need this bloated app if you can have PipeWire filter chain where you can add ladspa/lv2 plugins and create ultimate config with minimal overhead. EasyEffects can work only with two channels, meanwhile i have PipeWire Virtual Surround sink 7.1 with custom recorded Atmos.wav file with Ladspa audio compressor and with PW build in parametric EQ pimped for my HD 600 headphones :)
Zettinator@reddit
Indeed, EasyEffects is overengineered and the UI is quite bad. Might actually a good idea to make a better/simpler app for the common use cases.
n3onfx@reddit
Love the app itself and I use it extensively, the UI looks way worse now imo but looks doesn't really matter for something that spends 99% of the time running in the background once setup is done.
selar4233@reddit
Hopefully this isn’t the final version. It looked better before.
ExaHamza@reddit (OP)
It took a long time to reach that level, so let's give the project the proper feedback and time to see what happens in the long term.
InfiniteSheepherder1@reddit
Wow all that effort to make it look worse.
Preisschild@reddit
Honestly I agree with you. I liked the CSD tabs / buttons. Now its just default qt wasted space.
Kevin_Kofler@reddit
Except it actually uses less space overall even without cramming the toolbar into the title bar (to the extent of not even showing the actual title anymore).
Isofruit@reddit
Which is pretty much solely because of the center, which could be styled more space efficiently and was done better in the QT version, I entirely agree.
Fairly sure this could've also been done better by the devs while using GTK/Libadwaita, they just didn't do it.
uksiev@reddit
let's fucking go, honestly fuck gnome and libadwaita
unixmachine@reddit
That's wonderful, I remember when they ported it to libadwaita, people didn't accept it very well. Before, the app was called PulseEffects and used GTK3, which was usable in KDE environments.
One point that I think influences the change is that KDE has grown in market share due to the gaming community, which tends to use KDE because it has more established features and is more visually similar to Windows. Therefore, it makes sense to make your application more visually appealing to the majority of users.
Kevin_Kofler@reddit
Probably also because Valve uses it.
TRKlausss@reddit
I don’t know if this change is so positive. I use Qt in a professional environment, and we are getting bombarded with CVEs…
Can anyone shed a light on why they decided to switch?
stevecrox0914@reddit
Any framework will have vulnerabilities good security practice has the franework offering bug bounties to find them and release a CVE once a fix is in place (unless its a zero day).
Similarly popularity will drive a huge amount of CVE's being found and listed.
This is why pretty much every development process needs an automated dependency update tool and a CI pipeline to validate the update doesn't break. This should be business as usual.
Lastly there is a great question on what the CVE is.
Spring Framework is actually a really great example of living with this, within weeks a release will have all sorts of CVE's. Those CVE's will be focussed on an configuring an old legacy function in a highly non standard way and then misconfigure new service so an attacker can send a payload to get access.
Spring will fix one of them, security will require you to update and round and round we go.
Libadwaita won't be any less secure but its much less used than QT (e.g. qt is in things like car infotainment) so people havent gone looking to the same degree.
TRKlausss@reddit
You are not wrong, CVEs can be everywhere, although it should already be known that memory safety is a huge advantage against them.
Also, it feels like you are trying to do advertisement for your tool… Which I don’t think is either relevant or desired in this context.
Kevin_Kofler@reddit
As for memory safety, GTK (C) is not any memory-safer than Qt (C++). I would even argue that C++ makes some classes of memory bugs harder to accidentally trigger than C (though not impossible, obviously, given that anything that can be done in C can also be done in the same C way in C++).
Kevin_Kofler@reddit
Spring Framework is not one the commenter's tool, it is a popular Java framework mainly used for web applications.
stevecrox0914@reddit
Spring Framework is a framework in Java with hundreds of contributors that was first released more than 2 decades ago and literally defined a chunk of the Java programming language.
Its basically a set of libraries for presenting a web service or communicating with any kind of endpoint. Its why I won't embrace Panda or Data Frames because Spring solved manually writing SQL decades ago.
I use it as an example because its a similar size and complexity to QT.
If your a developer its good to look at the most popular frameworks for various languages so you can figure out the best tool for a job.
KnowZeroX@reddit
Qt has far more users, do remember Qt is commonly used not just on linux but on windows, mac, android, ios, and all other kinds of platforms. So when your goal is cross compatibility, it isn't uncommon for there to be CVEs on some platforms. That doesn't mean it is any less secure overall.
FryBoyter@reddit
I think an important reason, if not the main reason, is likely to be https://github.com/wwmm/easyeffects/issues/3521#issuecomment-2589990536.
Nereithp@reddit
To my understanding, the main author's personal preferences in regards to the "direction in which GTK is heading". Perhaps something in GTK was making it difficult for him to implement desired functionality, but this is just speculation.
the_abortionat0r@reddit
Loving the change.
oiledhairyfurryballs@reddit
That’s a real shame that they did that. And it’s not a good rewrite too. They essentially changed nothing but the library, which means it’s now an app designed with GTK in mind but in QT. The design does not look good with QT.
ThatOneShotBruh@reddit
I agree, but hopefully this is only the first step in the transition.
dddurd@reddit
Gtk2 would have been also an upgrade. But good upgrade nonetheless. Gtk4 is really bad.
jashAcharjee@reddit
Thank god finally. I hated the GTK shit look, bigger padding and non-PC oriented user interface
Sunimaru@reddit
As an everyday Easy Effects user on KDE I really like this and look forward to the new version hitting the repos. I also don't agree with the people complaining about the looks. The new version looks perfectly fine to me, maybe even better than the old one.
rx80@reddit
Awesome work, love the app, love the Qt rewrite.
ShadowFlarer@reddit
I don't have a strong opinion on the whole gtk vs qt thing, but EasyEffects is a really good app that i use everyday so i'm happy to get a update.
Severe-Divide8720@reddit
Definitely taking a look as a music person and a KDE user. Sounds great.