> good luck finding out that the "problem" is "show-arrow” = TRUE

Well, now you don't need luck, because I've documented all that, in response to your other tickets. I agree that the documentation was lacking and the behaviour unintuitive. Now the documentation is sufficient, so the behaviour is obvious.


> The default of the property "show-arrow” should be FALSE

This 100% cannot change in GTK+ 3, ever, so that version tag needs to go. GTK+ 3.22 is intended to be feature-stable, and while really useful new features may get in, existing features cannot be changed. Trust me - that hasn't worked well in the past. Hence the commitment to users to maintain API stability in 3 now.

As for GTK+ 4, I don't really see a problem here, or at least one that's worth solving; while GTK+ 4 could change this, it would require all users porting their apps from 3 to 4, who are currently exploiting the default value, to explicitly specify it to override the new default.

...which seems like making existing users do work they didn't expect, just so that new users could get the behaviour they expect without having to read the (now fixed) docs. I don't think either of those are good, without more reason.

That's not to say all existing defaults are ideal, but they're what we have, so they're unable to change in GTK+ 2/3 and possible highly inconvenient in GTK+ 4.

To me, the answer is to improve documentation. I try to do that when, like you, I run into confusing situations. If you have any other suggestions about how we can do that, bug reports for the docs are more than welcome. So, if intuition can't always suffice on its own, at least we can point out the 'gotchas' where needed.

Yes, this definitely would be a request for GTK+ 4, not for GTK+ 3.x

While of course it is real nice to have improved documentation, and I appreciate your commit, I think it is even more important to dont provide pitfalls in the first place and meet user-expectations.

A different approach to simplify porting to GTK+ 4 could be to mark the current gtk_toolbar_new() as deprecated and provide a new gtk_toolbar_new() which has "show-arrow" as argument.
Like that a port to GTK+ 4 would show a warning at compile-time.
For new users that would not be perfect, but at least it would increase the chance that they read the doc of the "show-arrow" argument and see it's implications.

Actually I think it should be no such big deal to debug "the arrow does not show" after a port to GTK+ 4
IMO just having "show-arrow"=FALSE as default would be the better design.

It is a weighing: How much work will porting be for all existing Toolbar-Users vs. How much trouble will arise for all users to come in the future

(In reply to alexxcons from comment #3)
> A different approach to simplify porting to GTK+ 4 could be to mark the
> current gtk_toolbar_new() as deprecated and provide a new gtk_toolbar_new()
> which has "show-arrow" as argument.

This is C, not C++. Function overloading does not exist here.


> Like that a port to GTK+ 4 would show a warning at compile-time.
> For new users that would not be perfect,

The library itself would fail to compile, so no, it wouldn't be perfect at all.


> but at least it would increase the
> chance that they read the doc of the "show-arrow" argument and see it's
> implications.

The summary of the widget makes these pitfalls clear now, too. I was careful to do that, so that the info is available up-front, without requiring them to scroll/search all the way down to the docs of a nominally unrelated property.


> Actually I think it should be no such big deal to debug "the arrow does not
> show" after a port to GTK+ 4
> IMO just having "show-arrow"=FALSE as default would be the better design.

So, because you think it's better, existing users should suddenly have extra work to do, but it's OK as we can just tell them you said it was no big deal?


> It is a weighing: How much work will porting be for all existing
> Toolbar-Users vs. How much trouble will arise for all users to come in the
> future

I don't think much trouble will arise for new users, now that I've documented the less obvious bits. If they can't read at least the summary of the widget before using, I'm afraid I don't have much sympathy. Of course things should be easy to use, but we should expect a certain level of initiative and self-study.

And again, I'm not convinced that sparing new users the expectation of reading the docs justifies suddenly burdening existing users with inflated windows, no overflow menu, and some tedious work that they didn't expect.


But hey, let's wait and see if anyone else has a different opinion.

(In reply to Daniel Boles from comment #4)
> (In reply to alexxcons from comment #3)
> > A different approach to simplify porting to GTK+ 4 could be to mark the
> > current gtk_toolbar_new() as deprecated and provide a new gtk_toolbar_new()
> > which has "show-arrow" as argument.
> 
> This is C, not C++. Function overloading does not exist here.

And if you meant adding e.g. gtk_toolbar_new_with_maybe_arrow(gboolean) or gtk_toolbar_new_without_arrow(void), then firstly, yuk, and secondly, as always you can already just use

  GtkWidget *toolbar = GTK_WIDGET (g_object_new (GTK_TYPE_TOOLBAR, "show-arrow", FALSE, NULL));

if you really want a single line/call instead of having to reset the property in a 2nd.

More simply, I would argue that the default *is* correct, for these reasons:

 * How many applications have you seen that insist that their window must be
   wide enough to show every item in the toolbar? instead of letting it shrink
   and providing arrow-style button to get at the now-hidden items. I bet the
   answer is not many at all. So it makes sense that this is the default.

 * Most people will be adding ToolButtons, which already provide proxy menu items,
   making this a non-issue.

It does seem odd to me that we don't have a GtkToolLabel, which could serve as a menu heading once overflowed, but them's the breaks.

If you'd like to make one - since your initial problem was with a disappearing, non-overflowing label - then it's probably not the worst idea in the world, and should be simple to implement!

some more food for thought:

What it really seems you want is not a Toolbar, but instead a general container - which, when shrunk down so far that a child at the end can't fit inside it, would unparent that child from itself, to an 'overflow' Menu or (preferably, since menus aren't generalised containers) a Popover. This avoids having to provide proxies or duplicates of each possibly-overflowing child. It could have a child property that would stipulate whether or not each child should be shown in this overflow popup. 

But that's a more general thing than GtkToolbar aims to do, so it would need to be a more generalised container accordingly. Implementating it may be quite complex.

I dont think we should change the default here