GNOME Bugzilla – Bug 342113
Ellipsizing column headers ellipsize too eagerly
Last modified: 2018-02-10 03:21:48 UTC
If you put an ellipsizing label in the treeview column header (or enable ellipsis on the internally created label -- yes, I know it's bad but anyway) the column header is ellipsized way too much. Even if there were sufficient space for the whole label, it is ellipsized almost completely. The culprit seems to me the GtkAlignment x/yscale settings which never allocate the label more space than it requested. And since ellipsizing label only requests enough for the ellipsis... Setting the x/yscale to 1.0 ought to be the right thing to do here. ...though it brings up another issue, namely that then the label alignment doesn't match the column alignment -- even if the column alignment is set to 0.0 the label is then actually centered. I'd argue that if the child is GtkMisc then its alignment should be updated to match the column alignment.
Created attachment 65668 [details] testcase
Created attachment 65669 [details] [review] proposed patch
I see why both changes are needed, but I am afraid that this is going to break things for non-GtkMisc widgets ... Matthias, what do you think?
Shouldn't the GtkAlignment handle it correctly for non-GtkMisc widgets? GtkMisc is special only because it has it's own alignment handling in addition to GtkAlignment?
Seems my patch breaks right-aligned hbox and also right-aligned ellipsizing label. Then again, from what I can tell ellipsizing labels in the header directly or inside an hbox are completely borken anyway already.
Seems that aligning ellipsising labels anywhere but left is already broken, see bug 332604
(In reply to comment #4) > Shouldn't the GtkAlignment handle it correctly for non-GtkMisc widgets? GtkMisc > is special only because it has it's own alignment handling in addition to > GtkAlignment? I think you're right, setting the alignment on the GtkMisc is just to set the contents of the GtkMisc aligned nicely too. So I guess the status is that the patch is okay, and the right-aligned labels are broken by 332604?
*cough* of course it's okay *cough* :) I had strangely behaving header using HBox(GtkImage{expand=False), GtkLabel{ellipsize=END, expand=TRUE, xalign=1.0}) (the column aligned to 1.0) -- the label expanded to fill the whole space and the icon remained left-aligned. But I can't tell whether that is bug 332604
Created attachment 112535 [details] [review] Updated patch to trunk I updated the patch since it didn't completely apply on trunk anymore and I tested it with the provided testcase. Kris, would you have another look at it?
Comment on attachment 112535 [details] [review] Updated patch to trunk >@@ -933,6 +934,14 @@ gtk_tree_view_column_update_button (GtkT > "gtk-alternative-sort-arrows", &alternative, > NULL); > >+ if (GTK_IS_MISC (current_child)) >+ { >+ gfloat yalign; >+ gtk_misc_get_alignment (GTK_MISC (current_child), NULL, &yalign); >+ gtk_misc_set_alignment (GTK_MISC (current_child), >+ tree_column->xalign, yalign); >+ } >+ This code section has to be taken out of "if (tree_column->show_sort_indicator)". The alignment of the misc will always have to be updated -- regardless of whether a sort indicator is shown or not. I would put it right before the "if (tree_column->show_sort_indicator)". In general I am still unsure whether to commit this patch or not. It does handle things just fine for GtkMisc-widgets. For non-GtkMisc-widgets things will break. You would say that the alignment will handle it fine for non-GtkMisc-widgets as Tommi says in comment 4. The problem here is not the horizontal alignment, but the change of xscale/yscale to 1.0. Before, the child widget only got the space it requested and the alignment then aligned that element in the column header. With the patch, the child widget gets allocated as much width as the column's width and thus the alignment property does not have any more effect. I consider this as a break in compatibility. It fully depends on what people stuff into column headers these days. I know of people putting their own specialized widget in there, which does not necessarily have to be a GtkMisc. Such cases will be broken. (I think in the general case people only put GtkLabel/GtkImage in there, which are both GtkMisc and thus work fine after the patch). As said, I am doubtful whether to commit this -- it depends on whether we want to maintain strict compatibility or accept a little breakage. Anyone with a strong opinion here?
We're moving to gitlab! As part of this move, we are closing bugs that haven't seen activity in more than 5 years. If this issue is still imporant to you and still relevant with GTK+ 3.22 or master, please consider creating a gitlab issue for it.