On Mon, 2007-04-23 at 11:28 -0400, Tristan Van Berkom wrote: > On Mon, 2007-04-23 at 09:17 -0600, Michael L Torrie wrote: > > On Mon, 2007-04-23 at 10:05 -0400, Tristan Van Berkom wrote: > > > It might be advantagous if alot of the glib data structures > > > were moved somewhere above libgobject in the stack (glibutils ?), > > > this way they could have the option of being gobject based, > > > opening a whole new world of possible code paths and also allowing > > > more generic access to these data structures through the gobject > > > api (hash tables and linked lists could possibly be serialized > > > by libglade and crammed through a network socket ? for an example of > > > a misc wild idea). > > > > I think you mean "below" the gobject stack, don't you? The data > > structure libraries are required by gobject after all, aren't they? > > > > Heh, yeah maybe my idea of gobject'ized glib data structs is a little > futile :) not sure just exactly what I'd do with a derivable GList, > I'm sure something random could come of it haha, maybe > GQueues/GAsyncQueues could be extended glists etc - I guess in the end > that sort of thing would just be libfancyobjects :) > > Might be an interesting thing from a bindings point of view... I dunno
I've found myself wanting GObject derived GList. The idea is to have a "list of things with some GType", and make the API which modifies that list emit "changed", "deleted", "inserted" signals, etc. I coded a GObject derived class to do most of this. One thing missing with GList is type safety of course, but if you want, you can add run-time type safety with a class around it. Peter Clifton _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
