Conversation

Notices

1. Alexander Mikhaylenko (alexm@neurodifferent.me)'s status on Tuesday, 07-Mar-2023 04:34:36 JST Alexander Mikhaylenko

   in reply to

   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.

   • Adrian Cochrane repeated this.
   • Alexander Mikhaylenko (alexm@neurodifferent.me)'s status on Tuesday, 07-Mar-2023 04:34:36 JST Alexander Mikhaylenko

     in reply to

     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.

   • Alexander Mikhaylenko (alexm@neurodifferent.me)'s status on Tuesday, 07-Mar-2023 04:34:37 JST Alexander Mikhaylenko

     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.

     Adrian Cochrane repeated this.