Conversation

Notices

1. Alexander Mikhaylenko (alexm@neurodifferent.me)'s status on Friday, 17-Feb-2023 16:17:26 JST Alexander Mikhaylenko

   • Chris 🌱

   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.

   • Adrian Cochrane repeated this.
   • Alexander Mikhaylenko (alexm@neurodifferent.me)'s status on Friday, 17-Feb-2023 16:17:31 JST Alexander Mikhaylenko

     in reply to

     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.