Last update: neurodifferent.me/@alexm/10997…
It's been a while, so a number of things happened.
------
You've probably already seen it, since it was in the last TWIG, but @jamie added a way to create AdwAboutWindow from AppStream data. In particular, this should make release notes page far easier to work with - the release notes already support appstream markup and now it can just pull them from appdata directly rather than having to copy-paste them, and unlike application name, developer name etc they tend to be fairly long.
It doesn't unfortunately fill everything - for example, copyright line or credits still have to be specified manually since AppStream doesn't have that data in the first place. But it still considerably reduces the amount of copy-pasted information.
One part that is a bit awkward is that the appdata xml needs to be in gresource (the original plan was get the installed file by path, but it's pretty hard to do correctly in practice), and meson doesn't make easy to pull translated xmls into gresource - but it is doable.
And well, it means that libadwaita depends on libappstream now.
------
To reduce confusion a bit, @brainblasted deprecated adw_expander_row_add_action() and added adw_expander_row_add_suffix() instead - matching action rows instead. We really should have done it back in 1.0, but didn't for some reason - better late than never.
------
For sidebars, Chris also added a property that hides AdwHeaderBar title, incl. the generated one that's pulled from the window or browsing view. This should make it a lot easier to have a title in a sidebar only when folded, once the new sidebar widgets land.
------
A new contributor added AdwSwitchRow - a simple AdwActionRow subclass with a GtkSwitch. While this isn't too difficult to implement manually, it's a really common case and it gets annoying, so having a helper is nice. Another nicety is that it doesn't expose the GtkSwitch:state property, only :active - meaning it's much harder to misuse it.
------
@mks_h added a description property to AdwPreferencesPage - it looks same as preference group description, but shown at the very top of the page, making some of the Settings mockups easier to implement.
------
I finally finished and landed AdwToolbarView. We also did a few changes to toolbar styles, so you may notice the doc screenshots look a bit different now. ^^
This one I'm not announcing in TWIG yet, since the rest of the new widgetry is not there yet, so it's not as useful yet as it will be later, once the new sidebar widgets have landed.
A change that's sort of related to toolbar view, but also not really, is that the new header bar style with a shadow is now also used for GtkWindow titlebars. While we can't use it for any random header bars in a GtkBox, we can do it here. This does have a few side effects though:
- If an app is using a header bar as a window titlebar, but has, say, a GtkSearchBar within the window, the header bar shadow will be above the search bar. It's not a big problem in practice since very few apps do this (I checked every core app and every third party app I have installed and only found 2 instances), and it doesn't do much harm, just looks a bit weird - but still a thing to keep in mind.
- Late in the last cycle we changed GtkPopoverMenuBar style to use a header bar-like style as well, with the same colors and border, and a backdrop style. Well, it is quite common to use menu bars together with a header bar set as a GtkWindow titlebar as well, particularly with the automatic one GtkWindow adds by default. So, I just reverted that change and the menubars look plain and boring once again. If somebody wants them to look fancy and blend with the titlebar, AdwToolbarView does support them, so you can add a header bar and a menubar within one and it will look nice. There is even an example of that in libadwaita tests.
Alice
in reply to Alice • • •Now onto the things that have not landed yet:
For adaptive states I extracted the code that makes them work from AdwWindow and into a reusable widget that's currently called AdwAdaptiveBin.
It works the same way as adaptive states on the window - you add one or more adaptive states, set their conditions add setters changing properties on the child widget, and they are safely applied on resize, with the tradeoff that the the widget has no minimum size and you must set it manually using the GtkWidget's width-request and height-request properties. If you don't, it will print a critical telling you that every time it's allocated, so hopefully people won't forget to do it.
Currently it's public in the branch, I'm not sure I'll keep it that way since a part of the idea for the new mechanism was to do it on the window so that it can all be done in one step - but at the very least it made the code a lot cleaner, so the widget is gonna stay even if it's gonna be private.
------
On GTK side I went ahead and tested gtk4-demo with all buttons being able to ellipsize. It... does not work well, it's a pretty big behavior change so it definitely needs to be an opt-in property. But that's fine.
What's less fine is that GtkCenterLayout prioritizes the center child over start/end. In practice it means that if you have, say, a dialog with the following header bar:
[ Cancel ] Add a New World Clock [ Add ]
and the title doesn't completely fit, the buttons will ellipsize first, and you will end up with this:
[ … ] Add a New World Clock [ … ]
and only then it will start ellipsizing the title:
[ … ] Add a New… [ … ]
That's not great, it should do the opposite here, first fully ellipsizing the title and only then ellipsizing buttons if it doesn't fit even then. I guess GtkCenterLayout needs a way to control this, because there are situations where prioritizing the center child makes sense. But that's something for another week.
------
The :pop-content-on-fold property on AdwDualPaneView is actually implemented now, so there is an easy way to make it immediately show sidebar instead of content when folding, same as how when visible-child is set to the sidebar right now.
------
As I mentioned in neurodifferent.me/@alexm/10998…, I started working on a widget that can replace AdwFlap for the utility pane case, but didn't have a good name for it. Well, I still don't have a good name and suggestions are still welcome
but the widget is now in the merge request as well, and AdwHeaderBar has learned to manage window buttons on it just like it does with AdwDualPaneView.
One thing it doesn't do for these widgets is handle nesting. It probably should implement it though.