The title of the tab is held by the GtkLabel child of the GtkEventBox and the GtkEvenBox is used to detect the mouse clicks on the label so tabs can be switched.
This all seems to work find, albeit it being a bit complex, with one exception - tabs with title text that is long are getting the title GtkLabel cut off instead of being resized to fit the label. From my tracking with GTK_DEBUG=interactive, it seems that the culprit is the GtkStack widget. At least, that is the deepest child, which has any effect on the overall tab title size when it’s changed manually. Changing the size of its children has no effect (by “size”, I mean the “[height/width]-request” property).
Can someone help me understand why parent widgets are not getting resized so the tab title is fully visible?
Thank you for the suggestion. I had already tried this with GTK_DEBUG=interactive but it doesn’t seem to work. Even if I set the [h|v]expand property of all of the widgets from the GtkOverlay down, there are still tabs that have their text cut off.
which is FALSE by default, so we can hope it may make a difference.
I tried to set it to TRUE, but it was not working for me. But maybe I did it wrong, as I have not much experience with Python. You may try that yourself.
Other idea was to replace the GtkLabel in the tab with another simple widget, to test if other widgets expand better than labels. GtkLabels may be special in some kind, as they have these ellipsize behaviour.
Tried that with no effect. What is even more interesting is that I can’t even click on the “Close” button. It behaves as if the Gtk.Overlay is the top widget in the tab and is top of the button preventing it from receiving events.
It would be great if some Devs jump in with some pointers.
Great. I wish all that would be better documented. It can be really hard to figure such things out, and this low traffic forum often does not help much, as ebassi is not always available, and I think he can not know all.
I was going to suggest you that now with the fine example code you could ask at stackoverflow, because that one has much more visitors. But luckily this issue is solved now.
Please post the working code example here, so that we can remember…
Well, I was too early with my declaration. As it turns out, the issue is not solved.
The same happens with any overlayed widged as with the original label. Any overlayed widget is not made to fit within the size of the main child but rather gets cut off.
At this point, a dev is required as this seems like a bug to me. Effectively, one has to guarantee that the main child widget of a GtkOverlay is bigger (or the same size) as any of the overlayed widgets.
It isn’t a bug.
It makes no sense to have any overlaying children that are as big as the main child. If all of the main widget is hidden behind another widget, then it’s pointless to put that main widget on the screen, in the first place!
GtkOverlay’s purpose is to allow a widget to obscure only a part of another widget. Therefore, all overlaying children must be smaller than the main child. An application programmer must make them smaller if it’s needed. (Only the programmer can know how much smaller. Only that one can know how much of the main widget that one wants to stay visible.)
I am not sure that I agree with your point. According to the documentation of the “get-child-position” signal emitted by a GtkOverlay widget, the child alignment can be GTK_ALIGN_FILL, in which case, the child widget can be full height/width.
Furthermore, it doesn’t even make sense to have such a restriction. If a widget can partially block the main widget, why can’t it fully block the main widget. I get the “why show it at all” argument but consider that the overlay widget might not “block” the main widget.
For example, in my application the overlayed widget is a GtkStack, which has a empty label and a progress bar. Then I switch which part of the GtkStack is show, creating the appearance that the tab label has a progress bar that shows some activity. In this case, the main widget (the tab title label) is not really hidden.
So, I still maintain that this is a bug. If nothing else, it’s a documentation bug, although, not in my mind. I might be able to work around it using the “gtk-child-position” signal but the natural behavior definitely does not follow my expected behavior.