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

[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.

regards,
--mitch