[sugar] Breaking API (Fwd: Minutes of the GTK+ Team Meeting - 2008-09-23)

[Simon Schampijer]

Hmmm, this is a really tough subject. I guess that we have to guarantee 
some kind of backwards compatibility unless we are totally convinced 
that we fix something broken. I think we have to discuss concrete cases, 
with the thoughts below in mind, and see what we change and what we 
should not.

Best,
    Simon


Marco Pesenti Gritti wrote:
> I found this interesting while we are thinking about our API policy.
> Obviously Sugar is way less mature then gtk 1.2 but still we have a
> bunch of activities using it.
> 
> Marco
> 
> 
> ---------- Forwarded message ----------
> From: Havoc Pennington <hp at pobox.com>
> Date: Sat, Sep 27, 2008 at 5:31 AM
> Subject: Re: Minutes of the GTK+ Team Meeting - 2008-09-23
> To: Gtk+ Developers <gtk-devel-list at gnome.org>
> 
> 
> Even though the update to each line may be trivial, I would say that
> if a deprecation touches a lot of lines in every app, it really has to
> meet a high bar for worthwhile-ness, or we're just wasting a whole lot
> of people's time.
> 
> Deprecation should not be about aesthetics, or second-guessing the
> kind of judgment calls where maybe one way to do it is 5% better, but
> honestly it doesn't matter that much. Deprecation should be about
> fixing things that were previously impossible, or things that were
> outrageously inconvenient, or things that are unfixably broken. It
> should be enabling 100% better not 5% better.
> 
> A goal with 1.2 -> 2.0 was that many apps would recompile without
> changes, and many did.
> 
> Even with that goal, porting 1.2->2.0 was a huge effort and made a lot
> of people unhappy. Do not underestimate how much work app developers
> can easily end up with once a couple years of "small" deprecations all
> add up. Programmers don't like busywork.
> 
> On the specific issue of GtkBox: just leave vbox and hbox in there.
> They are hardly any code; they are not hurting anything; and why would
> you create an enormous amount of busywork for literally thousands of
> people to save, what, a 10K object file and 100 lines of source?
> Something on that order I bet.  It doesn't make any sense. So there
> are two tiny leftover source files. I'm sure in the time saved not
> redoing all their box code, app developers can find some more valuable
> optimizations than removing those files from gtk.
> 
> There's even a precedent from 1.2 -> 2.0:
> http://svn.gnome.org/svn/gtk+/trunk/gtk/gtkseparatormenuitem.c
> 
> How much has anyone suffered due to gtkseparatormenuitem.c? One of the
> box subclasses (whichever orientation is the default) should be the
> same size as gtkseparatormenuitem.c, and the other one should have 1
> more line in its _init() to set the orientation. Saving that code does
> not warrant changing tens of thousands of lines of application code.
> 
> Havoc
> 
> 
> (if one is compelled to hack on boxes, my suggestion is to leave
> GtkBox alone but add a new nicer container like HippoCanvasBox, its
> features include:
> * have left/right/center/fill x/y alignment
> * you only need 1 "expand" boolean, alignment replaces "fill" with
> something more powerful
> * support IF_FITS mode
> * support children that are requested/allocated but not shown
> * support setting four (painted or transparent) borders independently
> * virtualize the "content" of the box vs. the the layout part,
> enabling many widgets to subclass box and thus automatically be
> containers with alignment and borders
> * and yes, support dynamically setting orientation
> 
> Or whatever the nicer features are ... you could call the new
> container GtkLayout since that name is likely old enough to be
> recycled ;-)
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list at gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
> _______________________________________________
> Sugar mailing list
> Sugar at lists.laptop.org
> http://lists.laptop.org/listinfo/sugar
>