Meeting on irc.gnome.org:#gtk-devel Meeting started April 6 2005 16:04 EST (22:04 UTC) In attendence: Matthias Clasen (matthias), Jonathan Blandford (jrb), Owen Taylor (owen), Ray Strode (halfline), Johan Dahlin (jdahlin), Carlos Garnacho (garnacho), John Ehresman (jpe), Soeren Sandmann (ssp), Federico Mena Quintero (federico), Jon Kare Hellan (jon_kare), Manish Singh (yosh) so, I have been starting to work towards stable releases and I may do them around the end of the week, if I can finish my loop over all unmilestoned bugs if there are any bad bugs which we should fix before the next release, please bring them up otherwise I'll work based on whats currently on the 2.6.4/2.6.5 milestones when can we expect the introspection code to land? do we know a date for gnome 2.10.1, btw ? Not that I know of. I don't even know who's coordinating 2.10.x I think that kmaraas He did 2.8.x anyways ok, so doing a release this week or next week should not make us miss 2.10.1 in any case hi jdahlin: I still plan to put my prototype code up later this week, but life has been hectic in the last few days... matthias: I'm asking because I'd like to look at the possibility of using features from it for the libglade integration for example, currently libglade loads all GTypes it supports during startup. Doing it lazily might be a better option (if memory really matters) jdahlin: I'll try to get it done this week where does libglade currently obtain the list of get_type functions to call ? hardcoded ? yes, hardcoded jdahlin: btw, I discussed GtkWidget::sizegroup with owen today, and we concluded that it doesn't make much sense as a property since a) a widget can be in multiple size groups, and b) you will need explicit support in gui builders for it anyway matthias: I came to a similar conclusion, I think it would be better to specify children of the GtkSizeGroup for reference, the list of GTypes are specified in the end of this file: http://cvs.gnome.org/viewcvs/libglade/glade/glade-gtk.c?rev=1.106.2.3&view=markup jdahlin: thats really misusing the "children" terminology, though jdahlin: "members" would be much better (a similar comment goes for treating columns in a treeview as children, btw) for this situations? matthias: I'm reusing child in a couple of other places, UIManager->ActionGroup, ActionGroup->Action, GtkTreeView->GtkTreeViewColumn and GtkTreeViewColumn->GtkCellRenderer jdahlin: yes, although I may be overly pendantic about terminology here probably keeps the parser a tiny bit simpler matthias: but your point is good, GObject is really missing the concept of having subobjects Well, the members of a size group definitely aren't subobjects, since a widget can be members of multiple size groups jdahlin: pushing containers to gobject is a very old topic, afaik jdahlin, wouldn't it better to think about relationships between objects, rather than just container & subobjects (children) jpe: that seems a bit complicated, but perhaps required for sizegroups jpe: general children properties, as in DSSL groves jdahlin, another example would be a model that's used by multiple views jpe: you could just set a property on all views for the model, which already works today if we had a sizegroup property we could just call it multiple times for a widget, to add the widgets in several different sizegroups jdahlin: but that (model property on views) misses the reverse relationship jdahlin: that gives wierd semantics the sizegroup property would have to be a list of sizegroups should the sizegroup property be a list of widgets? sizegroups I meant, not widgets Anyone familiar with installing Luminocity try on #fedora-desktop, we're in a meeting im sorry jpe: they could be, but it would require special support (outside normal properties) I think list-valued properties and container support in gobject are beyond the scope of 2.10/libglade integration but aren't we talking about needing special support for them already jpe: for size groups, I think special support is necessary not just because gobject doesn't handle list-based properties, but because treating them as generic list-valued properties will suck for a gui builder matthias, yes you'll need a decent gui for them in the builder, but it would be nice if serializing / unserializing them didn't require special support matthias, you're probably right about list-valued properties being out of scope, though my family calls for lunch...anything else we ought to discuss today ? Nothing that I can think of. If someone wants to tackle rectangular path optimizations in Cairo that would help HEAD performance a lot :-) owen, is cairo + gtk head usable on win32 yet? owen: Is it generating non-rectangular trapezoids for rectangular paths? jpe: I haven't touched it since I got it running.... so the slight oddities I think are still there. ssp: No, but it's generating rectangular trapezoids for rectangular paths. That could be optimized in the server, but optimizing it on the lcient side will give much better old-X-server performance right Sorry to bother you guys, but is the bug #145121 (GtkFileChooser should accept file DND) easily fixed? There's a patch attached to it, but I don't know if that was rejected or someone just didn't get around to incorporating it? jeramy: I'll take a look before 2.6.next thanks do we have any good naming suggestions for the new GladeXML object? GtkObjectFile, GtkBuilder have been suggested before GtkObjectFile == no :-) GtkBuilder isn't awful, though it isn't terribly descriptive GtkObjectBuilder? GtkObjectFactory Is the object really a factory / builder? It corresponds to one resource file right? GtkGlade Is the intent to keep it around after the objects are instantiated? jrb, maybe GtkGladeReader owen: could be several, since ui manager files can be referenced to external files. pixmaps could also be considered to be part of the interface I guess I'd have to see the proposed API to see if GtkBuilder made sense as a name ob = gtk_object_builder_new("main.glade", NULL, NULL, NULL) gtk_object_builder_get_object(GTK_OBJECT_BUILDER(ob), "window1") owen: it's just the api of GladeXML, plus a few functions to merge/unmerge ui files Well, it would have to be "build_object()" for the name to make any sense. If the objects are created on _new(), then ...Builder or ...Factory doesn't fit how about GtkUIDescription? maybe a bit long halfline: I think we've polluted that namespace with GtkUIManager GtkGladeReader is better if the files will continue to have .glade extensions owen: ah true GtkGlade is actually not terribly bad not very informative though :) GtkGlade is tied to the .glade extension Meeting ended April 6, 17:12 EST (23:12 UTC)