Post AIRX9JXOadomCu30jo by exalm@floss.social
(DIR) More posts by exalm@floss.social
(DIR) Post #AIRX9DEk15KafJH1pQ by exalm@floss.social
2022-04-14T01:50:41Z
1 likes, 0 repeats
I made a thing.There have been some talks about things needing to set insets on the window, and Danielle Foré had a Pantheon Mail tweet recently (https://twitter.com/DaniElainaFore/status/1511838960321904642). So I tried to figure out how we could actually nicely do insets like iOS does them.So, this is a pretty hacky demo, and yes, Nostalgia is already doing this, but I wanted to figure out how API for this could look like.
(DIR) Post #AIRX9FWXVskxl5cGqe by exalm@floss.social
2022-04-14T01:51:00Z
0 likes, 0 repeats
So, this is a pretty hacky demo, and yes, Nostalgia is already doing this, but I wanted to figure out how API for this could look like.
(DIR) Post #AIRX9HXK1wZS05zvLU by exalm@floss.social
2022-04-14T01:51:13Z
0 likes, 0 repeats
Before someone asks about blurring the content behind the top/bottom bars: no, that's not doable. Or rather, not doable in an efficient way - you would have to re-render the content for each blurred area - that's a no.This could be done properly if GTK had a separate layer for scrolling content, which it could pre-render, then selectively blur parts of it. It would still be non-trivial to implement, but would be possible at least - while right now it really isn't.
(DIR) Post #AIRX9JXOadomCu30jo by exalm@floss.social
2022-04-14T01:51:32Z
0 likes, 0 repeats
So what I really wanted to figure out here is how this could be done in a sorta-generic way. iOS manages it - if you add a UIScrollView, it will automatically adjust insets for the top/bottom bar, as well as the system UI. It also manages the UI radically differently from GTK.
(DIR) Post #AIRX9LObgHyZyDx1Jg by exalm@floss.social
2022-04-14T01:51:41Z
0 likes, 0 repeats
You can't seem to be able to manually position scroll views (??? at least I wasn't able to find out how to do that, correct me if I'm wrong), and the views are organized in such a way that having one scroll view per view is fine.In GTK though we often have multiple GtkScrolledWindows: sidebar next to content under the same header bar, multiple pages each with their own scrolled window etc. So this needs something more sophisticated.
(DIR) Post #AIRX9NBv0R0zXS1uoi by exalm@floss.social
2022-04-14T01:52:09Z
0 likes, 0 repeats
I'm _not_ uploading the code - it's too hacky and I'm honestly embarrassed to show this :p It could be done cleanly if it was inside GTK though.So the API is not fantastic but looks like this:- A widget that has a top bar, a bottom bar and content. Top and bottom bars have header bar/action bar styles, and actual header bars etc inside them have no background.
(DIR) Post #AIRX9PAvd5PZgxa9YG by exalm@floss.social
2022-04-14T01:52:35Z
0 likes, 0 repeats
(That's why there's no border between the header bar and search bar. @tbernard wanted to do this for tab bar and it really wasn't possible when those 2 widgets draw their own background and border and don't know about each other, so it's a nice side effect that it works here).- There's an interface for a widget that can have insets. It exposes public API to disable auto-adjusting top and/or bottom insets, and sorta-internal API for the inset widget to manage the actual insets.
(DIR) Post #AIRX9R0io0R3Nsp1v6 by exalm@floss.social
2022-04-14T01:52:54Z
0 likes, 0 repeats
- Here comes a hack. In an ideal world, GtkScrolledWindow could implement this interface and support insets in addition to the ones GtkScrollables provide via get_border() (used for headers in treeview/columnview).However, since this is a separate project, there's instead a widget that wraps a GtkScrolledWindow and adds insets. Yep. But again, it only needs to be this way if it's not in GTK. And yes, it's a giant hack.
(DIR) Post #AIRX9SszphRbCVDt9k by exalm@floss.social
2022-04-14T01:53:12Z
0 likes, 0 repeats
- There are similar wrappers for AdwPreferencesPage and AdwStatusPage as they contain internal scrolled windows. Again, in an ideal world those 2 widgets would just implement the interface. Same goes for GtkStackSidebar.- Finally, the widget itself implements this interface too, this way it can be nested and still work - notice how there are 2 bottom bars on the second page - that's how it's done.
(DIR) Post #AIRX9UreTfYbKubqL2 by exalm@floss.social
2022-04-14T01:53:45Z
0 likes, 0 repeats
There's a reason I'm talking in generic terms btw - all names are TBD. Leaving out the hard parts for later.So - that's it, really. Not everything works - e.g. GtkTextView still clips its text and it can't be shown over insets - but this can be fixed if it's in GTK.Similarly, WebKitWebView doesn't use GtkScrolledWindow and would need a separate treatment, but again - if this is in GTK, it could just implement an interface.
(DIR) Post #AIRX9WmlKopnIKKxzk by exalm@floss.social
2022-04-14T01:53:58Z
0 likes, 0 repeats
Dunno if I'm going to push for this, as I just needed to get distracted during a stressful week, but curiosity satisfied - it's doable.
(DIR) Post #AIRX9Yr5dhU5iKNS1A by exalm@floss.social
2022-04-14T01:56:03Z
0 likes, 0 repeats
Oh, forgot to mention an important detail. The widgets implementing the interface use a helper to automatically find an inset widget ancestor and register themselves. So this works semi-automatically; there's no need to register them manually.
(DIR) Post #AIRX9amuSDKRhwR8mO by exalm@floss.social
2022-04-14T02:01:53Z
0 likes, 0 repeats
And yes, if this looks weird in the sense that I previously implemented HdyWindow and pushed for making it possible to do random things with header bars in GTK4 and this might look to be the opposite of that with a fixed top bar area - it's not because this not a window - the inset widget is self-contained and e.g. for split header bars you could just put multiple inset widgets into a leaflet or a box. Or if you have back/forward navigation, each page could be such a widget. So it's fine. :)