On Sat, Oct 23, 2010 at 9:44 AM, Tristan Van Berkom <trista...@openismus.com> wrote: > I'm a few days into this and I've written up a GtkCellAreaClass and > started out implementing an orientable GtkCellAreaBoxClass. > > An initial problem here has to do with pushing data to the GtkCellArea > instead of pulling it from the model, do we really want to be able to > use GtkCellArea to render cells for data that is not coming from a > GtkTreeModel ? (is it worth the trouble ?)
I have always been relatively undecided on this and just meant to bring up that you can distinguish between the two methods and one will have to be chosen. Adding to this that I haven't come up with a concrete case yet wherein using GtkCellArea or GtkCellAreaBox without a tree model could be useful. Another thing that this depends on is whether cell renderers are shared amongst GtkCellAreas in the same GtkCellAreaBox and whether GtkCellArea implements GtkCellLayout. From your e-mail I understood that GtkCellArea indeed implements GtkCellLayout, does this mean that each GtkCellArea will need its own GtkCellRenderers to render? Would it be possible and make sense to share GtkCellRenderers amongst GtkCellAreas that are contained in the same GtkCellAreaBox? This stays kind of close to the model that we currently have and you could say that GtkCellAreaBox would pull the data and push this into a GtkCellArea. In this case GtkCellArea would not implement GtkCellLayout, but GtkCellAreaBox would. > Currently this presents a few problems, which are not > insurmountable but still weird to handle since the whole thing > is tied heavily into GtkTreeModel already: > > a.) We cant do gtk_cell_layout_set_cell_data_func() from > inside the GtkCellArea, that stuff would have to be done > from a GtkCellLayout implementation aside from pushing > data to the GtkCellArea. Right, I guess this is because data needs to be pushed to the GtkCellArea whereas in order to be able to call the CellDataFunc you need to pull the data (in GtkCellArea) first? This should be the responsibility of the pusher, and in case we decide to mark GtkCellAreaBox to be the pusher, this is not a problem, right? > b.) gtk_cell_renderer_activate() takes a "path" argument; > I think it would be better if this were a gconstpointer > user_data argument in any case that CellArea was rendered > for something that is not a GtkTreeModel row... If I continue > with the "pushing" data approach, this will likely turn into > a "detail" string argument to gtk_cell_area_event(). > > On the other hand, if we pull data from GtkTreeModel/GtkTreeIter we > get to easily reuse/share code that actually pulls data from > GtkTreeIter and pushes it to the underlying cells (as that would > be handled by GtkCellArea), and also we have less api churn to deal > with, since treepaths still make sense in GtkCellRenderer:activate > signals. Yes, that makes sense. > - GtkCellLayout->pack_start()/pack_end() should be deprecated > in favour of ->add()/->set_child_property(), since those apis > can only be implemented from a GtkCellAreaBox (but dont make > sense for say; a GtkCellAreaTable or GtkCellAreaGrid). Makes sense. > All-in-all I'm not sure that the "push data to the CellArea" > thing is going to be worth while, I'm considering changing > this to a "pull data from the model" approach which seems to > fit the current GTK+ codebase a lot easier. Yes, perhaps pull is indeed the way to go, or have GtkCellAreaBox pull and push this into GtkCellAreas as I described above. Not sure if you agree with that or whether that aligns with what you had in mind. An advantage of this could be that GtkCellAreaBox would be a straightforward refactor of the current GtkTreeViewColumn as all the layouting algorithms/calculations can be re-used. For a start, we would keep the same code/semantics for the cell_area, background_area calculations (taking the h/v separator into account, focus line width, etc.).This should make it easy to port GtkTreeView* to this without breaking the current way of layouting, so that this can be feasible material for 3.0. Later we can start changing cell_area etc. calculations, either in the same GtkCellAreaBox class or in a new one. You could perhaps make GtkTreeViewColumn use a different GtkCellAreaBox subclass for each column. regards, -kris. _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list