Why is not libadwaita merged into gtk4?

As far as I’m aware libawdatia brings three things:

  1. Adaptive containers
  2. New widgets
  3. New style classes

Which don’t exist in gtk.
So why are these features developed in a separate library. Why not just merge libadwaita with Gtk4?
Is it because Gtk4 was released before libadwaita? If so, does that mean it can be merged in the future? What am I missing? Can anyone please explain the situation. Because this situation doesnot make any sense for me at all!

Because libadwaita adds GNOME-specific widgets and GNOME-specific styles, same as how Granite adds elementary-specific ones and KDE libs add KDE-specific stuff on top of Qt.

I’m not really convinced with that, as I’ve mentioned things that libadwaita add (Adaptiveness, stylesheet) are not gnome-specific.
If you consider those features and patterns to be gnome specific, then the whole Gtk is gnome specific. And also libadwaita apps are being used on non gnome environments, just like gtk apps.

Another point: Kde may have some libraries because they are not the main developers of qt. And so elementary is not the developer of Gtk. While gnome is the developer of both Gtk and libadwaita. So why?

The GNOME stylesheet is not GNOME-specific? Tell that to elementary, that they need to throw away their own stylesheet and adopt Adwaita. :slight_smile: Or to xfce. Or to MATE, Cinnamon etc. Granted, they are still on GTK3 but same idea.

Adaptiveness - ditto. Do you see elementary, xfce etc using it?

then the whole Gtk is gnome specific. And also libadwaita apps are being used on non gnome environments, just like gtk apps.

I mean there are plenty of things in GTK that are indeed GNOME-specific and wouldn’t have been added to GTK today - e.g. GtkShortcutsWindow, the current GtkAboutDialog layout, the current GtkMessageDialog layout, the current GtkFileChooserDialog layout etc. All of those things people from those environments always complain about.

Did you know Granite provides a custom MessageDialog because GtkMessageDialog doesn’t work well in elementary and can’t be made to work well there, for example?

And also libadwaita apps are being used on non gnome environments, just like gtk apps.

Libadwaita apps such as GNOME Contacts, GNOME Clocks, GNOME Calculator or GNOME Characters? As well as third-party apps made for GNOME and following the GNOME HIG such as Shortwave or Amberol? Sure, they can be used anywhere, and?

Meanwhile e.g. elementary apps such as Pantheon Files, elementary Code and third-party apps like Planner or Dippi - they are using Granite, elementary stylesheet etc instead. And they can be used on GNOME as well.

So why?

“gnome” is not a person. The developers of GTK and libadwaita are not the same. But that doesn’t matter, you are still missing the point. GTK is used by GNOME, also elementary, xfce etc. It’s not a GNOME-specific library. libadwaita is. End of story.

You may want to read the announcement blog post, for example, it explains the specific things it’s solving quite well.

1 Like

I think I got your point, but I’m still convinced that it’s more beneficial for the platform that these two libraries get merged. Thanks for the clarification :blush:.

Edit: deleted this part because I think I am completely wrong.

Why? Keeping libraries separate also has another benefit: The two libraries can be released separately on their own release cycle. GTK does not have to tie itself to GNOME’s release cycle; if the libadwaita widgets were merged then GTK would have to do that, which would cause issues for all other users of GTK who might need something on a separate schedule from that of GNOME.

Also if you actually did this then you could say goodbye to either style classes or to alternate themes, because those two things are not compatible with each other. That would also hurt other libraries like Granite.

1 Like

I think your argument stands for the stylesheet. From this perspective you are right. But there are also widgets and containers, for example:
libhandy had a widget called window-handle now it’s merged in gtk4. On the other hand containers like leaflet were implemented in libadwaita not gtk4. So who decides that? Both widgets are really important. From your point then let all widgets go to Gtk and leave stylesheet in libadwaita.

One Gtk major version doesn’t break API compatibility, right? So that makes it possible to add new widgets to Gtk without a new release. ( I think that new widgets don’t break compatibility, do they?)

Adding widgets doesn’t break API. Deciding that they don’t work and reworking them does. Libadwaita has a much shorter release cycle and we can actually do that. GTK though? Well, you’re stuck with those widgets for the next decade.

Leaflet specifically is a bit of a grey area - I wanted to upstream it at one point, but didn’t because of the complicated swipe handling + at this point I want to ditch it completely and replace with 2 much simpler widgets optimized for how leaflet is actually used: a sidebar|separator|content widget specifically kinda like flap + a back/forward widget with a corresponding API, not what’s essentially a copy of GtkStack. As is though this widget isn’t good enough to be in GTK.

As for window handle - there’s an important context missing here: when that widget was developed, GTK3 was frozen and no new features could be added to it, while GTK4 was still in development. So, where would that widget go? Yep, libhandy.

You know what I am going to tell you about what I wanted to do. I want to use use the containers and widgets in libadwaita without using its stylesheet. How is that possible?

Another question:
I think that this way it’s more beneficial to separete libadwaita into two libraries one for stylesheet (gnome specific) and one for Adaptiveness (not gnome specific) like kirigami. Since Adaptiveness and styling are two separate problems. What do you think?

Feel free to copy any parts of it into your app. :person_shrugging:

into two libraries

No, that’s against the goal of being a single library for GNOME stuff.


Really though especially if you’re not writing a GNOME app you should be able to see why libadwaita parts being in GTK would not be a good thing. The only reason you have the option of not using Adwaita style at all is because it’s not in GTK. You wouldn’t have that choice otherwise.

2 Likes

The reason GTK and LibAdwaita will never merge is because GTK is not supposed to be used directly by application developers. Its main reason of existance to provide very basic Widgets that libraries like LibAdwaita can use to build their own widgets very easily.

GTK is there to act as a base for libraries like LibAdwaita.

No, that’s definitely not the case.

1 Like

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