Re: Private types inside GTK+

[Kristian Rietveld <kris gtk org>]

Hi,

On Sep 9, 2010, at 11:28 AM, Tristan Van Berkom wrote:
> Hi,
> 	With all the GSEAL()ing of the whole GTK+ api we get 
> to privatize alot of things which leaves us alot more leeway
> in how we can change things under the hood in the future.
> 
> However, what we have to play with is still a matter of
> basic C code implementation details and not much in 
> the sense of OOP code... so I wonder if we can make
> a mechanism at the build level to privatize entire
> object types to be used solely as delegate objects
> of widgets that are a part of the API.

I see where you are going.  I think that often such objects could make sense as public API.  But I guess you also want to avoid making these objects public too soon, since that will decrease the amount of leeway again.

> I had this idea while pondering:
>   https://bugzilla.gnome.org/show_bug.cgi?id=629133

Please allow me to comment in some more detail on this exact issue.

>   b.) Add some magick/logic to GtkCellView where cellviews
>       can be associated with a "group" of cellviews and
>       then align them with all the cellview's siblings.
> 
>       While this option seems more sound at first sight
>       in terms of code readability and all, it also introduces
>       some iterative overhead as each cell would have to 
>       consult the size requests of every cell in each cellview
>       sibling... the the allocation of each cellview in the list.
> 
>       (not to mention it would have to make the assumption that
>       every sibling has the same type of cell renderer packed
>       in the same order... and that each cell view is set to
>       render a row from the same model... a kind of ugly assumption
>       that you really dont want to make).

I agree, this will turn out ugly :)

>   c.) What seems to me as the "Right Thing" to do here is to create
>       a derived GtkMenu; GtkComboBoxMenu that would be responsible 
>       for taking into account the width of each cell on each row
>       and then effecting an allocation for every cellview in the
>       menu in a single pass.

If possible, I would even get rid of the separate cell views in this case.  Could a GtkComboBoxMenu just render itself using a set of cell renderers without needing instances of GtkCellView.  Though this might show troublesome in combination with supporting the separate menu items ...

> Vaguely, for bug 629133 my plan could be:
> 
>   - Privatize GtkCellView unless there are some objections (or at least
>     early deprecation in 3.0 cycle). 
> 
>     CellView is really only an implementation detail of GtkComboBox
>     and thus adds some cruft to the api that we really dont need
>     (unless some applications "love" the cellview and then justify
>     its existence and our maintenance of it).

GtkCellView has been around for some time, so it might have seen some usage.  We would have to investigate this.  At least, I would really deprecate early in 3.0 and not before ...

>   - Create a private type GtkComboBoxMenu which could be responsible
>     for allocating the private cellviews in a combo box's dropdown menu
>     properly and in a single pass.
> 
>   - Work on refactoring GtkTreeViewColumn so that it stands alone
>     and apart from GtkTreeView (somewhere along side working on
>     wordwrapping cell renderers and variable row heights in treeviews).

As I also noted in the bug, I would not make GtkTreeViewColumn a stand-alone class, rather, I would work on getting the algorithms that do the cell and column layouting in separate classes and then have GtkTreeView, GtkTreeViewColumn and GtkComboBoxMenu re-use this.  Note that even though cell layouting is done in GtkTreeViewColumn, the column layouting is done in GtkTreeView.

I think that these layouting algorithms in separate classes might actually be useful public API, to reflect on the comment I made at the start of this e-mail.

There might be more "components" of GtkTreeView that could be useful to refactor into new separate classes, for example the rendering loop, selection handling, input event handling etc.  My goal would be to refactor GtkTreeView in such a way so that it (the original functionality) can be composed from these separate classes.  And also so that GtkIconView (and new kinds of such views, Windows-style columnary perhaps?) could also be re-written by a composition of these classes.  This will reduce the amount of code that is duplicated between GtkTreeView and GtkIconView, and in this case you can also add GtkComboBox and GtkCellView to that list.  Furthermore, the road for creating variations of these "view" widgets with more flexible and special layouting has then been opened.

>   - Integrate GtkTreeViewColumn as a delegate of the private
>     GtkComboBoxMenu which would be used to render rows into
>     the allocated menu item space.

So instead of using GtkTreeViewColumn as a delegate, GtkComboBoxMenu would re-use the layouting algorithms and perhaps the rendering loop which are now in shared classes, to implement the desired behavior.

>     This would ofcourse have the advantages of centralizing
>     the columnized cell rendering code in one place as well 
>     as being more lightweight (not creating cell renderers 
>     for each and every row in the model/menu).

Indeed.  Especially for GtkComboBoxMenu, not having to create all GtkCellViews with exactly the right properties will help much.  And also in signal handling overhead, each GtkCellView has to connect to the model signals ...


regards,

-kris.