Due to an influx of spam, we have had to impose restrictions on new accounts. Please see this page for instructions on how to get full permissions. Sorry for the inconvenience.
This is an archived project. Repository and other project resources are read-only.
We need to figure out the API though: since the window doesn't have titlebar area, you have to add one manually. For that I have a TitleBar widget that allows dragging, actions like double click to maximize (they follow settings) and Shell context menu (or a fallback for KDE etc). You're supposed to add this widget and put a headerbar or really whatever you want inside. Some cases I imagine could be common:
leaflet.horizontal (or deck or stack or box.horizontal) ├ box.vertical │ ├ titlebar │ │ └ headerbar.titlebar │ └ some sidebar ├ separator.vertical.sidebar (notice it's not draggable, we might want to have box with 2 separators) └ box.vertical ├ titlebar │ └ headerbar.titlebar └ some content
The common thing is: all the headerbars should have .titlebar style class on them. With GtkWindow you get it implicitly for whatever children was added with set_titlebar(). But here it won't happen because there's not titlebar, you have to do it manually. This is easy to miss because it usually works fine, until you want e.g. .devel style or you're elementary and don't have a proper style for headerbar without .titlebar.
We should really figure out how to do it automatically.
Since corners are masked, HdyTitleBar becomes redundant and could be repurposed for this. However, it can't look like headerbar, otherwise we break the last case in that list, and I want to keep these separate.
Otherwise we can add it to HdyHeaderBar, in that case HdyTitleBar can just be removed. This has a benefit of being easier to use, but is less flexible.
Since headerbar is just a regular widget in the unified widget hierarchy, it doesn't disappear in fullscreen, so to replicate the current behavior you would have to either use a revealer + margins on the main content, or we'll have to have a new widget (which I suppose could be shared with #202)
Other issues are:
Applying mask on a window is meh and IIRC was previously cited as the reason GTK doesn't do bottom corners. That said, I don't see performance issues here, but need to try on slower hardware.
We can't introspect border-radius other than getting one int value. Hence we can't have window without rounded bottom corners.
Window shadow normal<->backdrop transition doesn't animate and it doesn't look fixable
Keeping track of keep-above is surprisingly a lot harder than I expected. You'd expect that it would be reflected in gdk_window_get_state() bit mask, but it isn't, and so I track it manually, and it will go out of sync if you call gtk_window_set_keep_above() or gtk_window_set_keep_below() manually...
Another thing is that it's totally fine to nest the titlebar objects, so we could include it into HdyHeaderBar as an internal widget, and provide a standalone version for other use cases.
After a discussion with Company, mainly in context of GTK4:
Do dragging/menus in headerbar. If you need draggable separator, make headerbar somehow shrink
to that. For GTK4, move the things there altogether instead of having it in GtkWindow.
There are some things in GtkWindow that peek into the GtkHeaderBar set as titlebar. Yes,
it's broken with every app that uses e.g. a box or a stack there. Namely, syncing title, icon,
whether to show app menu.
GTK4 has gtk_widget_class_install_action() and Company wants to make window.maximize etc actions.
Then headerbar can just use those and apps that want something different can override them. That
allows for things like mdi using GtkHeaderBar that would actually work
Menubar:
if you want GtkApplicationWindow to keep the menubar, you have a problem
that said, IMO the menubar has always been bullshit and should just die
but it has been bullshit to me when people argued it's the best thing ever, so I'm not the one who's gonna kill it
but I'm gonna cheer anyone on who wants to
Company suggested having a bin widget that adds titlebar-like behavior, basically like what I have right now for custom cases.
A widget that shows either left or right side of headerbar, but this is out of scope at least for now
Maybe we don't want to do all of this for libhandy? The titlebar container should be enough I guess, and it turns out we have one already, we could just extend it.
Sure it's not exactly like what he suggests, but we don't need to do it exactly the same, we're still using GTK 3 here.
Agree, all of this is unnecessary. I think we should do it in HdyHeaderBar implicitly though, one of the problems I had is that's it's so easy to forget to put a headerbar into the container.