Re: Minutes of the GTK+ Team Meeting - 2011-01-25
- From: Tristan Van Berkom <tristanvb openismus com>
- To: Matthias Clasen <matthias clasen gmail com>
- Cc: gtk-devel-list <gtk-devel-list gnome org>
- Subject: Re: Minutes of the GTK+ Team Meeting - 2011-01-25
- Date: Wed, 26 Jan 2011 16:18:56 +0900
On Tue, 2011-01-25 at 17:57 -0500, Matthias Clasen wrote:
> • 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
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
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.
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
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
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
- "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
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.
] [Thread Prev