Re: GtkComboBox size allocations magic?

[Kristian Rietveld <kris imendio com>]

Tommi Komulainen wrote:
> Hi,

Hello Tommi,

> I've been trying to figure out how gtkcombobox handles size allocations
> and I'm puzzled, it seems to have some very interesting magic involved.
> I guess the '/* WELCOME, to THE house of evil code */' isn't kidding. I
> was hoping maybe you could clarify some of issues here?

There's quite some magic involved, especially when switching from list 
to menu mode and vice versa.  I haven't looked at the code for years 
though, unfortunately.  Nevertheless, I hope I can provide you with some 
useful answers.

> Anyway, for one in menu mode combobox seems to be managing allocations
> for its arrow and separator grandgrandchildren, overriding the GtkHBox
> inside GtkButton. Why is that? Shouldn't the button/box be able to
> handle the allocations?

I think the real answer here is that I started out with writing the list 
mode code where I had to do the requisition/allocation myself.  After 
that I started looking at the menu mode code and as a "logical" 
consequence I also added requisition/allocation code for the menu mode 
(from what I remember I never looked at doing this with just the HBox). 
 However, doing our own size req/alloc here does give us the power to 
tweak it to our needs.

> The other thing is BONUS_PADDING, 'focus-line-width' and 'focus-padding'
> that are used in seemingly random fashion. For example
> gtk_combo_box_remeasure() and gtk_combo_box_calc_requested_width() are
> calculating more or less the same thing (one for one row, the other for
> all rows) but they take (some) padding into account very differently.
> What is the difference between those calculations?

BONUS_PADDING shouldn't have existed in the first place, I think.  It's 
only used by gtk_combo_box_calc_requested_width(), and probably to make 
up for the padding around the cell contents in GtkTreeView, which is 
really space for the focus rectangle + vertical/horizontal-separator. 
In this function also focus-line-width is added to the width, which is 
probably wrong since size request should take care of that (and 
differently for both menu and list mode).  The other usages of 
'focus-line-width' and 'focus-padding' seem to be correct.

It looks like we should get rid of gtk_combo_box_calc_requested_width() 
(which is only used to get a width to _set_size_request() on the cell 
view).  gtk_combo_box_remeasure() and gtk_combo_box_size_request() 
should be perfectly able to take care of this.  The size requisition and 
size allocation functions also seem out of sync ...

I think it would be good to file a "Check/sanitize GtkComboBox sizing 
code" bug, so we don't forget about it and can look at it later.

> I guess the intent (somewhere) is to get the currently active text and
> the text in the popup nicely aligned. This seems to be happening with
> GtkComboBoxEntry but not really with GtkComboBox, both in _new_text()
> mode (it's much more visible if you exaggerate xthickness.) I think
> there are some assumptions about certain pixels measurements which
> happen to be true with default theme, but not necessarily others.
>
> Shouldn't the combobox be checking the theming done on the popup
> window/frame/scrollbar when calculating its own size requests?

That wouldn't be a bad idea.  As said earlier, the power we have to 
tweak our size req/alloc for both cases will probably help here to make 
it look nicer ;)


regards,

-kris.