Re: Minutes of the GTK+ Team Meeting - 2008-09-23

[Christian Dywan <christian imendio com>]

Am Thu, 25 Sep 2008 22:20:17 +0200
schrieb Michael Natterer <mitch gimp org>:

> On Thu, 2008-09-25 at 15:07 -0400, Morten Welinder wrote:
> > If all you really want is to change the defaults for box packing,
> > then why isn't that all you are proposing?  It would be a simple
> > 1-line patch to gtk_box_pack_start_defaults, if I understand things
> > right.
> 
> Because I would never suggest a change that will break almost every
> single GTK+ application's layout even though these applications
> have done *nothing* wrong.
> 
> > Some thing will break if you do that, but nowhere near as many
> > things as with changing the default plus getting rid of hbox/vbox.
> > I suspect it would not be that many things, because most things
> > currently use the unaffected box packing methods.  This would be an
> > API break -- semantics changed -- but I don't think the impact
> > would be all that big.  Glade files, for example, seem to have
> > explicit shrink/expand data.
> 
> You didn't understand what I am proposing. The proposal to change
> the defaults is simply s side effect enabled by the deprecation of
> all current API to create boxes. There will be new API to create
> boxes, so there will be essentially a new widget, and this widget
> can have new defaults.
> 
> > If all the benefits is in changing the defaults, there is positively
> > no reason to run around and deprecate hbox and vbox.  If that part
> > has a secret benefit ("*huge*" or otherwise) then weigh that
> > against the pain for application developers.
> 
> If the pain is all you care about, I suggest you grep some source
> codes a bit. Gnumeric has like ten HBoxes and ten VBoxes in C code
> and a lot of them in .glade files. The C ones take half and hour to
> port, the glade ones take a regex. Where is the "pain"? It no more
> pain than any other deprecation.
> 
> > In other words: you seem to be proposing two separate things here,
> > only one of them has any stated benefit -- you say *huge*, I say
> > save-the-occasional extra line.  The other part no-one is even
> > trying to defend and it is clearly going to be painful for
> > application developers, especially for anyone targeting 2.x and 3.x
> > at the same time.  Drop that part asap.
> 
> (Asap, I see... thank you for sounding so refreshingly patronizing
> again)
> 
> I suggest instead that you drop the idea asap to target 2.x and 3.x
> at the same time please. This is just as insane as supporting 1.2
> and 2.x at the same time.
> 
> Have one branch for 2.x, have another one for 3.x.

All the fiery words aside... it seems more useful to compare a tree
that supports 2.12 and 2.16 right now, to one that supports 2.12 and
3.0 in the near future. And considering that there's a smooth upgrade
path as opposed to 1.x to 2.x, that doesn't seem all that foolish to
me. Of course it depends on the application, but it's fairly possible.

ciao,
    Christian