On Wed, 2008-01-02 at 08:58 -0600, Jonathon Jongsma wrote: > > GL-based toolkit; having multiple stages is a technical issue > concerning > > the drawing pipeline and GL contexts - having multiple renderers for > the > > scene graph implies a greater design change. > > Sure, but this doesn't change the fact that at a glance, the generic > name ClutterModel doesn't indicate what exactly is being modeled.
> It's not a big issue, but IMO you don't lose much by making the name > more specific (e.g. ClutterListModel or similar) even if you have no > immediate plans to add any other models to clutter. today I renamed the default implementation from ClutterModelDefault to ClutterListModel; this should make the nature of the model a little bit clearer. in theory, ClutterModel API is abstracted enough to allow the creation of tree, or any other data structure for that matter, based models; the only changes would be localised in the ClutterModelIter class, which has padding enough for adding needed virtual functions (and, in case, I can add padding before release). the only functions that would go away are the insertions, which depend on the actual type of backing store implemented by the ClutterModel subclass. in short: I'll punt any changes in ClutterModel API for 0.6, and in 0.8 we can start pondering (or reviewing patches) for having other ClutterModel implementations. ciao, Emmanuele. -- Emmanuele Bassi, OpenedHand Ltd. Unit R, Homesdale Business Centre 216-218 Homesdale Rd., Bromley - BR12QZ http://www.o-hand.com -- To unsubscribe send a mail to [EMAIL PROTECTED]
