From: Axel S. <A....@ke...> - 2005-11-26 12:45:18
|
On Sat, 2005-11-26 at 11:58 +0000, Duncan Coutts wrote: > > Hence, if we always implement the whole TreeModel within Haskell then we > > need to provide some default implementation. If that's not too hard to > > do and efficient enough, then I'm all for it! > > Notifying the view of changes in the model involves calling: > gtk_tree_model_row_changed > gtk_tree_model_row_inserted > gtk_tree_model_row_has_child_toggled > gtk_tree_model_row_deleted > gtk_tree_model_rows_reordered > > which emit the corresponding signals which notifies the view(s). > So we'd want the Haskell layer to present functions for modifying a > store to emit the right signals. Ok, so these C functions will trigger the signals (i.e. you can copy'n'paste the code from gtktreemodel.c?). > There is also more work to implement the drag & drop and sortable > interfaces. Just the interfaces, right? I.e. we "only" need to figure out how these interfaces work in Gtk and then reserve the right slots in the gtk2hs_tree_model? I'm certainly not in favour of re-implementing anything like TreeModelSort or even the DND stuff. > There is one difficulty in the implementation which is a memory > management issue. The GtkTreeIter values are just stack allocated values > and so we cannot know when they are no longer used, so we can't put > references to Haskell values (rg StablePtrs) into them, or if we do, we > must remember them so we can free them later. I'm still trying to figure > out the best way of dealing with this. I suppose the TreeIter should really only contain an integer index into the Haskell data structure. The way it could work is that we find some sort of enumeration of the underlying data structure. For a plain list implemented by an array it would just be the array index. For a tree constructed by an list of lists, it could be the element position of the flattended list. The disadvantage of this scheme is that we need to force the user to make his/her data structure an instance of class Ix, which is not always trivial. This only works since TreeIters are invalid once the model changes. > > > > This works and allows me to connect it up to a TreeView with a couple > > > columns. > > > > Cool. Can you create a TreeModelSort from the Haskell model? > > The TreeModelSort is just another interface so the same technique would > work. I just implement a GObject in C that implements that interface and > delegate the implementation of each method to Haskell land. But (see above) I'd rather not re-implement TreeModelSort. TreeModelSort basically wraps all calls to the underlying TreeModel and does a permuation on all TreeIters/TreePaths such that the TreeModel underneath looks sorted. We shouldn't have to do that in Haskell. > This is what the C glue layer I've already got does: > > struct _Gtk2HsStore > { > GObject parent; > > /*< private >*/ > HsStablePtr impl; /* a StablePtr CustomStoreImpl */ > }; That's it? I suppose you've defined the klass thing elsewhere. > > i.e. you pass the attributes of the renderers you want to connect as > > part of the column, which means that you have to create the renderers > > beforehand and that you can't change the renderers later on. I think > > this is bad since it prevents you from creating a new TreeView with new > > cell renderers after the store is created. Even with run-time type > > checks, the program will fall over the first time you show the widget, > > i.e. it should be easy to debug an incorrectly constructed table. > > Yes, it should be ok to make the columns and renderers with the view > without any reference to the store. And then one set of runtime checks > is needed when the store is connected to the view+renderers. > > I think the construction of the view+cols+renderers could be more > declarative than it is at the moment. For example we don't necessarily > need to expose the fact that renderers are objects in their own right. Sure, but people want to do the weirdest stuff, for example, they might want to add a new renderer to a column later on. That's when things with good intentions like Mogul fall over. > True. So that's probably what we should aim for - a simple runtime check > - especially if we can limit it to a runtime check when the view/model > are constructed/connected. Then we can think about more cunning types > later. > > > I'll rename my CVS tree to something else and assume that you do the > > whole model thing. > > Don't abandon me! :-) I'll try not to. But you've started to code in C...:-) > I don't really know yet what the higher level api should look like, and > you seem to have some good ideas about that. I'm not so sure about the latter. It's nice if you get it working though. Axel. |