neurodifferent.me is part of the decentralized social network powered by Mastodon.
A friendly space for neurodifferent folks.

Administered by:

Server stats:

195
active users

Learn more

Alexander Mikhaylenko

libadwaita updates

Made some progress on AdwBrowsingView/AdwDualPaneView (names are not set in stone) yesterday.

libadwaita updates

One of the goals I have with the dual pane widget is making it simple enough to implement that apps can do it in tree if needed, just like gtk4 made it easy to have custom entries.

So if some app wants them to e.g. be resizable but still adaptive - it can do it instead of getting told it's impossible.

Same thing with triple pane layouts. Eventually that may end up in libadwaita, but at least early on I don't think it's necessary - almost no apps need it. I can count Geary, Newsflash and... that's it? So they get to do it in tree instead.

So, one of the consequences of making it a wrapper around two browsing views that connect when folded is that they are stacked on top of each other and the top one steals input from the bottom one.

To prevent that, AdwBrowsingView overrides contains() to pass through input when there's nothing in it.

Now that's great, but in this widget the browsing views are inside bins which don't do that so it still didn't work and required widgets with overridden contains() instead. This is too complex for apps so instead the branch now adds AdwBin:pass-through and it's simple again. :)

libadwaita updates

Another thing I was unhappy about is window controls handling.

Traditionally this has been kinda bad... No, scratch that, _really_ bad.

When GtkHeaderBar was first introduced, the intention was to put one as a titlebar into a GtkWindow. Unfortunately, this was very much not enough even at the time - for split header bars you need two. And for each of them you need to manage window controls manually.

The traditional solution was to pretend this problem didn't exist and just hide controls from the left bar. Then anyone who moves window buttons to the left is left with funny layouts like close button in the middle of the window.

One of the demos in gtk's tests/ dir implements it correctly by parsing decoration-layout manually, splitting it in the middle and applying each part to both header bar -> too complex for apps, and predictably nobody ever did it.

Then later libhandy 0.x introduced HdyHeaderGroup to try and automate that and close button only on the active pane when folded. Well, it worked, but it was fiddly and it only worked with GtkHeaderBar and not HdyHeaderBar.

Then for libhandy 1.0 it was reworked it to work with either and allow nesting header groups for... Reasons? See, the idea was to allow hiding one header bar at a time in Geary which has 3 total. and so we nest 2 header groups... Except none of this is necessary because it already tracks mapped state of the header bars and excludes those so it already works without this.

And for the folded state tracking the current pane was unnecessary because why not have close buttons on all of them, so it was replaced with a bool property for that... Except again, it was unnecessary because of the mapped state tracking.

Then for libadwaita 1.0 I scrapped all of this stuff and changed AdwHeaderBar to have :show-start-title-buttons and :show-end-title-buttons so apps can bind them to the leaflet's folded state and be done with it.

And yet some apps still forget to do it.

libadwaita updates

That's understandable because manually managing these is messy no matter how the api looks like. It really ought to be automatic. And browsing view already makes back button and header bar title management automatic, so why not these 2?

One of the ideas for solving it was to have header bars track their own positions, but that cannot really work in GTK, so nope.

So instead AdwHeaderBar is just aware of AdwDualPaneView now. It works, but only for dual pane view and not app reimplementations. So if some app reimplements it, they will still have to track it manually. Not great, but I guess this is the best we can do here.

libadwaita updates

One thing I'm still very unhappy with is the styles. While having a dedicated widget for this finally makes it possible to have a different background for sidebars like some people have been requesting for ages, that style only makes sense with flat header bars.

And now we run into a problem. We don't have flat header bars elsewhere, and in a large part because of technical issues.

Scrolling content needs undershoot styles, like the shadow on my screenshots. So no problem, we will add it to all scrolled windows... Except what if it doesn't touch the header bar?

Oh, and we also need it on the bottom because of action bars that also have to be flat. So we'll also add it there...

And now it's ugly in a lot of other cases. Like when 2 scrolled windows touch each other like here in Builder, or when it touches the window edge. So that's not an option either and has to be manual.

At that point all of this needs to be manual really and now we end up with a completely nonsense style OOTB with non-flat header bars inside an already dark header bar.

And what's the solution? Who knows.

libadwaita updates

Note: I'm CWing this thread and I'll probably be CWing gnome stuff in general moving forward, just like I do for games. At this point there are at least a few people following me who are not interested in this kind of updates, so I want to make it easy to skip it for them, same as people who follow me for GNOME stuff are probably not interested in me playing touhou. :)

libadwaita updates

> and predictably nobody ever did it.

Or even knew it existed, for that matter. I only learned it existed from a gtk maintainer a year or so ago.

libadwaita updates

@alexm why we don't specify which widget has the corner of the window? That way we can specify that the app window has the right corner and the side pannel has the left corner. That can be used to put the window buttons only in one place and not many times.
I don't know, I'm just a regular gnome user

libadwaita updates

@Luci that's not how anything works, sorry :)

libadwaita updates

@alexm in gtk 3 that didn't happen

libadwaita updates

@Luci it absolutely did. Most of what I said is about gtk 3

libadwaita updates

@Luci Probably what u r referring to is that this specifically didn't happen in the GTK 3 version of gnome-control-center, and it's mostly 'cause the nightlight section was in a GtkStack, and u were accessing it through a GtkStackSwitcher. In the port to libadwaita and GTK 4, the night light section is now a page of its own, and therefore has its own headerbar and a "back" button

libadwaita updates

@nahuel @Luci and that's just the last couple of cycles too, before that it was even worse than on my screenshot.

libadwaita updates

@nahuel @Luci e.g. in gedit here - I'm surprised settings worked at least. Also those inner corners :(

This is 3.26/F27 - the first version with Settings with a sidebar, maybe I was remembering tweaks instead?