Replace GtkToolbar with GtkBox for gtk4

[bhennion]

This is an early draft, based on #4372.
Some things don't work yet, but the code base seems to be simplified quite a bit.

[bhennion]

I changed every GtkToolItem into a normal Widget and adapted them to the GAction business set up in #4372.
This allows to replace the GtkToolbar by any container we want, but I have encountered an issue with that.

Although the GTK 4 migration guide says we should just replace GtkToolbars with GtkBoxes, this creates an issue when resizing the window and the toolbar overflows. Here is a comparison of various solutions I tried.

• GtkToolbar (for reference): some of the items are put in an overflow box

  simplescreenrecorder-2023-09-09_12.35.03.mp4

• GtkBox: on some DE's, the window cannot get shrunk anymore once the toolbar reaches its limit size

  simplescreenrecorder-2023-09-09_12.34.25.mp4

• GtkFlowBox: the overflow is put on a second line, but the width is homogeneous within a column, making things pretty ugly

  simplescreenrecorder-2023-09-09_12.36.37.mp4

• GtkScrolledWindow: Adds a scollbar to the toolbar

  simplescreenrecorder-2023-09-10_18.02.26.mp4

I'm not quite sure what a good solution would be. I could not find any Adwaita container doing to trick either, implementing our own container with a decent overflow mechanism (like in this post) looks like a hassle.
We could put the toolbar in it's own GtkScrollWindow so it'd get a scrollbar if the width is too small but it's not quite satsfactory either.
@xournalpp/core Any ideas?

Edit: added the GtkScrolledWindow video

[Febbe]

Did you use the "toolbox" style for the GtkBox, and checked that it has not been overriden somehow?

[bhennion]

Did you use the "toolbox" style for the GtkBox, and checked that it has not been overriden somehow?

I tried that, but I don't think this could influence the overflow/wrapping of children in the box. Running ack toolbar in the gtk sources seems to indicate it is just a css class added in gtk4 to make the GtkButton's and other descendants of the box to look like they used to as GtkToolItem's in gtk3. It's not going to change how the box lays its children out.

[Febbe]

I think implementing our own version is the only satisfactory version (for gtk3). I don't know how the box behaves in gtk4. It may be that it is implemented in an expected way, because the box is supposed to replace the toolbar. If that's the case, I would just use a scrollbar (maybe hide the scrollbar itself). This is the most flexible, nice and fast solution.

[Febbe]

Playing with the gtk_box_set_homogeneous() might also do the trick

[bhennion]

I think implementing our own version is the only satisfactory version (for gtk3).

We could do that for gtk3 but whatever we come up with will need important work when actually switching to gtk4 (with the GtkContainer abstract class being removed and the new LayoutManager business). Not sure it's worth it.

I don't know how the box behaves in gtk4. It may be that it is implemented in an expected way, because the box is supposed to replace the toolbar.

No it's not. I tried it out by playing with gtk4-demo 's Builder example. They set up a toolbar, add a the right css class and a bunch of buttons. Same behaviour as in Gtk3.

[bhennion]

I added a video with scrollbars in the post above. The looks can of course be tuned via CSS.

[rolandlo]

I find the GtkScrolledWindow solution quite acceptable. It has some advantages over the overflow menu (where for example we don't see the color for a menu corresponding to a color toolbar button.
In the long run we'll probably experiment with progressive disclosure and don't display so many buttons at once. From the Gnome HIG:

Don’t overwhelm people with too many elements at once. Use progressive disclosure and navigation structures to provide a guided experience.

[bhennion]

I find the GtkScrolledWindow solution quite acceptable. It has some advantages over the overflow menu (where for example we don't see the color for a menu corresponding to a color toolbar button.

I can split this PR into two parts. In the first part, I'd only put the refactoring of the buttons so that

• they use the GAction business (necessary for the GMenu business, necessary to remove the GtkMenuItem menubar),
• they are normal buttons wrapped in a GtkToolItem so removing the wrap will be very easy (see 9394f84)

The second part would essentially contain 9394f84
This way, we'd leave the GtkToolbar arch as long as necessary for us to grieve their deprecation and settle for the next best thing.

If you try the version I just pushed without 9394f84, you get an overflow menu looking like this: