GNOME Bugzilla – Bug 521442
x/y thickness is being overriden by the combobox realize function
Last modified: 2008-03-16 02:17:49 UTC
Please describe the problem: The combobox realize function ignores thickness, for some reason this bug is not exposed in the most common engines, but on the windows ones it makes combo_box_entry to draw on top of the shadow. Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information:
Created attachment 106927 [details] [review] Proposed fix
Hmm, hard to say if this is correct. I don't see any visible difference when using this patch with testcombo and large x/ythickness. Can you show a screenshot of the difference ?
Created attachment 106958 [details] Combobox entry before and after the patch.
Thanks, looks right then. Please commit to both branches then.
2008-03-11 Alberto Ruiz <aruiz@gnome.org> * gtk/gtkcombobox.c (gtk_combo_box_size_allocate): Take thickness into account in the size allocation of the child widgets in list mode. Fixes #521442
It turns out that the patch didn't fixed the whole problem: There are two different scenarios depending on the "has-frame" value. * If it has frame, the child should be aware of the thickness of the frame. And the frame should be aware of the thickness of the combobox. * If it has no frame, the child should ignore the thickness of the frame and use the one from the combobox. The current patch totally ignores the first scenario and allways adds the combobox thickness directly. I'm going to propose a patch that fully fixes all my issues, but I think that there are open questions: The allocation assumes that if there is no shadow for the combobox, thickness is equals to 0, is that a correct assumption generally speaking? We're ignoring the ComboBox border at the moment (and in the patch that I'm going to attach I'm ignoring the frame border as well), my gut feeling is that I'm doing it wrong, but need some input.
Created attachment 107124 [details] [review] fixes thickness awareness for the child and the frame within the combobox
Created attachment 107136 [details] [review] This patch covers the GtkContainer::border-width property case I would say that this looks as the real patch. I tried to use gtk_container_set_border_width and it just does the right thing.
+ child.width = MAX (1, child.width) - delta_x * 2; + child.height = MAX (1, child.height) - delta_y * 2; This cannot be right, it defeats the point of doing the MAX in the first place. Probably more like MAX(1, child.width - delta_x * 2)
Created attachment 107205 [details] [review] Second take of the patch
Alberto, you probably did not mean to write: MAX (1, child.height - delta_y) * 2; did you? :-)
Benjamin, yes I did, that's why the patch I submited right before your comment was fixing that :P
Created attachment 107261 [details] [review] Third take of the patch Benjamin, you were right, I wasn't meaning that.
I assume these later assignments: + child.width -= delta_x * 2; + child.height -= delta_y * 2; probably also need the MAX(1, ...) treatment ?
The max thing is already in place, look at the very end of the patch text. The idea is not to call MAX everytime, but just at the end where it's really needed.
Ah, right. Then it is probably fine.
Revision 521442: 2008-16-03 Alberto Ruiz <aruiz@gnome.org> * gtl/gtkcombobox.c: (gtk_combo_box_size_allocate) The child is now aware of both the combobox and frame (if has-frame is set) thickness and border. (bug #521442)
I'll send an email to gnome-themes-list to make sure that there are no regresions out of this fix. If everything seems fine, I'll backport it to 2.12.