This widget is similar to a GtkStatusBar but more compact, and works as a GTK overlay child ( typically with a view as overlay parent ). Since the widget is an overlay child, it’s always rendered on top of the parent view, hence saving space for the apps using it.
This widget is part of nautilus project, and not standard GTK. The widget code ( 'nautilus-floating-bar.[h|c]' is currently duplicated and used by the following projects ( at least as far as I know ):
GTK 3.x is frozen, so no. GTK 4 - possibly? but given it’s a pretty GNOME-specific thing (elementary have their own implementation that behaves differently, xfce etc probably won’t want that to begin with) it would make more sense to have such a widget in https://gitlab.gnome.org/exalm/libadwaita/-/issues IMO.
That’s questionable. The floating bar covers the last row of the list, and it makes it harder to read its contents on smaller windows.
Additionally, it’s not “a widget”: it requires structuring your UI using an overlay, and then adding the bar to the overlay widget. This means you need to have a specific hierarchy, which is not something that’s typical to how GTK is structured.
Moving mouse cursor over the floating bar reveals the contents below.
By comparison, similar argument holds true for GtkScrollbar overlays, which hides content of the last row / column. So, the question really is, whether the advantages outweigh the minor limitations for the given use case.
That’s currently true.
Maybe, make the widget work in normal mode ( no overlay support ) by default, and overlay mode with a gobject property ?
Well no, what ebassi said applies regardless of whether it’s toggled with a property or not. If you want an overlay of any form, your scrolled window will have to be a child of this widget (if it’s an overlay+floating status widget; if it’s just floating status, you’ll have to manually put it into an overlay)
Of course, why wouldn’t it be possible? It’s also a lot easier in 4 than in 3, as you don’t need to care about how hover conflicts with random child GdkWindows and it just works.
I really hope it’s easier in gtk4. The overlay pixbub animation that follows the end of the progress bar was tricky.
Had to use box container with a 1 pixel panning to keep the progress bar away from extending to infinity. That was increasing the window height at the same time.
Other than it’s an overlay nothing.
Border-image will be a static image even if it’s animated gif. It will change all of the borders and I prefer having borders unaffected. And the image can be in the center or moved anywhere. It can stop at 90% of the progress bar or whatever I imagine.
It doesn’t have to be an GtkImage of course, it can be a GtkButton in the center of the progress bar to cancel the action. Or some other widget, even floating bar displaying percentage.
Here is the gif:
hhh.gif
and the code:
