Re: Minutes of the GTK+ Team Meeting - 2011-01-25

[Tristan Van Berkom <tristanvb openismus com>]

On Tue, 2011-01-25 at 17:57 -0500, Matthias Clasen wrote:
> Minutes
[...]
> • cell layout initialization

I was not going to waste my energy *again* by participating
in this awful discussion that I heard roomers was taking place
at 6:60am this morning during the meeting (yes I was not yet asleep).

So to save myself the headache I went to sleep instead.

>   ∘ the general feeling was that the current situation (derived cell
> layout implementations have to know to do stuff in constructor instead
> of init) is not acceptable.

I am more inclined to believe that Company just believes this
very loudly.

However I have not heard any solid arguments that my_object_init()
should be the right place to start calling apis on 'self' or
go ahead and add children to 'self'.

Even though much GTK+ code *does currently do that*, it's only a
coincidence that it works well.

The more construct property dependant code that runs in superclasses,
the more we will run into situations where we finally realize that
_init() is not the place to do such things and that ->constructor() 
is the safe bet.

>   ∘ some of the concerns about the complication of changing cell areas
> at 'bad times' can be addressed e.g. by restricting this to unrealized
> widgets, or to views without models, etc.
>   ∘ the current patch to make cell areas runtime-settable is incomplete

Except that none of that headache of changing underlying areas "on the
fly" is really necessary.

Is there a reason that Claudio's suggestion went flying out of the
window ? 

It's far easier than trying to provide "runtime settable cell areas" 
and it has no complexities like unnecessarily making the areas
runtime settable does.

For those who dont know that proposal which was lost underneath
a thunderstorm of arguments, the plan of action I support the most
for making GtkIconView derived classes able to interact with
the cell area during _init() time is the the following:

 a.) Make gtk_icon_view_cell_layout_get_area() assign and
     return a GtkCellAreaBox if no priv->area exists yet.

 b.) If the "area" property is set as a construct property
     then fire a warning that the currently set "priv->area"
     which was previously assigned will be cancelled.

This leaves the following options to subclasses:

 a.) They do their thing in _init() and implicitly
     create the priv->area early in the game, except
     if users create *that subclass* using g_object_new()
     and provide an "area", there will be a warning
     and either the _init() related code or the user's
     provided area will be ignored 

     This is no big deal, the subclass here generally adds 
     renderers and decides the layout of the icon view in 
     these cases anyway, these subclasses generally don't
     support using a different GtkCellArea, or sharing
     one with another widget.

 b.) The subclass can decide to support users providing
     a custom area by simply moving their code from _init()
     to ->constructor() and checking if the user already
     provided a GtkCellArea.

Note again: This discussion can be considered completely pointless
because we can safely say "Dont do that at all from _init(), write 
higher level access code safely from ->constructor() instead", 

>   ∘ proposal: Make cell-areas non-settable in 3.0. Considering there
> is only one cell area implementation, this is not a huge loss.
> Alternatively, complete the patch for runtime-settable cell areas
> within the next week.

This cannot be done.

Sorry, 
  gtk_tree_view_column_new_with_area(),
  gtk_tree_menu_new_with_area() and
  gtk_cell_view_new_with_context() are all needed
for the GtkComboBox to share the GtkCellArea between
the treeview and menu components.

So you cant "just remove those".

And of course there is no other GtkCellArea, yet...
but letting the user provide a different GtkCellArea,
be it a GTK+ one or a home grown one is one of the 
major points of having an abstract interface to laying
out cells.

removing the *_new_with_area() apis hide this and
reduce our chances of anybody writing more cell areas
for GTK+, which pretty much kills it... please don't kill it.

And I have to repeat.

All of this, because people love my_object_init() and
hate my_object_constructor() ?

I think that is a very poor excuse to create this
much friction.

Yes, there is the argument: "But GtkCellLayout is
an interface !... <whine> It should work always whenever
I call it and not conk out during _init() </whine> !
but that really is the same argument I've been hearing
before: 
 - "I don't like accepting that _init() is not the
    place to safely call apis"
 - "I don't like moving my code to the constructor()
    where I _know_ that the parent class has finished
    with everything"

In conclusion:
=============

Can we do either one of the following (in the order of my preference):

  a.) Give up the complaining about moving code from _init() to
      ->constructor() and just accept that ->constructor() is the
      right place to call highlevel apis accessing 'self'.

  b.) Implement the "Claudio's original patch" approach (i.e.
      as I mentioned above, this can be solved by simply creating
      the GtkCellArea early for renegade subclasses which insist
      on accessing the api from _init()).

Thankyou all for your attention.

-Tristan