#351 Reconsider use of adwaita-qt
Closed: Fixed 6 months ago by aday. Opened a year ago by catanzaro.

We've received complaints from many users about the adwaita-qt theme breaking apps (examples). Nowadays GNOME has been heavily discouraging custom themes. Upstream developers do not test their applications with adwaita-qt. It's good for adwaita-qt to remain available, but I'm no longer confident that it's an appropriate default for Fedora Workstation.

CC @jgrulich


Metadata Update from @catanzaro:
- Issue untagged with: meeting

a year ago

All those examples are KDE core apps using KColorScheme that override our styling and causing a color mismatch in some cases.

There is a potential upstream fix for this issue: https://invent.kde.org/frameworks/kconfigwidgets/-/merge_requests/94

This is not really Adwaita-qt fault and I also don't expect many people use KDE core apps on GNOME.

Edit: Btw. I tested the fix and it works.

This is not really Adwaita-qt fault and I also don't expect many people use KDE core apps on GNOME.

NeoChat is a KDE core app that I expect people would use on GNOME, since GNOME still doesn't have a good Matrix client yet.

This is not really Adwaita-qt fault and I also don't expect many people use KDE core apps on GNOME.

NeoChat is a KDE core app that I expect people would use on GNOME, since GNOME still doesn't have a good Matrix client yet.

NeoChat is QML based, isn't it? Adwaita-qt is only for QWidget based applications.

There is a potential upstream fix for this issue: https://invent.kde.org/frameworks/kconfigwidgets/-/merge_requests/94

I backported the fix to kf5-kconfigwidgets package. We should no longer see issues like those mentioned in the blog post posted in the first comment. The fix will be part of KF5 5.101 update that will soon get into F37 and F36.

In general I agree that adwaita-qt isn't necessary - I don't think that qt apps benefit from being restyled to match adwaita, and the quality of the theme is often going to be lower than the original styling.

My one question here is Fedora Media Writer - is that using adwaita-qt? How would it be affected if we dropped adwaita-qt?

In general I agree that adwaita-qt isn't necessary - I don't think that qt apps benefit from being restyled to match adwaita, and the quality of the theme is often going to be lower than the original styling.

My one question here is Fedora Media Writer - is that using adwaita-qt? How would it be affected if we dropped adwaita-qt?

It does use the library part of Adwaita-qt. But if we drop Adwaita-qt, I don't think we are actually going to remove it as a package so it will be still available and the only change would be in QGnomePlatform to default to a different Qt style.

adwaita-qt is buggy and provides bad user experience with misaligned menus, missing titlebars, blinking titlebars, missing shadows, etc. and sometimes even crashes. It feels like Fedora-specific downstream hack with low quality, causing very bad UX in upstream-driven distro like Fedora.

adwaita-qt is buggy and provides bad user experience with misaligned menus, missing titlebars, blinking titlebars, missing shadows, etc. and sometimes even crashes. It feels like Fedora-specific downstream hack with low quality, causing very bad UX in upstream-driven distro like Fedora.

I think you are not talking about Adwaita-qt, but about window decorations provided by QGnomePlatform? Misaligned menus was a bug in QtWayland that has been fixed. I have not seen any issue with missing or blinking titlebars, can you point me to a bug report? Also QGnomePlatform already has shadows support. The crash you are talking about was happening once when I missed to rebuild QGnomePlatform for a QtWayland update, as QGnomePlatform is using private API. Btw. have you seen default Qt window decorations that you are talking about "downstream hack with low quality"?

In general, we don't have a good pipeline to get feedback from users to contributors (especially when so few of our members actively engage with users). So I think the underlying pretense of this ticket is flawed. In general, I'd rather keep Adwaita-Qt and QGnomePlatform. Without it, at least some of the applications I have to use for work look awful/broken on GNOME.

Without it, at least some of the applications I have to use for work look awful/broken on GNOME.

Which apps? Why do they look bad without Adwaita-Qt and QGnomePlatform?

I agree with the issue, but I'd also add QGnomePlatform. I've also seen people complain about Qt apps being broken on GNOME, without realizing it was caused by downstream, for example https://www.reddit.com/r/Fedora/comments/zfcn3c/comment/izdkwnm/?context=3. This is one example, but I've seen many people complain about this subtle change by Fedora that easily misleads the user, including myself. I was under the impression that GNOME made this change when I first ran into this issue, until I checked online. I was really close to bother the GNOME developers about this.

Without it, at least some of the applications I have to use for work look awful/broken on GNOME.

I'm not sure what you mean by broken. If by "awful" you mean not being integrated and larger cursors, then fair enough. I never ran into issues with stock GNOME, even with KDE apps under Flatpak. To be honest, I prefer themes that don't integrate with the desktop than themes that literally make the app unusable. I was unfortunately one of the victims who wanted to test something with Qt apps, but was blocked with Adwaita-Qt/QGnomePlatform's bugs and wasted half an hour figuring out what caused it by learning Qt platform themes and such. The solution was to remove QGnomePlatform.

Since QGnomePlatformTheme is CSDs, perhaps we could use libdecor? Inochi Creator flatpak uses libdecor, which replaced the SDL titlebar with GNOME's.

There is no reason why QGnomePlatform should be removed, I agree that Adwaita-qt style is not perfect, because writing a QStyle is hard and complex, but QGnomePlatform, besides CSD implementation, doesn't change anything UI-wise. QGnomePlatform is the only platform theme that can read GNOME settings from both GSesttings and xdg-desktop-portal and apply it to Qt apps, it provides native file dialogs and as mentioned provides CSD, as the only CSD implementation in Qt is super basic and ugly. Btw. I plan libdecor support in QGnomePlatform so CSD will be improved. If we decide to not use Adwaita-qt by default, then it's just a matter of changing the default in QGnomePlatform.

If we decide to not use Adwaita-qt

As of now, running either

rpm-ostree override remove (lib)adwaita-qt5

reveals that qgnomeplatform-qt5 has both libraries as dependencies. Can this be situation be improved upon?

No, because Adwaita-qt is currently used to implement CSD. We can do that later when libdecor is used instead. It is also needed for Fedora MediaWriter.

I've asked several GNOME developers for their opinions on Adwaita-qt and it seems that consensus upstream is that distro themes are bad, this basically.

That said, it does look like a pretty nice theme IMO. Perhaps we could promote it as an option that users could select themselves to use for apps that they have tested it with? The problem isn't that it's available, but that it's default and users who don't know about it are not going to wind up with the user experience intended by upstream developers of Qt apps.

If we decide to not use Adwaita-qt by default, then it's just a matter of changing the default in QGnomePlatform.

This seems like a good plan to me. I'm not really seeing any strong reason to get rid of QGnomePlatform? @theevilskeleton what precisely is the problem you found with it?

I supposed I misunderstood the behavior of QGnomePlatform, as I thought it was Adwaita-Qt and QGnomePlatform that caused apps to break. My apologies and thanks @jgrulich for clarifying.

That being said, I support shipping QGnomePlatform, as long as it doesn't break any apps. libdecor support would be even better.

Metadata Update from @catanzaro:
- Issue tagged with: meeting

a year ago

@jgrulich I've scheduled this for discussion at the next Working Group meeting, (join instructions for if you wish to attend).

@jgrulich I've scheduled this for discussion at the next Working Group meeting, (join instructions for if you wish to attend).

I would like to join, but I'm unfortunately not available at that time. I can provide you information what it would require to make Adwaita-qt as non-default style. Is there anything else you would like to know so I can provide you necessary information?

I would like to join, but I'm unfortunately not available at that time. I can provide you information what it would require to make Adwaita-qt as non-default style. Is there anything else you would like to know so I can provide you necessary information?

That seems like enough, thanks.

By the way, I can reschedule this discussion for a different week if you prefer (but not a different time).

I would like to join, but I'm unfortunately not available at that time. I can provide you information what it would require to make Adwaita-qt as non-default style. Is there anything else you would like to know so I can provide you necessary information?

That seems like enough, thanks.

1) We will need to keep Adwaita-qt as part of Fedora Workstation for Fedora Media Writer and QGnomePlatform. FMW depends on it because the only alternative style for Qt6 is currently Fusion and that is not really visually appealing + it doesn't have dark equivalent. And QGnomePlatform depends on it for its CSD implementation.

2) I can patch QGnomePlatform to make it to use Breeze/Breeze-Dark instead of Adwaita-qt/Adwaita-qt-dark. That's an easy thing to do. Even with this, we will still have Adwaita-like decorations (from QGnomePlatform) as the only available decorations in Qt are called Bradient and they are super basic, we really don't want to use these. I plan to implement support for libdecor which will remove Adwaita-qt dependency and bring our CSD implementation to the next level.

3) Problem is that in order to use Breeze style, you need to install some KDE Frameworks as dependencies. This is a no-go for shipping it by default in Fedora Workstation. I also think it's not pulled in when any KDE app is installed and most certainly will not be pulled in when a pure Qt app is installed (like Wireguard). This will be problematic and I'm not sure what to do about it. From our side (KDE SIG), we definitely can make plasma-breeze (Breeze style) installed together with some essential KDE Framework, but what to do with pure Qt apps? Do we want to use Fusion style in such case by default and not Breeze?

By the way, I can reschedule this discussion for a different week if you prefer (but not a different time).

It won't help, I'm not available every Tuesday around this time.

Neal is planning to argue that we should keep adwaita-qt and that the situation with nonstandard Qt themes is not comparable to the situation with nonstandard GTK themes. I'll assign this issue to him for now, and he will provide an argument later.

Metadata Update from @catanzaro:
- Issue untagged with: meeting
- Issue assigned to ngompa
- Issue tagged with: pending-action

a year ago

Just to add a few cents here. The Qt integration stuff is also important for various accessibility situations, so we need to keep that part of it going regardless of any other change we want to make. Theming isn't just about color palettes here, but also about ensuring that when a user enables an accessibility setting under GNOME it also applies to their Qt applications as far as we can achieve it.

I'm afraid that it still isn't clear to me why we are restyling Qt apps to make them look like GNOME apps...

For one, it isn't clear to me what the actual target apps are for adwaita-qt. The most popular Qt apps, like Telegram, KDenLive and Krita all come with their own styling, and aren't affected by adwaita-qt. You have to go a way down the list of most popular installed apps before you encounter a Qt app which is affected by adwaita-qt. The most popular examples I can find there are QBittorrent (ranked 123), QDBusViewer (ranked 162) and Okular (ranked 186). (For reference, Dolphin is ranked 436 and Kate is ranked 584.)

Are we so concerned about the appearance of these specific apps that they need restyling? There are plenty of other more popular apps which don't have Adwaita styling, and I don't see anyone losing sleep over it.

Then the fact is that these apps don't look as good with adwaita-qt as they do with Breeze (or whatever the default Qt theme is). Even a cursory examination shows various UI issues that show up. So we are going to the effort of including adwaita-qt, only to make these small number of relatively infrequently used apps look worse than they did to begin with?

Sorry for keeping on about this - I'd just like to understand. If someone could explain that would be great. Also, I know that we're discussing other peoples' work here, and I'm sorry if this discussion is in any way hurtful. I have nothing but respect for all the people involved.

Generally speaking, unlike GTK, Qt is designed such that applications need to handle what the toolkit tells it to do per the platform. If an application doesn't provide a theme of its own, then it inherits what the platform plugin sets.

For Linux, unless the platform plugin sets a theme, you get a very ugly default that provides an even worse experience. It also doesn't work properly in GNOME because it makes different assumptions about the desktop environment.

QGnomePlatform sets Adwaita-Qt as its basic theme and uses it to provide a number of basic capabilities: a functioning CSD that integrates with GNOME, a visual style for prompts and windows that somewhat fits with the GNOME experience, and so on.

It doesn't stop applications from shipping their own theme on top, just like how GNOME applications clobber the set theme for GTK to force Adwaita on other desktops. But what it does do is ensure that things the application doesn't handle will be handled properly in the GNOME environment both visually and technically.

For Linux, unless the platform plugin sets a theme, you get a very ugly default that provides an even worse experience. It also doesn't work properly in GNOME because it makes different assumptions about the desktop environment.

I'm not sure how it can possibly be worse here, when some apps are literally unusable with Adwaita-qt. I, and frankly many others, would much rather have "ugly" looking apps than unusable apps.

It doesn't matter which toolkit themes better. What matters is how much making changes affects the people who use them unknowingly. Presumably, this affects a large chunk of Fedora users.

I wasted 30 minutes to an hour just to figure out that the issue wasn't the apps breaking on GNOME, but Adwaita-qt. I'm well versed with the risk of theming, so I managed to figure out what the problem was, which I highly doubt many people would even know where to begin. Many people take things at face value, so they will believe that the problem is the app and/or GNOME, without really thinking about theming, especially when Fedora is regarded and praised to offer a "vanilla GNOME experience".

I disagree with calling apps running Adwaita-qt as unusable and I believe you are exaggerating. There was a bug in kf5-kconfigwidgets that has been fixed in our packages and the issue where mixed dark/light theme was used shouldn't happen anymore. Is there any other issue that makes Adwaita-qt unusable at this point?

Last time I opened Fedora media write a button simply didn't have label and appeared as a 5x5 px square, so yeah it is quite unusable.

Last time I opened Fedora media write a button simply didn't have label and appeared as a 5x5 px square, so yeah it is quite unusable.

FMW doesn't use Adwaita-qt and the issue you have (if you have it with current FMW) is a FMW issue.

I disagree with calling apps running Adwaita-qt as unusable and I believe you are exaggerating.

My apologies, for the lack of clarity. I didn't mean that every single app is automatically unusable when Adwaita-qt is applied. I meant to say that an app breaking with Adwaita-qt is a lot more harmful than apps looking "ugly," as it leads to heavy accessibility and usability regressions.

There was a bug in kf5-kconfigwidgets that has been fixed in our packages and the issue where mixed dark/light theme was used shouldn't happen anymore. Is there any other issue that makes Adwaita-qt unusable at this point?

The problem is its chance of breaking apps in the foreseeable future, not whether there was a bug that was later fixed, or that there is no bug that is pointed out in the present. Developers generally test Qt with Breeze on Plasma, not with Adwaita-qt (and especially not GNOME). It doesn't really matter if I report bugs right now, because, chances are, many users ran into issues with Adwaita-qt that wouldn't otherwise get on Breeze, but don't really know how/where to report the bug and where to begin troubleshooting. Or, regressions can occur when an app updates at a random time.

Again, Fedora is praised to provide a near-vanilla experience; shipping a custom theme that increases the chance of breaking apps in the future can legitimately lead to wasting upstream developers' time and users believing the issue is with the desktop environment, and not by the fact that the distribution subtly ships a custom theme. Worst of all, this can literally ruin the user experience, as less knowledgeable users can't use their apps anymore.

I admit that I am genuinely irritated by this, as, like said plenty of times, I wasted 30 minutes figuring out the problem when I wanted the app to just work™. I apologize for being an ass.

Again, Fedora is praised to provide a near-vanilla experience;

People assume Fedora ships a vanilla experience. We very deliberately do not. We are Fedora, not GNOME. It is true that GNOME makes a number of good decisions. But they also make a number of not-so-great ones. And sometimes the apps they offer aren't very good either.

That's why we use Firefox as our default browser, and why we may actually ship Thunderbird in the future. It's why we have our own wallpaper and ship the logo overlay extension. It's why I'm pushing for shipping the appindicator extension in Fedora (it missing is easily the number one complaint people have about GNOME and Fedora Workstation).

Fedora Workstation intends to provide a cohesive and integrated experience. It's not intended to ship a GNOME desktop experience. It's intended to ship a Fedora Linux desktop experience.

There was a bug in kf5-kconfigwidgets that has been fixed in our packages and the issue where mixed dark/light theme was used shouldn't happen anymore. Is there any other issue that makes Adwaita-qt unusable at this point?

The problem is its chance of breaking apps in the foreseeable future, not whether there was a bug that was later fixed, or that there is no bug that is pointed out in the present. Developers generally test Qt with Breeze on Plasma, not with Adwaita-qt (and especially not GNOME). It doesn't really matter if I report bugs right now, because, chances are, many users ran into issues with Adwaita-qt that wouldn't otherwise get on Breeze, but don't really know how/where to report the bug and where to begin troubleshooting. Or, regressions can occur when an app updates at a random time.

Qt applications are not supposed to assume a specific theme unless they bundle one (as Telegram does). Even KDE Plasma users don't necessarily all use Breeze, and the desktop embraces and fully supports alternative themes and user experiences. So any developer making that assumption is flat out wrong.

I never said that users don't use custom themes, and I have no problem with that. Again, the majority of developers don't test their apps with Adwaita-qt, so there is a higher chance that such themes will cause problems. At least with Breeze, it's the default theme so there's a lot more focus in QA there.

Qt's default theme is not Breeze, though. That's only KDE Plasma's default theme. That's the difference between GTK and Qt.

Alright, then let me rephrase. "I never said that users don't use custom themes other than Breeze..." and "At least Breeze is the de-facto custom theme that is shipped by the most popular Qt based desktop environment."

The sentiment doesn't really make a difference, though.

The difference is that you're asserting that we shouldn't have applications fit in with our desktop environment. I'm asserting that we should.

I have far more specific thoughts about this, but at the risk of Allan slapping me again in a ticket, I'm not going to go into it anymore.

Developers generally test Qt with Breeze on Plasma, not with Adwaita-qt (and especially not GNOME).

But if Breeze depends on KDE Frameworks, then is it really an appropriate comparison? Because that's not going to be available in Fedora Workstation regardless, since we don't want KDE Frameworks installed by default. And setting Breeze would just be yet another non-default choice of theme.

Perhaps it would be better to compare adwaita-qt vs. whatever the upstream default theme really is. Could somebody please take some screenshots?

Breeze is implemented through KDE frameworks, yes.

Metadata Update from @catanzaro:
- Assignee reset
- Issue untagged with: pending-action
- Issue tagged with: meeting-request

a year ago

Metadata Update from @catanzaro:
- Issue untagged with: meeting-request
- Issue tagged with: meeting

a year ago

Metadata Update from @catanzaro:
- Issue untagged with: meeting
- Issue tagged with: meeting-request

a year ago

Posts like https://mastodon.social/@tbernard/109897404484985777 makes me think whether we should really ship Adwaita-qt by default. The thing is that Adwaita-qt gets blamed for many issues that are not really its fault, like the one in that post, because the app is QML based and we don't do any QML styling at all, but all the time Adwaita-qt gets blamed for it and people just chime in without having any clue who's fault is that. Other issue mentioned in the comments is the issue with mixed dark/light theme, but this was/is a bug in a KDE Framework and yet again Adwaita-qt gets blamed for it. There is now this "get rid of Adwaita-qt" mood in the community and I don't really want to spend my time defending it all the time. We can give the default Qt theme a try and will see how people like it. I know Adwaita-qt is not perfect and that it's also outdated compared to latest Adwaita style, because it's a project that could use a full time maintainer and unfortunately I have priorities elsewhere these days.

I'm super disappointed (but not surprised) by this attitude. System integration doesn't seem to be appreciated by the GNOME community anymore, and this rise in anti-distro attitude from GNOME developers really creates problems.

Even though @jgrulich might be tired of defending it, I won't be, because I actually care about making stuff actually work. And frankly, I'm willing to go to bat for Fedora KDE folks who are willing to go the extra mile for making Qt/KDE apps work well on GNOME because we don't have to do it.

(Oh and by the way, QGnomePlatform has little effect on Flatpak apps, which is what that guy is complaining about.)

(Oh and by the way, QGnomePlatform has little effect on Flatpak apps, which is what that guy is complaining about.)

I don't want to give up on QGnomePlatform at all, to me this is something we really need, because the integration provided by Qt is essential compared to what QGnomePlatform does. An example can be support for CSD or support for Settings portal. We can even switch dark/light theme on runtime for Qt apps through gnome-settings (obviously when Adwaita-qt is used).

It's all the negativity that goes towards Adwaita-qt with this #stopthemingmyapp movement that really makes me not to spend the extra effort on defending it.

(Oh and by the way, QGnomePlatform has little effect on Flatpak apps, which is what that guy is complaining about.)

I don't know exactly how it works but on Fedora I have QGnomePlatform installed in Flatpak apps and Flatpak apps use Adwaita-qt. I didn't do anything on my Fedora installation to make that.

The main problem with Adwaita-qt and/or QGnomePlatform is it provided bad quality of user experience, it feels not mature. No shadows on windows (windows are hard to resize) or misaligned menus, dialogs without titlebars, blinking titlebar when opening/closing menus.

IMHO This should not be part of default user experience of Fedora until it does not have issues like this.

(Oh and by the way, QGnomePlatform has little effect on Flatpak apps, which is what that guy is complaining about.)
The main problem with Adwaita-qt and/or QGnomePlatform is it provided bad quality of user experience, it feels not mature. No shadows on windows (windows are hard to resize) or misaligned menus, dialogs without titlebars, blinking titlebar when opening/closing menus.

1) No shadows and resizing issues - this is due to lack of API that was introduced in Qt6 and we had to backport it to Fedora (not Flathub though).
2) Misaligned menus - QtWayland issue, not related to any theming, but already fixed in upstream and backported to Fedora and KDE runtime in Flathub.
3) Dialogs without titlebars / blinking titlebar - I'm not aware of any issue like that and haven't seen a bug report.

Btw. with the default Qt CSD implementation you would end up with same issues, no shadows (even with the API addition that only QGnomePlatform makes use of), and way worse looking decorations.

Posts like https://mastodon.social/@tbernard/109897404484985777 makes me think whether we should really ship Adwaita-qt by default. The thing is that Adwaita-qt gets blamed for many issues that are not really its fault, like the one in that post, because the app is QML based and we don't do any QML styling at all, but all the time Adwaita-qt gets blamed for it and people just chime in without having any clue who's fault is that. Other issue mentioned in the comments is the issue with mixed dark/light theme, but this was/is a bug in a KDE Framework and yet again Adwaita-qt gets blamed for it. There is now this "get rid of Adwaita-qt" mood in the community and I don't really want to spend my time defending it all the time. We can give the default Qt theme a try and will see how people like it. I know Adwaita-qt is not perfect and that it's also outdated compared to latest Adwaita style, because it's a project that could use a full time maintainer and unfortunately I have priorities elsewhere these days.

The real problem is when distributions push significant changes that affect apps in ways that are not (cannot be) tested by app developers. In this particular case the apps are neither tested with adwaita-qt nor the default qt style so i don't think there is any good solution, one can argue that at least adwaita-qt has been extensively tested by Fedora users.

It might be a good idea to have a resource explaining people like me where exactly theming begins and ends in QT, having bad press around adwaita-qt does not help anyone, specially if it is done in a way that's not accurate.

Scheduled for next week's meeting, Tuesday, March 14 at 10:00 AM EDT (14:00 UTC). Join link

Metadata Update from @catanzaro:
- Issue untagged with: meeting-request
- Issue tagged with: meeting

a year ago

Attaching comparison of Wireshark in Fedora Workstation vs. KDE provided by GNOME community. Notes:

  • broken hover
  • too dimmed links at the bottom
  • not dimmed placeholders in entries

wireshark.png

Note on Fedora media writer: the screenshot above is with a fully-updated Fedora 37 system. If you instead install Fedora 37 fresh and do not apply updates, then you get Adwaita-style window decorations instead of the Qt-style decorations. Wonder why that changed.

Note on Fedora media writer: the screenshot above is with a fully-updated Fedora 37 system. If you instead install Fedora 37 fresh and do not apply updates, then you get Adwaita-style window decorations instead of the Qt-style decorations. Wonder why that changed.

Fixed recently: https://bugzilla.redhat.com/show_bug.cgi?id=2174905

For comparison, I've tested some of these apps on Ubuntu, which doesn't seem to have adwaita-qt.

Those screenshots were taking using the Ubuntu live session, which uses X11. If I use a Wayland session, and force those apps to use Wayland, then the window decorations use a different style and icons, and don't have window shadows.

gwenview-wayland.png

kate-wayland.png

@jgrulich has written a really helpful post explaining the different aspects of what's being discussed here - https://jgrulich.cz/2023/03/08/explained-qgnomeplatform-and-adwaita-qt/

Some possible suggestions for QGnomePlatform:

  • Default theme should be Fusion rather than Adwaita-qt.
  • Icon theme changes seem to break icons in some apps (e.g. PlasmaTube). Investigate and resolve or else stop changing the icon theme.
  • Implementation of dark mode seems to break apps that do not expect to be dark, e.g. dark text or dark icons on dark background. Dark mode probably needs to be handled on an opt-in basis so it only affects apps that are prepared for it; it's fine if that means Qt 5 apps are never dark. I'm not convinced it makes sense to mess with color scheme at all, but if we do, need to be confident we are not responsible for dark on dark colors.

I showed your blog post to the GNOME community and some are complaining about basically everything QGnomePlatform does, but I would prefer to focus on the parts that we know cause breakage.

I showed your blog post to the GNOME community and some are complaining about basically everything QGnomePlatform does

There were only ~3 people in that discussion, and most of them seemed to agree that the native dialogs and window decorations make sense.

I showed your blog post to the GNOME community and some are complaining about basically everything QGnomePlatform does

There were only ~3 people in that discussion, and most of them seemed to agree that the native dialogs and window decorations make sense.

You would get most of the settings applied anyway, because the built-in QGtk3 platform theme in Qt does the same, the only difference in QGnomePlatform in this regard is that it can get it also from the Settings (xdg-desktop-portal) portal. I'm also now going to be 100% confident when I say that you don't really want to use default decorations provided by Qt, there is literally zero benefit doing so. Yes, the decorations in QGnomePlatform are not 100% copy of Adwaita, but it's close enough. Not to mention the support for shadows, that it can match your titlebar button layout etc.

Nicolas Fella from KDE also wrote about this topic, which can also further help you and members from GNOME community to better understand how Qt integration works. You can read it here: https://nicolasfella.de/posts/how-platform-integration-works.

Hi, I have created a repo [1] with a fix in KConfigWidgets framework (KColorSchemeManager) that allows us to set custom color scheme from QGnomePlatform and with a fix in QGnomePlatform that installs a set of adwaita-like color schemes and makes KColorScheme to use them based on the system theme, to match all the colors with Adwaita. This should fix issues for all the KDE apps like Kate, Dolphin, Konsole etc.

Please test it and let me know whether it helps.

[1] - https://copr.fedorainfracloud.org/coprs/jgrulich/Qt_and_GNOME_integration/

I'm super disappointed (but not surprised) by this attitude. System integration doesn't seem to be appreciated by the GNOME community anymore, and this rise in anti-distro attitude from GNOME developers really creates problems.

This is not a constructive comment

Discussed today and agreed:

  • Color scheme issues in KDE apps are probably fixed in QGnomePlatform
  • QGnomePlatform will stay
  • adwaita-qt will be replaced by another style because it is too much effort to maintain (regardless of desirability of matching GNOME style). Replacement not yet determined.
  • Icon theme issues remain; Jan to investigate

Adding pending-action tag for Jan and Neal to agree on a proposal for an alternative style to replace adwaita-qt. I think Fusion looks like a good choice, but Neal really does not like this theme.

Also: adwaita-qt to remain installed by default (but no longer used as default application style) because it's required by QGnomePlatform to draw the window decorations and also required by Fedora Media Writer. That will remain.

Metadata Update from @catanzaro:
- Issue untagged with: meeting
- Issue tagged with: pending-action

a year ago

@jgrulich and @ngompa - reminder that you have a pending action item here. Personally I think that Fusion looks decent, and we should adopt it if an alternative isn't proposed.

We discussed this issue at last week's WG meeting (23 May 2023). We're still waiting on the alternative theme to be proposed and plan on revisiting this topic in 1 month.

Hi, I've started working on https://fedoraproject.org/wiki/Changes/NoCustomQtThemingForWorkstation. This is supposed to actually get rid of (to be used by default) QGnomePlatform and Adwaita-qt from Fedora Workstation and rely on Qt upstream. I would appreciate any feedback you might have to this document before I send it officially for approval.

Metadata Update from @catanzaro:
- Issue assigned to jgrulich

10 months ago

Metadata Update from @aday:
- Issue set to the milestone: Fedora 39

10 months ago

IMHO, Fedora GNOME/Workstation should default to Adwaita-qt for all Qt applications and Fedora KDE should default to Breeze-gtk for all GTK applications. Applications should not look like from another planet by default.

Breeze-GTK for GTK applications in Fedora KDE will continue for as long as reasonably possible. I prefer having applications look more like they belong on the system, regardless of toolkit.

I would like to continue it for Qt applications on Fedora Workstation too, but there are really only two paths for making that happen:

  • Update QGtkStyle to support GTK 3 and GTK 4
  • Additional contributors to Adwaita-Qt to update it and help maintain it

I have hope for the former, but nobody seems to be interested in the latter, especially with how negative the GNOME community has been around Adwaita-Qt.

I have hope for the former, but nobody seems to be interested in the latter, especially with how negative the GNOME community has been around Adwaita-Qt.

Oh noo we want to remove themes that break applications and make them way less accessible GNOME's so baaad. It's not as if theming will always be an issue, no matter how much work you put into it.

With how much the Linux ecosystem is fragmented, your "apps looking like they belong on the system" is futile in the first place. QT apps will always look out of place on GNOME, GTK apps will always look out of place on KDE, Granite apps will always look out of place on GNOME. Unless you get all the developers onto one standard toolkit and design, this is how it's going to be.

Trying to theme these apps is not the solution, and only ends up hurting end users, developers, and wasting everyone's time. More standard and generic APIs, like accent colors and the color-scheme preferences, are the way to go, and the only feasible "solution".

Breeze-GTK helps a lot in making GTK applications look less out of place in my Plasma Desktop setup. I do not use GNOME, but as far as I know, the same holds for Adwaita-Qt in GNOME, despite all the complaints. (You typically only get reports when things do not work. When they do work, the user might not even notice that they are using a Qt application to begin with.)

Color schemes are only a small part of theming. The look part goes much further, e.g., how do the buttons on scrollbars look, how do dropdowns look, etc. And then there is also the feel part, which unfortunately GTK has made less and less themable over time, first with support for C theme engines getting suddenly dropped from GTK 3 in the middle of the major release's cycle, and now with libadwaita hardcoding a lot of Adwaita behavior. Examples for feel theming are whether there are any buttons on scrollbars at all, and on which side, whether dropdowns drop just down or open a popup that can also cover the dropdown and extend above, etc. (Qt styles can actually influence several of these things by setting style hints that the core Qt code interprets.) Good integration is look&feel consistency. But even look consistency is more than just coloring.

No one is complaining about the problems that Adwaita-Qt is addressing - we already know why it exists. We're complaining about the problems it causes when it breaks apps, which is very frequent, courtesy of my article and the comments. In an ideal world, theming would be perfect and everything would work fine without breaking. But we don't live in an ideal world - the theming situation we're in is far from perfect, and by doing so we're effectively turning many perfectly usable apps into apps that users can't use. Like many of us, we would rather have "out of place" apps that at least work than literal unusable apps.

Hi, while finishing https://fedoraproject.org/wiki/Changes/NoCustomQtThemingForWorkstation, I have a remaining question. Do we want to use Breeze style when it's installed instead of Fusion style by default? I imagine Breeze gets pulled in most of the times anyone installs a KDE application.

Personal opinion: it would be nice to have KDE default theme used by default by just for KDE apps, not for all Qt apps. Imagine I install Fedora, then install first Qt non-KDE app, like SpeedCrunch. It gets Fusion. Then I install some KDE app (app using KDE libraries specifically) and this pulls KDE default theme as dependency and theme is changed also in previously installed Speedcrunch. This would be inconsistent.

Maybe installing Breeze by default in Workstation would solve this problem. But is this good idea? I feel Fusion is better default for non-KDE apps, it's just generic and 100% working correctly always. Non-KDE apps are probably not tested with Breeze, while KDE apps are usually tested and consumed with Breeze.

Personal opinion: it would be nice to have KDE default theme used by default by just for KDE apps, not for all Qt apps. Imagine I install Fedora, then install first Qt non-KDE app, like SpeedCrunch. It gets Fusion. Then I install some KDE app (app using KDE libraries specifically) and this pulls KDE default theme as dependency and theme is changed also in previously installed Speedcrunch. This would be inconsistent.

Makes sense, but no idea how to implement this on the Qt plugin level. I would have to be probably checking whether the appstream ID starts with "org.kde.*" or something like that.

Maybe installing Breeze by default in Workstation would solve this problem. But is this good idea? I feel Fusion is better default for non-KDE apps, it's just generic and 100% working correctly always. Non-KDE apps are probably not tested with Breeze, while KDE apps are usually tested and consumed with Breeze.

Installing Breeze by default would pull-in also many KDE frameworks so this is not possible.

Why is it not possible to pull in a few KDE Frameworks into Workstation? There are always a lot of GNOME libraries getting pulled into the KDE Spin.

It's a big ecosystem that we don't currently depend on. I'd prefer to draw the line at Qt itself.

I've tested Gwenview, Wireshark and Kate in F39. None of them seem to have the Adwaita styling, and they look better for it.

This was testing with the regular Fedora packages. There were some issues with the Fedora Flatpaks, but I'm not sure whether those are related or not.

Either way, I think we can close this issue. Thanks everyone!

Metadata Update from @aday:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

6 months ago

I've tested Gwenview, Wireshark and Kate in F39. None of them seem to have the Adwaita styling, and they look better for it.

This was testing with the regular Fedora packages. There were some issues with the Fedora Flatpaks, but I'm not sure whether those are related or not.

Either way, I think we can close this issue. Thanks everyone!

It's tricky with Flatpaks. I will probably keep QGnomePlatform for Qt5 there, because what I did for Fedora was to backport some Qt6 goodies to actually improve the Fusion style for Qt5 apps, but we probably won't do the same in the KDE runtime and by default the Fusion style there would not look as good as in Fedora.

I've tested Gwenview, Wireshark and Kate in F39. None of them seem to have the Adwaita styling, and they look better for it.

This was testing with the regular Fedora packages. There were some issues with the Fedora Flatpaks, but I'm not sure whether those are related or not.

Either way, I think we can close this issue. Thanks everyone!

It's tricky with Flatpaks. I will probably keep QGnomePlatform for Qt5 there, because what I did for Fedora was to backport some Qt6 goodies to actually improve the Fusion style for Qt5 apps, but we probably won't do the same in the KDE runtime and by default the Fusion style there would not look as good as in Fedora.

Do you mean the upstream KDE runtime? I'd expect that Fedora KDE Flatpaks / the Fedora KDE runtime would behave pretty much the same as the same packages in loose RPMs, and if there are differences they should be easy to address (maybe we need to add Fusion into the Fedora KDE runtime, for example.)

I've tested Gwenview, Wireshark and Kate in F39. None of them seem to have the Adwaita styling, and they look better for it.

This was testing with the regular Fedora packages. There were some issues with the Fedora Flatpaks, but I'm not sure whether those are related or not.

Either way, I think we can close this issue. Thanks everyone!

It's tricky with Flatpaks. I will probably keep QGnomePlatform for Qt5 there, because what I did for Fedora was to backport some Qt6 goodies to actually improve the Fusion style for Qt5 apps, but we probably won't do the same in the KDE runtime and by default the Fusion style there would not look as good as in Fedora.

Do you mean the upstream KDE runtime? I'd expect that Fedora KDE Flatpaks / the Fedora KDE runtime would behave pretty much the same as the same packages in loose RPMs, and if there are differences they should be easy to address (maybe we need to add Fusion into the Fedora KDE runtime, for example.)

I mean the upstream KDE runtime (on Flathub), where to me it doesn't make sense to follow Fedora and all the additional Qt6 backports we have. The Fedora KDE runtime will pick whatever we have in RPMs, right? So there it should be same.

Metadata Update from @catanzaro:
- Issue untagged with: pending-action

6 months ago

Apologies for bumping a closed ticket, but I was wondering if the issue at hand could be solved by adding some Qt appearance settings to, say, GNOME Tweaks. Or would that be too tall an order?

Oh noo we want to remove themes that break applications and make them way less accessible GNOME's so baaad.

@orowith2os Real mature... And of course themes will break applications — if you refuse to support them properly. It's a self-imposed vicious circle.

With how much the Linux ecosystem is fragmented, your "apps looking like they belong on the system" is futile in the first place.

Perfect-solution fallacy.

Trying to theme these apps is not the solution, and only ends up hurting end users, developers, and wasting everyone's time.

[citation needed]

Trying to theme these apps is not the solution, and only ends up hurting end users, developers, and wasting everyone's time.

[citation needed]

https://stopthemingmy.app/

This ticket is resolved by the removal of adwaita-qt. There's really nothing more to discuss here. Please stop.

https://stopthemingmy.app/

@theevilskeleton Oh, I do know of this one. Considering that the vast majority of the signatories belong to the same circle, referencing that site is basically an ipse dixit.

This ticket is resolved by the removal of adwaita-qt. There's really nothing more to discuss here. Please stop.

@catanzaro Very well.

Login to comment on this ticket.

Metadata
Attachments 26
Attached a year ago View Comment
Attached a year ago View Comment
Attached a year ago View Comment
Attached a year ago View Comment
Attached a year ago View Comment
Attached a year ago View Comment
Attached a year ago View Comment
Attached a year ago View Comment
Attached a year ago View Comment
Attached a year ago View Comment
Attached a year ago View Comment
Attached a year ago View Comment
Attached a year ago View Comment
Attached a year ago View Comment
Attached a year ago View Comment
Attached a year ago View Comment
Attached a year ago View Comment
Attached a year ago View Comment
Attached a year ago View Comment
Attached a year ago View Comment
Attached a year ago View Comment
Attached a year ago View Comment
Attached a year ago View Comment
Attached a year ago View Comment