Last update: https://crab.garden/@alice/110457636175445239

---

So now both AdwNavigationSplitView and AdwOverlaySplitView have landed.

The latter has had a few more last-minute changes, a notable one is that I completely dropped touchpad gesture support from it.

Unlike touchscreen swipes, touchpad swipes never worked well with it and sometimes were the reason people were disabling gestures altogether: opening sidebar on touchscreen was (and is) an edge swipe, which is not possible on touchpad, so instead opening sidebar is a swipe from anywhere.

Similarly, closing the sidebar was a swipe from the sidebar on touch or from anywhere on touchpad.

This means that e.g. Loupe had to do pretty nasty workarounds to prevent swipes from interfering with navigation, and that's not great.

So, touchpad swipes re gone, now the only remaining gestures are restricted to the sidebar/the edge where the sidebar is.

Meanwhile a bunch of properties have been renamed:

- swipe-to-open -> enable-show-gesture
- swipe-to-close -> enable-hide-gesture
- reveal-sidebar -> show-sidebar
- locked -> pin-sidebar

And :reveal-progress is gone with no replacement. If needed, we can always add it back later.

---

The sidebar size defaults have changed for both split views: the default max width has been reduced from 360sp to 280sp, and the default width fraction has been reduced from 0.3 to 0.25, so the defaults should work well for more apps now.

---

For AdwNavigationSplitView it's now possible to use the navigation.push action repeatedly when it's not collapsed (I don't want to say expanded because GTK uses that term for another thing), specifically for pushing content when it's already pushed - then the action will just no-op instead of printing a critical about the duplicate page.

The intention behind that critical was to match AdwNavigationView (where you cannot have the same page twice in the navigation stack), but it doesn't work very well in practice - the primary use case for this action is a sidebar, and when it's not collapsed you're gonna be clicking rows when :show-content is already true, unlike when collapsed and you won't even see the sidebar in that case.

So - it no-ops now. Thanks @melix99 for feedback

---

And that's it. The next steps will be to get rid of leaflet/flap/etc mentions all over docs, then deprecate old stuff.

#Libadwaita #LibadwaitaUpdate

Alice :queercat_trans: (@[email protected])

Content warning: libadwaita updates, long

Mastodon Glitch Edition

@alice so is the touchpad swipe to open/close overlay sidebar (sorry if that's an incorrect term) gesture gone permanently, or is there a hope of bringing it back later in a way that doesn't cause as much trouble?

@melix99

@bugaevc probably permanently, I mean how would it work?

It's too intrusive, and works completely differently from touchscreen here, unlike on navigation view or carousel, so it's hard to work with from developer pov.

@alice I don't know gtk or libadwaita nearly enough to suggest a specific solution, but with some sort of gesture claiming and priorities system. Like the underlying/main view would use up the swipe as much as it can (e.g. for scrolling itself horizontally or back/forward navigation), and pass the remainder to the overlay sidebar view to interpret.
@alice Again surely you know this better than I do, but see how NestedScrolling{Child,Parent}{,2,3} work on Android, they even split fling velocity properly between the child and the parent. And then they have a bunch of views that take advantage of this, such as SwipeRefreshLayout that does not conflict with vertical scrolling of the underlying view.
@bugaevc I don't mean technical issues (though there are _major_ technical issues with specifically scrolling (TLDR scrolling doesn't come in sequences and you can only stop/propagate individual events, and there isn't even a way to do grabs - that's why none of the swipes on touchpad work together with scrolling atm)), but design issues. You have 2 swipes, one is an edge swipe, the other isn't. And apps need to account for both at once.
@bugaevc like even if it did work well, you now have a gesture where a random swipe somewhere on a window can bring up or hide a sidebar, and it's exclusive to touchpads - that's rather messy :)

@alice hm, so you mean it's undesirable from the design/ux pov?

how am I supposed to open a sidebar then? -- is it by tapping a button?

@bugaevc depends on the app, sometimes yes. Same as when not using touchpad, like with a mouse those gestures were never a thing.
@bugaevc in some apps you're not supposed to open/close the sidebar yourself, like shortwave manages it automatically.
@alice I open shortwave to check and immediately see this :|

@bugaevc GtkBox bug :)

In GTK 4.6 this would have inflooped too.