Re: a new combo box

[Kristian Rietveld <kris loopnest org>]

> On 27 Dec 2014, at 18:05, Sébastien Wilmet <swilmet gnome org> wrote:
>
> On Sun, Dec 28, 2014 at 12:50:24AM +0900, Tristan Van Berkom wrote:
> > In any case, I think this misses the point I was trying to make, I think
> > someone had to raise the obvious question: is it justified to bring in a
> > whole new combo API ? Or can we / should we get the most out of the API
> > we have ?
>
> Yes, it was more a side note.
>
> As a comment says at the top of gtkcombobox.c:
> /* WELCOME, to THE house of evil code */


I vaguely recall pushing a commit to remove exactly this comment, but I see it never made master. Sorry about 
that.

Anyway, in light of this discussion the comment is interesting. The comment was actually added right from the 
start of the code and not after years of adding new features. I believe it was born out of frustration (and 
immaturity).

The big problem is that GtkComboBox implements two widgets at once. Back in GTK+ 1.x we had a GtkOptionMenu 
(menu-based) and a GtkCombo (list-based). High on the wish list in the beginning of the GTK+ 2.x series was a 
widget that could handle both styles *and* be able to switch between these styles at run-time with the toggle 
of a style property. This became GtkComboBox and it essentially implemented all event handling logic and 
child widget rendering logic (for showing the “sample” (the selected item) and the arrow) twice and 
additionally had code to transform between these two at run-time. We also added the possibility to add 
another random widget as “sample widget”, not limited to GtkEntry.

In retrospect I believe the two-in-one approach was a bad design decision. It would probably have been better 
to implement the list-based and menu-based variants as specialisations of a base class and somehow implement 
the logic to switch between these two at run-time. This would also have made it easier to add additional 
styles such as the one proposed.

So in summary, GtkComboBox is highly flexible but only in terms of contents as you have to stick to the 
default list and menu styles. The proposed design seems to have a new style and limited possibilities for the 
contents. I believe it will be very hard to map this to GtkComboBox API as it stands now, making replacement 
pretty much inevitable as Mattias has mentioned.


On the other hand, I agree with Tristan’s approach to avoid complete replacements of existing code (widgets). 
To make this a possibility, I believe you need a framework to allow the existing widgets to evolve: parts 
have to be deprecated and removed, parts have to be changed (shoving in new base classes), and new parts are 
added. GTK+ does not have such a framework, because there is no set cycle for the change or removal of code 
(ABI break), you can never complete the required clean up to be able to implement new functionalities or 
styles. But I am touching on a controversial topic now, so I will stop right here ;).



regards,

-kris.