-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Why disable custom themes? #39
Comments
Hello, In some case, custom themes can work fine: it depends of GTK version inside AppImage and GTK version on your system.
In fact, there is no need for this workaround, see by yourself: APPIMAGE_GTK_THEME="${APPIMAGE_GTK_THEME:-"Adwaita:$GTK_THEME_VARIANT"}" If you set
Yes, I am able to reproduce this issue with CPU-X 4.0.0 AppImage:
Feel free to export |
Thank for for the detailed response.
This makes sense, so it's about Gtk breaking things over time again. I'll try this out and also replicate your screenshots and find what other themes are affected by this. Do you know if it is generally a safe bet to build on Ubuntu 18.04 then?
I have seen this, but I'm not sure how forcing a different theme other than Adwaita on my users would solve anything. Yes I can set this to chicago95, but what's the point if nobody has it installed? The only thing that is justified to put as APPIMAGE_GTK_THEME appears to be a theme that is available on all common Linux distros, and Adwaita seems to be the only one where this applies. Or do you mean to also ship the custom theme alongside? Either way, I wouldn't want to force any specific theme ever, neither on the system nor a single gtk app. Linux is all about customization which this would break. OS theme integration far outweighs ugly tabs on some exotic distro IMO. Question is just how exotic that is. May I ask what distro you are building CPU-X on? |
Well, theming is always an issue. Mostly technically, but also UX wise, especially when applications should be distributed on more than one platform from the same package. Distributions can invest a lot more time into testing, after all. See also https://stopthemingmy.app/ and maybe also https://invidious.snopyta.org/watch?v=hdRGVej3RyI. If you want a specific theme, shipping it is the most reliable way to do so. Otherwise, using a known good fallback is a good idea. Edit: |
No, I don't want a specific them. I also don't want a fallback. I want to not break customization for the user. I understand how this might be preferable for some Gtk application authors though, but I wonder if overwriting APPIMAGE_GTK_THEME by default is really that good of an idea. But anyway, I can (and am doing) just alter the script, so all is good. :-) |
Please don't hesitate to contribute a way to opt out of this behavior. This shouldn't require a lot of code. Patching the auto generated script sounds like a really annoying workaround. |
Hi! Thanks for all the work on this. As far as I can tell until now, it works flawlessly! Except, of course, hardcoding Adwaita (dark/light) is not so cool, as this completely breaks the OS-wide Ui integration.
Now in the source, it says
Custom themes are broken
. I haven't been able to verify this yet: I disabled that line and found that everything seems to work out fine. For example, this is Chicago95, a heavily customized theme, with a popup and some controls:It's exactly how it should look like and how it also looks without AppImage in the first place.
Do you have some more details on this? Some way to replicate bad behavior? Because otherwise, I am in favor of keeping this line disabled and shipping it as is to my users.
The text was updated successfully, but these errors were encountered: