Meeting on irc.gnome.org:#gtk-devel Meeting started April 18 2005 16:04 EST (22:04 UTC) In attendence: Matthias Clasen (mclasen), Johan Dahlin (jdahlin), Tor Lillqvist (tml), Jonathan Blandford (jrb), Morten Welinder (gmorten) ok, so I thought we should maybe talk about the GtkBuilder patch that'd be great, I'm very interested to hear what kind of improvements/changes are needed to get it into the right shape jdahlin: I haven't tried the patch, but from reading it, I wondered why we need the pseudo-interface containing the build_children and that other function mclasen: you send in a structure, which is a representation of the xml which tells a object to construct children for all child tags mclasen: I've used this mapping for UIM->AG, AG->A, TreeView->Column, Column->Renderer jdahlin: I understand that, but I wondered if we should not either make it a real interface, or do it nongeneric, to avoid that slightly odd type registration stuff mclasen: I think a real interface is prefered, but I didn't finish it, since it requires some more work for making it friendly for language bindings perhaps to be split up into several different methods of a interface, or add a new GBoxed type with a couple of methods on a sidenote, we'd still need a hash table of names -> GType, to delay type registration. jdahlin: can't we just construct objects as we parse the file ? (Would still have to do the deferred property thing for widget properties) mclasen: that would be one option, yeah (or actually typename -> pointer to get_type function) for third-party widgets, we will still need to register some parsed-start-tag --> constructed object function, though now I remember why it won't work because of construct properties we'd have to do construct at end-tag time, and append all eventual children. its probably construct-only thats problematic when are objects constructed in the current code ? Does it parse the whole tree, and walks it in a second pass to construct the objects ? yes, the objects are constructed in the second pass and it's just this structure, which contains the tree that's difficult to wrap for language bindings (as it is right now) so, if we add a real interface for the construct-from-xml functions, and have a way to lookup get_type functions by type name, we don't have to register all the types in _gtk_build_init_types any longer, right ? right we'd also need a way to resolve internal children eg, action_area for GtkDialog can that be solved by giving names to all internal children ? what do you mean? it can probably be solved using introspection, but I'm not sure if want to do that. if all internal children had locally unique names, you should be able to look them up by walking over the widget tree and comparing names... or just include an extra method in the interface we'd have to construct the children as you do in the current pseudo-interface, right. I was just wondering if that method is actually necessary then we'd have object specific logic in the parser which might be okay, since it's mainly for backward compatibility the parser could just call a generic find_internal_child method... and what about third-party objects which have internal children? not that different from looking up the find_internal_child method in the pseudo-interface and calling that, but it is probably safer to have a method for it in the interface since we don't guarantee uniqueness of widget names, afaik so an application could e.g. add a child named "vscrollbar" to a scrolled window... right do we have any clashes like this today? I don't know, but I guess not widget names are not that heavily used mclasen: anyone who uses glade uses widget names. make that libglade but probably unique names mclasen: should we have a global registry and let the objects add themselves to it? like: gtk_builder_register_get_type_function(str, ptr) mclasen: within a single dialog, yes of course. jdahlin: it will overlap with the introspection stuff which will also allow you to look up get_type functions by type name mclasen: can it be moved out of the introspection and be placed in gtk/gobject itself? but since the introspection stuff hasn't landed yet, it is probably a good idea to have a simple registry like that for now I need to start packing up now. Did anybody else look at the GtkBuilder patch ? okay mclasen: didn't owen give it a look? there is one more feature that might be useful to have, the possibility of modifying styles (setting colors, fonts etc) jrb: didn't hear anything from him, apart from the fact that it prints out to 50 pages, 2-up see you next week, bye Meeting ended April 18, 16:54 EST (22:54 UTC)