Private types inside GTK+

[Tristan Van Berkom <tristanvb openismus com>]

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 had this idea while pondering:
   https://bugzilla.gnome.org/show_bug.cgi?id=629133

Basically the bug explains that we have no way of aligning
renderers in a combo box's drop down menu in the way
that they can be aligned in a GtkTreeViewColumn... 

I had a few ideas on how to implement this to get the
desired effect:

   a.) Connect to the menu and submenu size-allocate
       signals and do a second allocation pass which
       may result in the alignment of the GtkCellView cells
       which are currently packed into menu items.

       This ofcourse involves a needless overhead of
       allocating all the items twice.

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

   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.

       This would also have the added benefit of removing some code
       from GtkComboBox that deals with the menus, making the hugely
       complex widget a bit more modular and easier to work with.

Then I got to thinking... probably we shouldn't even be using a list
of cellviews all owning their own cell renderers hard-wired to display
a single row in the model... we should be using a GtkTreeViewColumn
to do the work instead ! ... ofcourse this would require some severe
refactoring of GtkTreeViewColumn and we would have to wait until
that is ready.

Ultimately, if we could use some entirely private types in GTK+ as
delegates of our API widgets then we can make all of those changes
without having to wait for GTK+4 and another api break.

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

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

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

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

   - At that point we could completely drop GtkCellView (if
     its not part of our published api), and even drop or drastically
     change the private api of GtkComboBoxMenu since it was never a part
     of the api.

Are there any technical limitations that dont allow us to create
widget/object types that are completely internal to GTK+ ?

Any ideas on how this would effect the build system ?

Do people like the idea of using completely private types
inside GTK+ and removing some unnecessary cruft from
the api (imo giving us a bit more freedom to move around
between api breaks) ?

Cheers,
            -Tristan