Skip to content
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

Consider avoiding libadwaita in favor of GTK #1378

Closed
badcel opened this issue Aug 13, 2024 · 8 comments · Fixed by #1380
Closed

Consider avoiding libadwaita in favor of GTK #1378

badcel opened this issue Aug 13, 2024 · 8 comments · Fixed by #1380

Comments

@badcel
Copy link
Contributor

badcel commented Aug 13, 2024

Please avoid using libadwaita. libadwaita doesn't work well outside of the Gnome desktop, reduing the potential user base for this application.

Originally posted by @probonopd in #1322 (comment)

As the DevToys Linux version is primarily a wrapper around a webview it potentially does not benefit as much from libadwaita as an application with native controls.

Libadwaita apps are generally tailored to the gnome desktop which may result in a reduced compatibility with other desktop environments.

Under this aspects it could be worth to verify what would happen if DevToys was based on the more general GTK instead of libadwaita.

@veler
Copy link
Collaborator

veler commented Aug 14, 2024

Thanks :) How does this translate into GirCore? Should I try to use GTK instead of ADW namespace or something like this? Or would you recommend using another library than GirCore as GTK wrapper?

@badcel
Copy link
Contributor Author

badcel commented Aug 14, 2024

Yes this would mean removing the GirCore.Adw-1 package and keeping the other packages.

Then you switch to the GTK namespace and that's mostly it as libadwaita is inheriting from GTK.

Both libraries provide an Application class and ApplicationWindow class. The WebKit bindings depend on GTK directly. So the change should be straight forward.

I think you would mostly loose rounded corners on Linux and gain cross desktop compatibility.

@veler
Copy link
Collaborator

veler commented Aug 14, 2024

Gotcha, thank you Badcel! I will try to work on this in the next few days

@veler veler linked a pull request Aug 15, 2024 that will close this issue
18 tasks
@veler
Copy link
Collaborator

veler commented Aug 15, 2024

Alright, I opened a PR here ! Thank you for sharing this @badcel :D
#1380

@CodedOre
Copy link

If I might chime in on this issue:

I noticed you changed the code to check the GTK theme name in order to check for dark mode.
This is not an ideal way to check it. In fact, on a modern Gnome Desktop, it doesn't detect dark mode at all:

Bildschirmfoto vom 2024-08-16 09-11-12

To give a few details:
While setting dark mode with the GTK theme name was a popular workaround when there was no proper standard, it still has it flaws. For example, GTK_THEME is regarded for use in debugging, not to set a dark theme. And some frameworks, like libadwaita, even ignore it entirely. Which is also why Gnome is not setting the GTK theme name when setting dark mode.

Instead, the proper way would be to check the Settings Portal, part of the XDG Desktop Portals. The dark mode preference of Gnome sets the value read by the portal. And the libadwaita code you've used read the dark mode preference from this portal.

Since GTK does not include support for a dark mode preference, you would need to read the portal directly. You could do this by directly accessing the DBus interface with an library like Tmds.Dbus. There's also a C library called libportal, but I'm not sure what the easier way would be.

TLDR: Using the GTK theme name to check for dark mode is not ideal (maybe for a fallback), ideally the Settings portal should be used.

@badcel
Copy link
Contributor Author

badcel commented Aug 16, 2024

@CodedOre thanks for the feedback. I opened a new issue for this topic to track it separately.

See #1381

@veler
Copy link
Collaborator

veler commented Aug 17, 2024

Hello,

Thank you for much for reporting this regression. I unfortunately haven't been able to reproduce it on Linux Mint and Ubuntu. My Ubuntu, in particular, uses Gnome Desktop, but the theme has "dark" in its name, so the issue does not reproduce there.

I did follow @badcel recommendation in #1381 and tested the change on Ubuntu and Mint, and so far, it detects well the theme without needed to fallback on string detection.
#1382

I will try to test on Fedora, but I wouldn't mind if you give it a try too :)
Thanks again !

@CodedOre
Copy link

Hello,

Thank you for much for reporting this regression. I unfortunately haven't been able to reproduce it on Linux Mint and Ubuntu. My Ubuntu, in particular, uses Gnome Desktop, but the theme has "dark" in its name, so the issue does not reproduce there.

Well, Ubuntu had a dark mode setting using the GTK theme name before the Settings portal was finalized. Guess they still set the theme name.

Fedora on the other hand uses more or less upstream Gnome, so there it only sets the setting read by the portal.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants