GNOME Bugzilla – Bug 764802
EPortEntry too large
Last modified: 2016-11-22 19:06:28 UTC
The port box in the account editor looks wrong. The drop down arrow is in the middle instead of to the right. http://i.imgur.com/Z99EEm7.png
Thanks for a bug report. I made some debugging and it's a regression in the GtkComboBox with "has-entry" set to TRUE. The EPortEntry widget defines its own get_preferred_width() callback [1]. The problem is that the internal GtkEntry child of the GtkComboBox reports its minimal and natural size as 167 pixels, and the combo-box itself its minimum size as 201 pixels. The EPortCombo wants a size up to 6 digits, plus the combo button, which results in the 82 pixels reported minimum and natural width from the callback. While the GtkComboBox respects the size (that's the reason why the combo button is placed "in the middle"), the internal GtkEntry doesn't respect it and is left with the 167 pixels width. The internal entry should respect parent size request, as it used to before the gtk 3.20. [1] https://git.gnome.org/browse/evolution/tree/e-util/e-port-entry.c#n229
Well, that's not how,it works. A container needs to respect the size requests of its children. You can't simply override get_preferred_width and impose a small width and expect that to work.
Right, in general, but the GtkComboBox is not a general container, it's a combo box and the entry is sort-of an internal child, not a general child. For me, the GtkComboBox is the widget and that it uses a GtkEntry as something inside itself is an implementation detail (which the library user can depend on). The thing is that the GtkEntry inside the GtkComboBox is not a general GtkEntry, the same as GtkComboBox is not a general container. Anyway, if this is not going to work (and note that this worked since gtk 3.10 or even earlier, but only gtk 3.20 broke it), then what is the correct way of achieving the right behaviour with the gtk 3.20? (And no, I do not like conditional compilation, but if there's no better way...)
but the combobox doesn't know that you decided to impose a smaller size; how could it do something to fix up the entry ?
I do not know, I'm not a gtk+ developer. The only thing I know is that it worked for years, until gtk+ 3.20.
*** Bug 765591 has been marked as a duplicate of this bug. ***
*** Bug 767725 has been marked as a duplicate of this bug. ***
*** Bug 769990 has been marked as a duplicate of this bug. ***
Downstream bug report about the same from Fedora 25/gtk 3.22: https://bugzilla.redhat.com/show_bug.cgi?id=1395072
With Company's help on the gtk+ IRC channel, it's enough to set entry's width-chars to 5, which I'm going to do. Created commit fb73820 in evo master (3.23.3+) Created commit 758f53a in evo gnome-3-22 (3.22.3+)