Re: a new combo box

[Emmanuele Bassi <ebassi gmail com>]

On 28 December 2014 at 16:32, Morten Welinder <mortenw gnome org> wrote:
> This is the third (fourth) incarnation of a combo box and there is
> still opposition to keeping the API stable?  That's just crazy.

on the contrary: with a new class you'd be sure that the GtkComboBox
widget API is finally "stable" — as in "no changes, except for bug
fixes" — which is apparently what you want.

> Matthias' awesomeness aside, why would this be the last time?

it wouldn't. the only way to declare the whole of GTK "stable"
according to your metric of needing to never port anything ever again
would be to simply kill off the project, or go in deep maintenance
mode, and only do bug fixes that do not require new API. that's the
state in which GTK+ 2.24 is, incidentally.

as a project, GTK can either add new API and never deprecate anything
ever again — thus catering to the people that already have a sizeable
code base and don't need to change their UI because of an established
user base — but that would be confusing for new developers that come
to the API reference and see three different widgets covering 8
overlapping use cases, thus muddling up the developer experience of
the whole core platform. or GTK can deprecate older classes when it
becomes clear that the maintenance burden they impose is too high, in
the face of changing requirements and designs — which imposes
maintenance burden on application developers, something that happens
basically on every platform anyway.

we could introduce delayed or "soft" deprecations: we simply indicate
that a widget should not be used for two cycles (i.e. a year), to let
the new widget's API take shape and solidify, and then enable the
deprecation warnings. I'm sure we can introduce some pre-processor
macro that does this work for us. I honestly don't think never
deprecating stuff will ever work.

ciao,
 Emmanuele.

-- 
http://www.bassi.io
[ ] ebassi [ gmail com]