Re: a new combo box

[Matthias Clasen <matthias clasen gmail com>]

On Sat, Dec 27, 2014 at 12:59 PM, Tristan Van Berkom
<tristan upstairslabs com> wrote:

> It's really not that bad, combobox is currently < 6k lines of code which
> is really not much for all that it does, sure we could afford to do a
> bit less (like dropping the crazy tabular menus).

Tbh, thats only true after your shoved off 2000+ lines to gtktreemenu.c.

> Honestly I would have rather proposed to just switch the whole internals
> of combobox to do the more modern looking thing using cell areas, which
> strikes me as the obvious way forward, bringing a new look to the combo
> without dropping any of the value of combobox, and every app using
> combobox automatically benefits - only that it would probably result in
> breaking API.
>
> Frankly I don't appreciate this let's rewrite everything from scratch
> attitude, it doesnt show a whole lot of respect to the users of our API,
> who would, I think have a justifiable expectation that their usage of
> combobox would not be labeled as obsolete at least until GTK+ 4.
>
> Sure, exceptions can be made within reason for dropping huge important
> parts of GTK+, but let's stick within reason right ? Has this been
> discussed ? Has it been concluded that there is no way forward with
> the existing API ? Where is that discussion ? What is the rationale ?

Thats one of the hardest questions, isn't it ?

Deciding when a codebase that you've invested a lot of time and effort
into has grown too old and complex, and it is better to start from
scratch ? I'm often struggling with this, and stick to fixing things
up to 'preserve existing investment' far too long. Of course, starting
over is not a panacea: you may end up repeating old mistakes, and do a
lot of work just to end up in the same place you started from. On the
flip side, its a chance to revisit old assumptions that are deeply
embedded in the old code, add modern features without having to
force-retrofit them into ancient code (and cause collateral damage in
the process).

That being said, I think the case for GtkComboBox is pretty clear-cut.
It was doomed from the beginning by the mistake to force two pretty
distinct user experiences (option menus and combo boxes) into a single
widget. You've made a valiant attempt to clean this up with the
introduction of GtkTreeMenu, but it is still a mess. Another mistake
was to expose a data-driven API (with models and cell renderers) for a
widget that most of the time is used in non-data-driven scenarios.
We've later tried to patch up that mistake by adding the simplified
GtkComboBoxText. But since it is a subclass, it inherits all of the
api problems of GtkComboBox. Lastly, there's a number of ill-advised
APIs in GtkComboBox that make it very hard to do any new
implementation of the same api: tabular menus, spanning columns, etc.
Almost as if to prove the last point, your last major refactoring of
GtkComboBox already broke a bunch of those APIs (e.g. col-span-column
is not working anymore).

You'll be happy to learn that the "buildable API" of GtkCombo is
pretty close to compatible with GtkComboBoxText (I should probably
rename the active property to active-id to get even closer), so for
most users, switching from GtkComboBoxText to GtkCombo should be as
simple as s/GtkComboBoxText/GtkCombo/ in their ui files.

Since you are asking about discussions and conclusion, I'll state that
in my opinion, combo boxes should not use (even less expose in the
api) cell renderers and tree models. I believe that is pretty much
agreed upon between most people who regularly touch GTK+ code (with
the exception of you, possibly).  Speak up if you disagree.