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

[Marco Pesenti Gritti]

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