Re: a new combo box

[Tristan Van Berkom <tristan upstairslabs com>]

On Sat, 2014-12-27 at 18:05 +0100, Sébastien Wilmet 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 */

Sorry for not having removed that comment after spending significant
time cleaning that up myself.

> If it's the reason why new APIs are created instead of cleaning
> internally the code, then the risk is to repeat the history every 10
> years, deprecating endlessly APIs. Every code base evolves. At the
> beginning a new class is (almost) always clean, but years after years
> when more features are added the code becomes harder to understand, and
> the risk is that it becomes "evil code" that nobody wants to modify, if
> no refactorings is done regularly.

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

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 ?

Cheers,
    -Tristan