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 <[EMAIL PROTECTED]> Date: Sat, Sep 27, 2008 at 5:31 AM Subject: Re: Minutes of the GTK+ Team Meeting - 2008-09-23 To: Gtk+ Developers <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-devel-list _______________________________________________ Sugar mailing list [email protected] http://lists.laptop.org/listinfo/sugar
