Is libadwaita suitable for multiplatform apps?

Hi,

I’m porting some multi-platform (Linux+Windows) apps from gtk+3 to gtk4. I noticed that many gtk4 apps also started using libadwaita.

Does libadwaita bring any benefit for multi-platform apps?

From what I could see, libadwaita is a visual API tuned for GNOME (and derivatives like Librem/Posch), and relies on portals for some settings like dark mode or accent color. Am I right?
What is the behavior on platforms where portals are not present, like win32? Does it fallback on configurable defaults, like gtk does with its “settings.ini”?

Also, I’m wondering why it was decided to go this “GNOME-only-plus-portal-tweaks” way, wouldn’t have it be better to create something like a “libvisual-gnome” library instead, so other devs could create drop-in “libvisual-e17” or “libvisual-win32” platform-specific equivalents?

1 Like

No, Libadwaita has native implementations for the dark mode setting on Windows and MacOS, it does not use portals on those systems.

I am not sure what extra benefits you might be thinking of here, if you are comparing to something like Qt or Flutter, etc. The benefit of multi-platform is if you like the development style then you can use that to build the same app on multiple systems.

2 Likes

ah, thanks for the info, this is indeed very nice!

About the potential benefits, when I think of a “multi-platform visual API”, I ideally expect some little tweaks to better match the platform’s UI.
I mean, not a complete new CSS styling, but for example, using the platform’s standard minimize/maximize/close control buttons style instead of the GNOME one. Or using square corners instead of rounded ones for windows under Windows10.
In general, anything that would help the apps to look and behave more native/integrated.

There is no built in styles for those, but you can create a custom style for other platforms. BTW, Win11 actually has rounded corners now.

1 Like

Thanks!

So, basically libadwaita doesn’t provide more than gtk itself, regarding the multi-platform support.

Then I’ll stay on gtk4 alone for my apps, and add a plugin for optionally loading libadwaita and calling adw_init() at startup, for those wanting to use the style.

FYI: that won’t automatically make the app integrate well with GNOME. Libadwaita provides many common widgets in GNOME apps (e.g. toolbar view), that you won’t have access to without libadwaita.

1 Like

Yeah, of course, but it’s not an issue, I’m not targeting the GNOME platform but instead try to be as agnostic as possible.

Ideally for me, as said above, would be a visual lib that (slightly) adapts its UI depending on the platform, what libadwaita doesn’t.

There is no point for me to use libadwaita widgets if they just always stick to the GNOME style.

How would a developer make sure that their app worked with all these different libraries?

There is no such thing, every platform has a set of designs that are incompatible with each other, e.g. Windows expects you to use a toolbar or ribbon, MacOS expects you to use the global menubar, GNOME expects you to use the headerbar, KDE expects you to use a non-global menubar and toolbar, I could go on here…

For anything more than slightly, there is no way for this to work really, the appearance of the UI is completely dependent on the app. But it seems someone could create a small add-on library to libadwaita that changes a few small things like you mentioned, e.g. the window buttons and the corner rounding.

Anyway, I see what you mean. If you want to use the dark mode and high contrast implementations in libadwaita then that could be a reason to use it, otherwise you will have to reimplement all that code for Windows and MacOS and also for the portal, or at minimum copy it out of libadwaita.

1 Like

I don’t understand your point…
I’m already testing my apps on different environments/platforms, so that wouldn’t change anything for me.

@jfrancis
thanks, I fully agree.

I was a litte bit confused about libadwaita’s goals, now it’s clear to me.
Creating “-e17” or “-win32” variants would definitely not make sense.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.