Re: GtkComboBox size allocations magic?

Tommi Komulainen wrote:

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 ;)



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]