Skip to main content

Fun fact: The XDG desktop portal for GNOME mobile is not adaptive, despite Nautilus being Adaptive (Nautilus is still not yet perfect on mobile but it's getting there)

#xdg #linux #linuxmobile #gnome

XDG file picker for GNOME on GNOME mobile
#linux #gnome #linuxmobile #xdg
in reply to Amy 🇹🇭🏳️‍⚧️

Emmanuele Bassi
Emmanuele Bassi
• •
that’s because it’s using dialogs provided by GTK4, and GTK cannot depend on libadwaita widgets
in reply to Emmanuele Bassi

Angelo Verlain
Angelo Verlain
• •
@ebassi I saw there are 2 separate implementations: GTK and GNOME. I wonder if the GNOME one couldn't possibly use libadwaita
@Emmanuele Bassi
in reply to Angelo Verlain

Emmanuele Bassi
Emmanuele Bassi
• •

@vixalientoots the GTK portal uses GTK3; the GNOME portal uses GTK4. That's the difference.

You cannot implement GtkFileChooserDialog inside GTK using libadwaita, because libadwaita depends on GTK.

The only way to do that would be for the GNOME portal to implement a whole new file selection dialog living in the portal itself.

@Angelo Verlain
in reply to Emmanuele Bassi

Maxim Therrien
Maxim Therrien
• •
@ebassi @vixalientoots why isn't GTK4 adaptive? I feel like if GNOME Mobile is going to succeed, GTK4 needs to be capable of adapting to a mobile screen by default.
@Emmanuele Bassi @Angelo Verlain
in reply to Maxim Therrien

Emmanuele Bassi
Emmanuele Bassi
• •
@isVeryLoud @vixalientoots because we still have no precise idea what “adaptive” means. We started with libhandy, then libadwaita, and now libadwaita has a whole new set of widgets to implement adaptive layouts. If we wanted them in GTK4 we would have required breaking API twice, by now. Plus, for GTK5 we might get a better layout system that will make implementing animated layouts more easy. In short: we are still iterating.
@Angelo Verlain @Maxim Therrien
in reply to Emmanuele Bassi

Maxim Therrien
Maxim Therrien
• •

@ebassi @vixalientoots Thank you for explaining!

> If we wanted them in GTK4 we would have required breaking API twice, by now.

Would adding adaptive components besides the existing ones be considered an API break? I agree it's probably the dirty way to go at it, but it would at least allow edge cases like non-GNOME software and code depended on by Libadwaita to have standardized adaptive components, although "we still have no precise idea what “adaptive” means" still remains.

@Emmanuele Bassi @Angelo Verlain
in reply to Maxim Therrien

Emmanuele Bassi
Emmanuele Bassi
• •
@isVeryLoud @vixalientoots adding new containers isn’t the problem, but if you look at how libadwaita works, you’ll see that it moves faster than GTK, and that it can break API more easily. GTK has a longer horizon of support. That’s one of the reasons why libadwaita exists: to experiment, iterate, and release more quickly.
@Angelo Verlain @Maxim Therrien
in reply to Emmanuele Bassi

Maxim Therrien
Maxim Therrien
• •
Got it, thank you! So for xdg-portals, we'll just have to wait for GTK5 to get mobile-ready portals, or should they roll their own widgets that look like Libadwaita?
This entry was edited (1 year ago)
in reply to Maxim Therrien

Emmanuele Bassi
Emmanuele Bassi
• •
@isVeryLoud @vixalientoots you don’t have to wait for GTK5: you can write your own portal implementation that uses whatever file selector dialog you want—even write your own according to your own platform guidelines or preferences
@Angelo Verlain @Maxim Therrien
⇧