From: Axel S. <A....@ke...> - 2005-11-23 08:55:28
|
I thought I cc this to the list, since there's no need to discuss this in private. This thread just evolved about some CVS commit message. On Tue, 2005-11-22 at 20:46 +0000, Duncan Coutts wrote: > On Mon, 2005-11-21 at 10:09 +0000, Axel Simon wrote: > > On Mon, 2005-11-21 at 09:48 +0000, Duncan Coutts wrote: > > > On Mon, 2005-11-21 at 08:51 +0000, Axel Simon wrote: > > > > On Sun, 2005-11-20 at 19:16 +0000, Duncan Coutts wrote: [..] > > > > > > What user api are we presenting? Does that api require that we implement > > > it by the single column stable ptr technique? > > > > Yes, I'm afraid, it will break the current API > > Oh that's ok. > > > and only allow a single > > column with an arbitrary Haskell data type. It would make things very > > Haskellish, though. Rough ideas (again): > > > > TreeModel: Has not type (TreeModel row) where row is the Haskell data > > type in the model. Say this is a record: > > > > data Phone = Phone { name :: String, number :: Integer, marked :: Bool } > > > > I'd say > > m <- treeModelNew -- of type (TreeModel Phone) > > v <- treeViewColumnNew -- of type TreeViewColumn > > cName <- cellRendererText > > cNumber <- cellRendererText > > > > Now here is where it gets speculative: > > > > cellLayoutAddRenderer cName [attrText m := name, > > attrBackground m := \p -> if marked p then "red" else "white"] > > cellLayoutAddRenderer cNumber [attrText m := (show . number) ] > > > > So attrText is one of the attributes of CellRendererText: > > > > attrText :: TreeModelClass model => CellRendererText -> model row -> > > (row -> String) -> ... > > > > The only reason the attrText takes the model is to get the type right. > > That actually doesn't mean it's type correct: I can pass a different > > model to attrText than what I install into the final TreeView. However, > > I can check that the models are the same when I actually set the > > attributes. > > Perhaps we should parameterise the renderer or column or something by > the model type. So we can guarantee that the types for the renderers > match the model. I thought about that, but TreeViewColumn is already a widget, and having widgets with a type parameter is not a very good idea, IMHO, mainly because it messes up our type generation, casting, container functions, etc. I did exactly this for the GtkCList back in the days of gtk+hs and Manuel wasn't happy about that (which I can now understand). Mainly because it would probably mean that TreeView, ComboBox, IconView, etc. all get a type parameter. > > I hope this is understandable. > > Yes. > > It's a nice idea. The only downside is having to implement it as a > single column model which will make it not work for as the model for > CellView/ComoBoxEntry/etc. I think it is an omission Gtk that this won't work. Once I figure out what I need, I will file a bug report. If it gets incorporated, then we can use some private (uh-uh) header files to access the underlying functions for earlier Gtk+ versions. > Of course the advantage is that arbitrary Haskell types can be used. I thought about whether there is a way to actually mix the two models, but I'm not sure it's possible. On creation of the model, we could always enforce that column 0 is the Haskell type and have the Combo box on creation always add a String column with number 1, an IconView a String and a GdkPixbuf for column 1 and 2, etc. It might work, but it is a bit clumsy. Axel. |