Notices by Alexander Mikhaylenko (alexm@neurodifferent.me)

I need ideas.

Thinking what to name that view for utility panes from my last thread.

So currently I have AdwDualPaneView for sidebars that turn into browsing when folded.

The line between utility panes and sidebars in HIG is rather thin:
- they are used differently
- sidebars use split header bars, utility panes don't
- they handle adaptivity different

The first 2 points don't concern API and so the 2 widgets are basically identical when unfolded. On top of a lot of people using them for actual sidebars - for example, AdwDualPaneView only allows sidebars on the left because otherwise the folded state doesn't make sense. The utility pane view can put the sidebar on either side, and e.g. Emblem would use it there just because of that. And, similarly, I can see quite a lot of apps use it for more than strictly the HIG definition of utility panes.

And so I don't think it makes sense to call it anything related to utility panes.

Before the name "utility pane" appeared, we were using the name "transient sidebar", and I find it describes what this widget is more accurately.

At the same time, the name "dual pane view" stops making sense when we have a second widget that's also 2 pane. In HIG terms it's a sidebar. Obviously this widget is not just sidebar but sidebar+content, but "sidebar view" could still work.

So I'm leaning towards the following names:

- AdwNavigationSidebarView - becomes browsing when folded
- AdwTransientSidebarView - becomes overlay when folded

But they are long and unwieldy, that's not great. Any ideas for something shorter but still clear/making sense? So not like leaflet/flap where it's just random words, but also not as long.

Other ideas:

- Android calls the latter kind "navigation drawers", but uses them too differently from us

- UIKit and SwiftUI call the first kind UISplitViewController and NavigationSplitView. But "split view" can refer to both

- A lot of web frameworks seem to be calling the latter kind overlay sidebars

Last update: https://neurodifferent.me/@alexm/109891100907228249

I was mostly focused on preparing 1.3.rc and landing everything I need to land in time, so not much happened in the meantime.

However, since it's hard code freeze now, I can start landing new stuff, so I've just landed the new undershoot, view switcher styles and toolbar refactoring, along with opening corresponding MRs for Calendar and Logs since it's a behavior change.

The rest still needs work:

First, all of the new API need docs and tests.

Otherwise:

AdwToolbarView is ready otherwise. I still need to port a few more apps to test things - I have a mostly complete port of Ephy (it's complicated because of fullscreen handling), but there are a few bugs there that I want to iron out first to make sure they are even fixable with this widget.

AdwAdaptiveState - there is a regression with porting preferences window that I need to get to first.

I'm also still waiting on GTK to start ellipsizing buttons - GTK people decided to try it out globally after branching gtk-4-10.

And then I need to decide if it will still need non-px units with that.

Meanwhile, I fixed a bug in GtkBuilder, so adaptive states in UI files can now be a little prettier.

Before:

<object class="AdwAdaptiveState">
<conditions>
<condition type="max-width">600</condition>
</conditions>
<setter object="sidebar_view" property="folded">True</setter>
</object>

After:

<object class="AdwAdaptiveState">
<condition type="max-width">600</condition>
<setter object="sidebar_view" property="folded">True</setter>
</object>

I.e. <condition> just within the <object>, without <conditions>. It was always supposed to be like this (well, ideally it would be <property> but we can't have custom GBoxed there), and without <conditions> the parser was choking on nested conditions like:

<condition type="all">
<condition type="max-width">500</condition>
<condition type="max-height">500</condition>
</condition>

That works now, so yep.

The next widget to replace after leaflet is AdwFlap. And this one is complicated.

With leaflet: adaptive states, AdwBrowsingView and AdwDualPane view cover most cases - and those that they don't are easily reimplementable in apps, like three-pane layouts.

With flap it's harder as there are quite a lot of different use cases with it.

The "fullscreen header bar" case is covered by AdwToolbarView, so that's fine.

Utility panes can be covered by a new widget made specifically for those.

There are a few apps using flaps in really creative ways, like Apostrophe - those are gonna have to do it in tree instead. :/

But one case that's rather surprising is using them as a sidebar, with split header bars and everything. Technically this can work just fine - I mean it's still a generic widget that doesn't care where your header bars are - you won't get anything fancy like window button integration, but otherwise no problems. However, the styles will be wrong - utility panes don't get the new sidebar style.

Now that's another point I'm not super happy with, so me and Tobias looked at styles to check if maybe utility panes can use the new styles too? And - well, they can. Just not when folded, but AdwDualPaneView also doesn't do it when folded.

And at this point I become kinda unsure - why is it 2 separate widgets. Because while sidebars and utility panes are indeed separate patterns in the HIG, the line between them is quite blurry.

From the HIG pov the main difference is whether the header bars are split or not. But that is not an inherent property of either widget, it's just how you use them.

Besides, for apps like Nautilus we'll likely want it to be sidebar on desktop and turn into a utility pane when folded. This is perfectly possible with adaptive states, but not trivial.

And then - a difference is whether it changes into browsing when folded, or into a transient sidebar.

Now, AdwBrowsingView still needs to implement swipes - it currently doesn't. And since I decided not to set clamped=true on spring animations there, I need to fix how AdwSwipeTracker calculates velocity - there's currently a bug there that's visible in Loupe - make a full swipe, so that the page is in the final position, then swipe further than that and release it - the page will still bounce. With proper timing this looks really weird - the page moves, stops for a few milliseconds, then keeps moving. This shouldn't happen.

I also still need to port AdwPreferencesWindow to that - currently it's still leaflet as it has API for subpages and it's kinda scary to touch that.

There are also smaller things - one of the features I'm a bit proud of is that the automatic back buttons automatically show the title of the previous view in their tooltip. However, there's no fallback for an empty title.

And finally, AdwDualPaneView is the one that needs the most work.

- It has a :pop-content-on-fold property that's unimplemented atm

- It doesn't implement GtkBuildable

- For sidebars it's common to have an empty title, this is a bit awkward to implement atm and there should be a helper in AdwHeaderBar

- AdwHeaderBar also needs a property to disable automatic window button handling

And otherwise I think that's it for these specific widgets.

Now, spacing. So, toolbars are supposed to have 6px padding on all sides, right? Well, that's not entirely true. It only has side padding, while top/bottom padding is instead margins on each button, each entry, each switch and each separator. And then we undo it for popovers, so that buttons like in Epiphany's menu don't have extra padding.

This may sound ridiculous, and honestly it is, but the reason is these 3 cases.

Honestly, we should probably just get rid of all 3:

- view switchers can just be always wide in header bars, nobody really likes the narrow layout there anyway. And view switcher bars - we can just make them taller and use the regular padding

- calendar and logs should be redesigned, they look broken anyway

Now, why does it matter for collapsing spacing? Well, undoing those margins for buttons, entries, separators and switches in this particular case would make that css even more complex than it already is, and basically unmaintainable. If it was just padding on the toolbar we could do it easily, but with that part in mind... Yeah, not happening.

So a few things happened since the last thread (https://neurodifferent.me/@alexm/109782999447988651)

A few people (mainly @brainblasted) have been trying the new widgetry in all sorts of apps. I've seen branches of:

- Contacts
- Fractal
- Patterns
- Telegrand
- Nautilus (!!!)

And I use Characters and libadwaita demo for testing myself.

This is probably the most widely-tested wip widget to date in libadwaita 😅

One of the missing pieces last time was undershoot style handling - if we have a flat header bar next to scrolling content, we need to add a border/shadow/whatever if content scrolls down.

I'm not going to detail the problems because I already did it last time (see https://neurodifferent.me/@alexm/109783084155319601), but we ended up with yet another widget replacing GtkBox for this.

The preliminary name for it is AdwToolbarView (I don't particularly love it but don't have better ideas), and it actually allows us to do quite a few other things aside from "make header bars in dual pane view not look borked", even when header bars are not flat:

- Add a window handle to the full thing so search bars etc are automatically draggable - currently they are not even though they look connected to header bars

- Get rid of the borders between header bar, search bar, tab bar etc, like in this mockup: https://gitlab.gnome.org/Teams/Design/os-mockups/-/blob/master/tabs/tabs-borderless.png

- Get rid of double spacing after getting rid of the borders, again like on that mockup. This part is complicated though, I'll explain why in the next toot.

- Have a shadow on the header bar. We never did because if you pack it into a box it will go below the window contents and not above - in a vertical box widgets are drawn top to bottom so header bar is rendered before content, along with its shadow

- Have a property for extending content underneath it. At this point one can use it instead of flap for things like Epiphany header bar in fullscreen.

So while I was not enthusiastic about having a widget for this initially, it seems to be working surprisingly well in practice.

Another layout this leaves in the dust is tabs that are attached to a header bar but aren't full width. For example, in Nautilus. This was the original reason the tabs mockup wasn't completely implemented and kept the border btw.

Devhelp is another app with the same pattern, though it's still using GTK3 and GtkNotebook. But well, they can both switch to split header bars, all of this stuff is gonna be opt-in anyway - by using the new widgets.

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