-
-
Notifications
You must be signed in to change notification settings - Fork 11
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
GTK settings in distributions like Feren OS is set to an invalid value #72
Comments
That's exactly what's happening, the portal is exposing the string of the host style which is not available inside the sandbox. I don't think running elementary apps on non-elementary OS is a "supported" usecase as of now. In order to fix this there needs to be a guarantee that the application will be using the correct stylesheet. Dippi for example explicitly sets the style and icon-theme to elementary. another option would be to have |
I think the best port of call WOULD be to have LibGranite do it instead, since it's the elementary OS equivalent of LibAdwaita, technically, and there's no way I'd think in normal usage for there to be other theme choices anyway besides io.elementary.stylesheet.idk or Adwaita. Heck, I thought that was already the case... nevermind. Obviously you'd still need to support your in-house accent variations, but I'm sure that'd be easy enough to do. |
Possibly related: #30 |
This is because of flatpak/flatpak#4873 |
i don't think so, the issue here is with apps using the elementary runtime. they have the elementary stylesheet in the sandbox already. i believe the best solution is go the libadwaita route and have it hardcoded as part of the granite library. #30 has some limitations (won't work for icon themes, fonts, and won't respect the dark theme application preference). |
Technically, I think that would be easy enough to implement? - there's already possible reference code in elementary/granite#501 's removals, so I guess it ultimately depends on who gets to doing the pull request first, given I have a suspicion this could be the new goal (given LibAdwaita doing that), to finally close this issue, instead of the current inactive pull request. |
Nevermind, work is in progress to effectively put the stylesheet inside Granite itself(?), presumably also fixing this issue |
I'm assuming elementary/granite@6f035b7 means that once the next Granite release happens this bug can be closed as FIXED? |
I suppose, the only thing left now is for Flatpaks to use the updated Granite, hence I'll put this issue out of its misery finally. |
I'm not sure if this is entirely related to #1 and #28 and the likes, but just in case it's not known it's causing actual issues in non-elementary-OS scenarios, I thought I'd make this extra issue in case. Feel free to close it if it's indeed a duplicate of any existing issues.
What Happened
Basically elementary OS's applications in the Flatpak format are horribly visually broken in certain, if not all, non-elementary OS environments. A quick DEBUG mode variable shows that the Flatpaks are set to use... nothing (I'm suspecting they're using, in my case, 'feren' and 'Inspire' (the Feren OS theme combo), but since they don't exist inside the Flatpak they're effectively nothing values in the GTK+ debugger).
This is troublesome especially as:
Camera (bug in effect):
Camera (after changing values):
Fondo (bug in effect, also notice that dark mode doesn't work in this buggy state):
Fondo (after changing values, dark mode now works):
Calendar (bug in effect):
Calendar (after changing values):
Dippi is the only case I know of of automatic theme setting:
...and finally, while it isn't in AppCenter currently, I'll just demonstrate the potential unusability this bug could, theoretically, cause using Byte (forced Adwaita values, to illustrate a point):
Expected Behavior
At the very least, the fallback should be io.elementary.stylesheet.blueberry with elementary icon set
Steps to Reproduce
Logs
Platform Information
The latest version of Feren OS is in use for this issue report, however I'd suspect this same issue would occur elsewhere, if not just in all KDE Plasma distributions.
The text was updated successfully, but these errors were encountered: