GtkCellRenderer design issue

[Lorenzo Gil Sanchez <lgs sicem biz>]

Hi,

I've been thinking on how the Cell Renderer class is designed in GTK+
and I think there is some points where we can improve it a little bit.

I'd like to say all this discussion has a meaning with editable cells.
For non editable cells GtkCellRenderer is more than ok.

We have at least to ways to treat editable cells:

A) GTK+ way: We have a GtkCellRenderer living inside another widget
(e.g. a GtkTreeView or a GtkGrid). When the user does some action (e.g.
a mouse click or press the enter key) this widget call
gtk_cell_renderer_start_editing on that renderer and the renderer
returns an instance of a GtkCellEditable, which is not a class but an
interface implemented by some widgets like GtkEntry. So the GtkTreeView
has now a brand new GtkEntry and it puts it on the cell. Now the user
finishes editing the contents of that cell and the GtkTreeView removes
the GtkEntry from itself destroying it.

----------------------------------------------
| TreeView                                    |
|---------------------------------------------|
| TreeViewColumm     |      TreeViewColumn    |
|                    |                        |
| CellRenderer       |      CellRenderer      |
|                    |                        |
| CellEditable       |      CellEditable      |
----------------------------------------------

B) Java Swing and WxWindows way: We have CellRenderers and CellEditors
and there is no direct connection between them. For example, in a
GtkTreeView we can have a CellRenderer and a CellEditor in each Column.
When the user enters into editable mode of a particular cell, the
GtkTreeView *shows* the CellEditor of that column and *moves* it to the
cell location. When the user finishes editing that cell, the GtkTreeView
just *hides* the CellEditor. Please note that there is no
creation/destruction of the CellEditor (e.g. a GtkEntry) everytime the
user moves to a cell and enters the editable mode.

-----------------------------------------------------
| TreeView                                           |
|----------------------------------------------------|
| TreeViewColumm           | TreeViewColumn          |
|                          |                         |
| CellRenderer CellEditor  | CellRenderer CellEditor |
|                          |                         |
-----------------------------------------------------|

I think option B is simpler, cleaner and more flexible because of the
following reasons:

1. You can implement new Editors without touching Renderers. There are
hundreds of examples where this can be useful:

	- Imagine you have images in a TreeViewColumn and you want the 	user to
be able to change them by going to a cell and editing 	the name of the
image. Here you have a GtkCellRendererPixbuf as 	the renderer and you
can use a GtkEntry for the Editor.
	
	- Or maybe you have numbers in a column using a 	GtkCellRendererText
and you want to use a GtkSpinButton to edit 	them.

	- Perhaps you are editing dates using a flashy drop down 	calendar
combo (like Planner) but all you need to use to display 	them is a
GtkCellRendererText.

2. For widgets like GtkTreeView and GtkGrid it is easier and faster to
handle their children because they just need to create/destroy them once
and then all they need to do is show/hide them in the proper location.


Now that you know this I'll tell you my particular problem. I'm
implementing a GtkGrid and so far I use GtkCellRendererText for the
cells. All the cells are always editable so they way I move the active
cell is connecting a key-press-event signal handler to the CellEditable
because the focus is always on the cells and not in the Grid.

Now I want to use GtkCellRendererToggle for my boolean columns and I
can't use this aproach because the GtkCellRendererToggle does not return
a CellEditable in its start_editing method. So I need to handle the
check and uncheck of the toggle by myself adding some weird cases to my
Grid design.

What do the gtk hackers think about this issue? I'm eager to read
comments.

Thanks

Lorenzo Gil