GTK4 and toolbar: how hard it is to bring it back

Applications
1

Hi,l ALL.
I’d like to revive the topic in Hope GtkToolbar back to GTK4.

From that thread going by the list of features as posted:

  1. icon_size: support large icon

You can select the icon size when adding an image to a GtkButton . You can also change it at run time.

It is easy with the SVG image - it will be scaled automatically.

  1. icon_position: left, top, right, bottom, center

Position relative to what?

Position relative to the top left toolbar point.

  1. label: show or hide button’s label

Icons and labels should not be mixed; in general, you either want text or you want icons for
commonly known operations . Too many icons lead to complex icons that are hard to remember.

Well, MSW have it, Qt have it, OSX have it, GTK… does not.
But then GTK is already unique, right? :wink:

This feature exist for a reason - it is possible that user doesn’t pick what the tool do and so text with the image will help. No need to go over each button and wait for the tooltip to show up.

  1. flat/ relief: set button as flat or relief

This is just a case of adding the flat class to the button.

I hope it is already being done.
But it just gives you guys more work for no particular gain. The dedicated toolbar already had it.

  1. image: always show icon while icon or image is set

I don’t know what is this.

  1. Arrow to scroll hide buttons

If you mean moving buttons to a menu in case the toolbar is too small, then I’d probably suggest
changing the UI; moving widgets around isn’t the greatest way to maintain positional memory,
which is what people tend to rely on more than icons or text.

No, that is not what (s)he means.
I presume that what is meant here is following.

When the frame becomes to small and the toolbar is present - then the toolbar displays a little down arrow at the end. Clicking this arrow brings up a pop-up with all additional tools nicely packed in a grid.
And I presume this functionality was not done by the user but by the GTK itself.

  1. Style to switch small or large icon

Again, this is mostly a case of styling your UI.

No it is not.
Users can switch between different sizes of the tools - one user can be blind and one user can not. And so first will have small icons and the second will have big.
Are you saying now this will done with 2 different GTKBOX classes and it will be switched during the run-time when the user selects one or the other.

All in all “toolbar” is an essential class in the application development and it has to be brought back.

On top of everything - I’d like to know how to code this from C/C++, not the CSS.
CSS should define the “styles” of the existing object in addition to the C API of GTK - meaning every single CSS style should have an equivalent of the C function.

However it turns out not to be the case here.

Thank you.

2

Sounds like you’re agreeing on this point?

You can use the halign and valign properties for this.

Of course it does. See Gtk.Button:child, Gtk.Label and Gtk.Image.

The toolbar CSS does also. See Gtk.Button:has-frame or Gtk.Widget.add_css_class() to set this programmatically.

It’s the obvious and default behaviour, so I’m not sure either.

I don’t believe that’s the case, but doesn’t seem to be in anyway specific to toolbars either way.

Yes it is.

We have accessibility features and themes for this use case, and again this unrelated to toolbars. If this is a required accessibility feature that is missing, it should be implemented for all applicable widgets.

No, that would be a very silly way to avoid using CSS or other available APIs.

Please see the documentation, and if there is something missing those issues can be discussed for what they are. This another case entirely unrelated to toolbars.

3

@oneeyeman1 Can you show your code and show specifically what you are trying to do? With a picture maybe? I am looking at the pictures in the previous topic and basically everything there can be accomplished with either a simple GtkBox or GtkFlowBox. There is no need for a special toolbar widget, it is not actually essential for those cases.

4

@andyholmes ,

  1. Not really.
    SVG scaling is done based on the monitor resolution. If the user so desire - (s)he can choose big/small buttons in the toolbar.
    But I’m not sure what the OP meant, so…

  2. I can use those properties for aligning to the left or right. What if I want something like “left center right” layout?

  3. Can I dynamically set/remove the text on those buttons?
    As an example - I create a “toolbar” with some buttons and controls, then after some time I set the text/labels on them, but didn’t like how it looked and removed it.
    Because remember - I can have controls in the toolbar as well and the text should appear below the buttons/controls there.

  4. I don’t care about CSS.
    In fact I believe that everything that can be done with CSS should be possible to do with the code.
    And so yes - add_css_class call is a solution for me.

  5. Apparently so, but OP didn’t bother to explain it. :wink:

  6. Not sure what you mean here:

I don’t believe that’s the case, but doesn’t seem to be in anyway specific to toolbars either way.

and what you are referring to.

When the main window becomes smaller so not all buttons/controls are visible in the toolbar, toolbar displays the little down arrow. Clicking on the arrow brings up a little pop-up which displays the missing buttons/controls in the grid fashion.

Are you saying that that was not done by GTK?
And why do you think it is not specific to the toolbar?

  1. No it is not.
    This is just a one use-case scenario.
    It just might be a user preference to have a big icons/controls in the toolbar. Or it is possible for the user to try it out.
    But this is not the styling thing. It is a configuration matter.
    How the program run and what it does is driven by the user requirements. If (s)he so desires, (s)he can choose the size of the buttons/controls, set which one will appear first and which one will appear last, whether the text should be displayed or not, or maybe even hide the toolbar altogether.

As you can see this is not styling but configuration matter.

And you guys push the user of the app to stick to only one design that will be hardcoded.

I hope you see the difference.

BTW, for me GtkToolbar was missing one very important feature - possibility of customizing it.
But since its gone now - this point is mute.

BTW2, all other OS/toolkit have dedicated controls for the toolbar. But this is not an argument for you, right?

Thank you.

5

@jfrancis ,

I’d like to keep GtkToolbar and I’d like to extend it with the possibility to customize it.
Rearrange the buttons, change the position of the tools, enable/disable too;tips/texts.

Can this be done with what you are proposing? WIthout re-creating the whole “Box” and calling “layout” function to recalculate all sizes there is?

Thank you.’

6

Sorry, I don’t understand the question. You don’t recalculate sizes, the GtkBox does it for you. You can just rearrange the children or iterate them to set the text/tooltip.

Then you are making things more difficult for yourself for no reason. The point of CSS is to simplify the C code. To implement the same code in C they would be many many lines of tracking widget state, sizes, colors, positions, etc. But with CSS you can reduce that down to a few simple calls to add_css_class and remove_css_class.

I don’t really see that. I am looking at the current HIG for Windows and macOS and I cannot see anything like what you are describing. They look like a simple bar with buttons, very similar to what can be accomplished with just GtkBox. Maybe you are thinking of other obsolete controls that came in the era before GTK4.

7

@jfrancis ,
You didn’t answer my question about possibility of customizing the “toolbar”.

How can you do that?
Do I have to implement the right click handler and make a context-menu with the “Customize…” item in it?

And I guess its OK - if the current HIGs do not mention old toolbar…

Maybe because developers are moving away from the old style GUI programming and make everything draggble (like docki/undock interface).

I can agree with that. It looks more modern. But with GTK - can you implement docking? Does GTK supports something like this?

Thank you.

8

I don’t remember the old GTK2 and GTK3 Toolbar widget supporting any of that by default either. If an application wanted customization or docking then they had to write custom code for that. Same as in GTK4, but if someone writes a widget for this then people can share it…

9

@jfrancis ,
Yes, neither 2 nor 3 had this feature.

That’s why I said - I’d like to have toolbar re-instated with this feature added.

But seeing that it will not, I have a different question.

is GtkBox a Window? Can it accept a mouse click? Or I have to have a Window in order to have this function?

On Windows it is available with double-click on the toolbar.
On OSX it is available thru the right click/menu option.

But this is with the actual toolbar control.

Thank you.

BTW, the HIG for OSDX said that the toolbar is residing in the title of the window. There is no mentioning that the toolbar is deprecated. The HIG still refer to it as a toolbar.
Windows HIG doesn’t mention a toolbar, because it is replaced by a different control. But then HIG is for the WinUI applications and not C/C++ one.

10

I should say first I’m not really disagreeing with @jfrancis, I’m just approaching the discussion from a bit of a different angle.

That’s not specific to toolbars though, and there are APIs in GTK, GDK and GDKPixbuf for working with scalable graphical elements.

You can also use hexpand, vexpand, and some widgets like GtkLabel have additional properties likexalign and yalign. There are also a number of widgets like GtkCenterBox, GtkGrid, GtkFlowBox with special behaviours for controlling the layout of children. And custom layout managers are also an option.

Of course.

As far as I know, GTK3 did not do this for you.

It is not specific to toolbars, because there are many situations where a widget’s children will overflow and need to be reorganized. This is why we have widgets like scrolled views, flow boxes, and so much work has been put into adaptive layouts for libadwaita.

Visual aspects that are not stylistic will affect non-visual ways of interacting with the UI, like keyboard focus order. This applies to almost every element in a UI, so definitely not specific to toolbars.

There is nothing a GtkBox with GtkButtons and other controls can’t do, that GtkToolbar could do, however there are plenty of things you can do with generic containers that GtkToolbar could not.

The reality of GtkToolbar is that it was an entirely unnecessary widget with imaginary semantics. A bar of tools is nothing more than a box of actions.

In contrast, you can’t replace a GtkToggleButton with a GtkButton, because a toggle button has real on/off semantics and states that accessibility tools need to express to the user.

We can all play the game where we name things that are in some toolkits and aren’t in others. If a feature is justifiable, then it should be possible to justify it without pointing at other toolkits. Otherwise the first toolkit with that feature could not have justified having it in the first place.

An appeal to popularity is not a logical argument, it is a logical fallacy. If other toolkits have justified these features with arguments, you should make those arguments and/or expand on them.

11

@andyholmes ,
One question remains thou.
Is GtkBox a window or a special layout class only.

If its a window then in order to implement a toolbar customization nothing else is required.

If its a virtual layout class - then I will have to make a window, place a GtkBox on top and then put some buttons/controls in the box. Then I will handle left/right click on the window and implement the customizing dialog. But then its easier to have a dedicated class for that that derives from the window and can handle the clicks for customizing.

Because, unfortunately users and developers do not think alike. And whatever we, the developers, think is useful and will be used often, users of our software have completely different angle and will most likely re-arrange or add/remove the stuff in the toolbar.

And yes - like I said “Its not an argument that all other OS/toolkit have it”.
It just going to be harder to write a good portable code that can be run on all platforms without introducing platform specific code.

Now, I’d like to discuss how to best implement it for the GTK HIG. Is it better to have it MSW way where users need to double click the toolbar or OSX way where the user needs to right click the toolbar?

Thank you.

12

If by “window” you mean top-level surface, then no, GtkBox is a widget that must be placed in a top-level surface like GtkWindow or another implementation of GtkRoot.

Top-level surfaces are top-level, so they can’t be put inside other top-level surfaces. Widgets must be placed inside top-level surfaces, so can’t also be top-level surfaces. There’s a fork in the road here and you can only go one way.

This sounds like you’re just talking about Drag-and-Drop, which already has first-class support in GTK4. Maybe you’re looking for a helper library like libpanel?

Do you have a real-world example of that being the case in GTK4? If so, that just seems like something that should be reported so GTK can handle it for developers.

The GNOME HIG addresses this generally with the design principle of Make it Simple, and specifically by describing recommended Patterns.

There is no discussion of toolbars in particular, because this style of modifiable UI is not encouraged, although GTK4 will always provide the tools necessary to implement them if the situation calls for it.

13

@andyholmes ,

If by “window” you mean top-level surface, then no, GtkBox is a widget that must be placed in a top-level surface like GtkWindow or another implementation of GtkRoot.

No of course not. Not the top-levbel one.
The old GtkToolbar was GtkWidget, which is a “window”, i.e. it can accept mouse clicks.
However it looks like GtkBox is also GtkWidget and so can accept a mouse clicks. And so it is not a class for layout purposes only and so this is mute now.

This sounds like you’re just talking about Drag-and-Drop, which already has first-class support in GTK4. Maybe you’re looking for a helper library like libpanel?

Not just.
There is also a possibility of bringing in the dialog to rearrange the tools in the toolbar.
Chevck for example this page: How to Customize Toolbars - Win32 apps | Microsoft Learn.

Do you have a real-world example of that being the case in GTK4? If so, that just seems like something that should be reported so GTK can handle it for developers.

No, I don’t.
But try to port any Win32 app to GTK4 that has toolbar/statusbar etc.

The GNOME HIG addresses this generally with the design principle of Make it Simple, and specifically by describing recommended Patterns.

Both ways I describe in my previous reply for MSW and OSX are quite simple.
However this is the basic stuff for the toolbar and I’m actually surprised that it is not designed and implemented in GTK.

There is no discussion of toolbars in particular, because this style of modifiable UI is not encouraged, although GTK4 will always provide the tools necessary to implement them if the situation calls for it.

This is not modifiable UI.
The modifiable UI would be when someone rearrange the position/size of the control - something that RAD tool does.

But this is not modifying UI.

14

GtkBox was always a GtkWidget, so that’s nothing new.

GtkToolbar never provided a flag like TB_CUSTOMIZE, nor did it include a built-in dialog like the one shown on that page. If libpanel doesn’t have what you need you’ll have to create it yourself.

Sorry, I must just not be understanding what you’re asking for. I just don’t see any way that reviving GtkToolbar from GTK3 would address anything you’ve been describing.

15

@andyholmes ,
The question is - how do I call it?

Should the re be dedicated menu and a right click context menu like in OSX or it should be a double click like in MSW.

Or maybe something else - like combining those 2?

GtkBox was always a GtkWidget, so that’s nothing new.

Looking at the name it sounds like this astrictly layout class.

GtkToolbar never provided a flag like TB_CUSTOMIZE, nor did it include a built-in dialog like the one shown on that page. If libpanel doesn’t have what you need you’ll have to create it yourself.

It should have been.
Again users and developers doesn’t think the same. And whatever we as developers think is most useful features may not be so for the users

Sorry, I must just not be understanding what you’re asking for. I just don’t see any way that reviving GtkToolbar from GTK3 would address anything you’ve been describing.

I guess I’m lost in the terminology here.
But probably since GtkBox is a window class, then everything should be good.

Thank you.

16

You’re applying GTK3 (really: GTK2) terminology to GTK4. In GTK4 there are no “window” and “no-window” widgets: all widgets can use event controllers to handle events. The only “window” widgets are top levels—i.e. GtkWindow and friends.

This has nothing to do with what kind of API GTK exposes to application developers. Windows does not a standard control to change a toolbar, either; it’s a construct provided by applications themselves. Application developers that decide to subject their users to that kind of functionality can implement it, by creating a window with two list views showing the available controls and the controls in use, and then update the tool box in the main window in response to that.

Incidentally: it’s a terrible user experience. For complex UIs, in the past 15 years (since Office 2007 and the creation of the ribbon the design direction has been to have the UI change itself to present context-dependent controls, and adaptive UIs that show the most used controls more prominently. The idea of people spending time to change the contents of a toolbar one button at a time is a fantasy that appeals to a certain subset of users—mainly, the app developers themselves—and has no bearing in user testing.

In any case, the toolkit has no obligation to give you this kind of UI; GTK already gives you all the necessary components to create it yourself.

17

@ebassi ,

You’re applying GTK3 (really: GTK2) terminology to GTK4. In GTK4 there are no “window” and “no-window” widgets: all widgets can use event controllers to handle events. The only “window” widgets are top levels—i.e. GtkWindow and friends.

So what would be the layoutr class then?
The one that is used explicitly to set the default position and size of the control/widget.

I thought that the UI design should be like this:

Main Frame -> Panel -> Layout class 1 -> Widget
                       Layout class 2 -> Widget
                       Layout class 3 -> Widget

where Layout class is responsible for placing the widgts on the panel and recalculate their position/size appropriately only. It shoud not be displayed on screen.

Are you saying that GtkBox and friends are responsible for that?

But they are windows, or in the GTK terminology, widgets. And so ARE displayed on screen.
So why does it need to be displayed if their purpose is to position widgets and not present them.

This has nothing to do with what kind of API GTK exposes to application developers. Windows does not a standard control to change a toolbar, either; it’s a construct provided by applications themselves. Application developers that decide to subject their users to that kind of functionality can implement it, by creating a window with two list views showing the available controls and the controls in use, and then update the tool box in the main window in response to that.

The dialog itself is part of the standard controls library. How do you call it is also on Windows (by default).
How do you create it and what you place in it is on the developer.
Yes, you can make your own dialog.

Yes, ribbons made the toolbars obsolete and the drag/pin pattern of the UI elements made it even more ancient. But the idea to provide the user with the possibility to set up the toolbar/ribbon/applicationbar/whatever is still here.

Like I said before - when the user starts using the software (s)he decides what is most useful and can rearrange the buttons as (s)he wish.

Thank you.

18

I think you should just jump in and start writing some code. When you get stuck on trying to implement something, or are not sure what the next step is, you can share that code and get some more direct answers.

That way there won’t be any confusion about terminology, or what toolkit features we are all talking about.

19

Hi, guys,

I have another question about this.

In GTK3 there is a signal called context-menu: Gtk.Toolbar::popup-context-menu.

What would be the equivalent in GTK4? Because there is no such signal in the GtkBox (see here: Gtk.Box)

Thank you.

20

That looks like a simple mapping from a right-click to a signal, so it should be replaceable by adding a Gtk.GestureClick to the widget and connecting to the Gtk.GestureClick::released signal.