Meeting on irc.gnome.org:#gtk-devel Meeting started September 27 2004 17:06 EST (21:06 UTC) In attendence: Anders Carlsson (andersca), Matthias Clasen (matthias), Owen Taylor (owen), Jonathan Blandford (jrb), Robert Ögren (roboros), John Ehresman (jpe), Sven Neumann (neo), Federico Mena Quintero (federico) should we begin ? yeah I have two items which I would like to discuss today matthias: wait for owen? matthias: ne'ermind... jrb: is he around ? matthias: he just logged in that was quick... the first item on my list is libglade can we get libglade in shape for 2.6 ? I think it would be great to have a libglade release supporting most of the new widgets close to the 2.6 release are there any widgets that are hard to support in libglade? * andersca would guess not I don't actually know how much effort it is to add new widgets to libglade, so it may be quite simple... matthias: Of course, libglade without glade isn't much good matthias: I think standard fully propertized, no special handling widgets are close to zero work for libglade owen: we have a couple of model-view widgets. do these cause extra work ? matthias: Well, libglade/glade can't handle the model, so I don't think so.... (probably not until libglade supports gobjects... hmm yep, should work with gtkiconview at least * owen thinks jrb would chime in here except that he's vanished * matthias was waiting for that... He's off talking to dcbw sorry yes! you have been volunteered to update libglade to 2.6... matthias: there's the gobject branch that was never finished, too matthias: adding most of the new widgets is really easy (speaking of libglade, it'd be nice to get it into gtk+ at least for 2.8) matthias: the thing we always wanted were GObjects so we could get size groups, columns, etc Big question there is whether we could restrict libglade to gmarkup and be compatible owen: probably not matthias: I talked to jamesh briefly last night about it. I'll have to take a look at the code andersca: what would break it? owen: I think there is actually a gmarkup patch jrb: *shrug* I do know that when I tried porting bonobo-ui over to gmarkup it'd break with some ui files and I think libglade restricts its xml parser to a subset which is fairly close to gmarkup matthias: it uses libxml... eg it doesn't support entities iirc andersca: you can cripple libxml... do we have libglade files w/ entities in the wild? jrb: my claim is that we don't because libglade doesn't support it... should perhaps gmarkup become a better XML parser? Since we'd presumably be changing the API as well (I'd guess, not completely required), it's not bad if we only get 95% compat * andersca wouldn't mind renaming libglade to GtkWidgetFile and have it support .gtkwidgetfile files instead or something adding support for entities would make it a lot more useful andersca: too many letters... neo: I don't think there is a meaningful state between 'gmarkup' and 'conformant xml parser' neo: gmarkup should be fairly complete for the subset of xml it supports (no encodings, no namespaces, no dtd) jrb: nah, you just use a #define WID anyway jrb: besides, you'd want something like GladeXML *eel_glade_get_file (const char *filename, const char *root, const char *domain, const char *first_required_widget, ...); owen: gmarkup + encodings or gmarkup + dtd would be meaningful, but I wouldn't volunteer to write a dtd parser... matthias: You don't need validation to be a compliant xml parser owen: but you need dtds to support entities. Although xinclude would be an alternative, if it wouldn't drag in most of the xml standards tower matthias: Hmm, I guess so. matthias: What does expat do? Does it just have a dtd parser good enough for entities? do we really need entities here? I've never really missed them in a glade file support for encodings can be added in a wrapper around GMarkup owen: don't know, though I would expect it to support dtds jrb: I think we've drifted off-topic matthias: expat isn't *that* many more lines of code than gmarkup GimpXmlParser does that, I could clean it up and propose it for GLib if you want me to owen: that's what I thought so, it looks like we have three actions here: a) talk to jamesh about gobject+libglade b) find a volunteer to add support for 2.6 to libglade c) investigate gmarkup extensions neo: I don't think anybody has actually asked for encodings in gmarkup. (Entities, yes, PI's yes) I did a) already matthias: also, d) investigate adding a libglade clone to gtk+ for 2.8 (OK, expat is 12,000 lines compared to 2,300 for gmarkup) (or at least get it moved over...) jrb: yes as earler, we also need b2) find a volunteer to ad suppor for 2.6 to glade (glade3/gazpacho/whatever) owen: does expat handle any other xml family standards (xinclude, namespaces, etc) ? matthias: No. That would give you libxml which is 100k+ lines. owen: what is the current state of glade3 ? is it actively developed ? Well, there was lots of activity earlier this year, then it droped off again matthias: I looked at both on friday; both are semi-actively maintained matthias: glade3 looks slightly more mature, but clearly not usable matthias: on the other hand, I can see myself adding a column editor to gazpacho jrb: tough choice between immature and unusable... matthias: indeed jrb: that probably means we should look after getting glade2 patched to support 2.6, and let glade3/gazpacho be handled by their respective developers... matthias: yeah matthias: libglade's the more important one anyway. the other topic I had on my mind is selectable labels and tab/ctrl-tab focus movement... jrb: How is libglade more important? we added the ctrl-tab "focus-me-harder" behaviour to put selectable labels as second class members into the tab chain owen: it's conceivably possible to add support to glade files via an editor if libglade support is there Well..... owen: (as the control-center-2.0.0 proves) but that change is a bit broken, since several containers already used ctrl-tab for special focus movement so what I want to do for the next 2.5.x release is to put selectable labels back in the regular tab-chain, and make the focus-first-child function in gtkwidget.c skip selectable labels hrm so gazpacho looks almost usable * jrb gets back on topic nick federico does that sound reasonable ? (I think selectable labels are almost exclusively used in message dialogs currently) (is anyone logging this?) logs will appear on www.gtk.org/plan/meetings/ as always matthias: Sounds plausible to me, though we'd need to get it in the devel branch early and see what came up owen: I want to have the change in the next 2.5 release owen: I'll try to get it done this week ok, another agenda item was just pointed out to me the Boston gnome summit, which will take place around 10th of October (?) would be a great opportunity to do another face-to-face gtk meeting yeah matthias: Well, assuming attendence... speaking of which, I imagine that the novell people will be hacking a bunch on Beagle during those days, and I'll need to have something working for the file chooser do people have a little time to discuss the draft spec, or should we do that on the mailing lists? federico: Well, maybe a little less cross-posted... ;-) * owen dreads the thought of the gtk-devel-list admin queue so, who will be at the Boston summit (besides the obvious Boston-based RH and Novell people) ? ...I guess we'll find out when we get there, and it should be possible to organize an impromptu gtk meeting if enough interested people are there I can't make it, but I'll be on irc what would the agenda be? pre-2.6 "everyone check the new APIs"? federico: thats a good topic. another one might be: performance of the new functionality, speed up ui manager, combo box, icon theme, file chooser yeah... given the recent developer.gnome.org/.../optimization, it could be useful oh, there's something I've been meaning to ask I noticed that gtk-sharp doesn't use the gtk.defs stuff that everyone else seems to be using and then, everyone seems to grab pygtk's gtk.defs and tweak it as they go should we standardize that at the gtk/glib level, so that binding authors can grab the canonical .defs from gtk itself? federico: http://bugzilla.gnome.org/show_bug.cgi?id=139486 is probably the wayforward there federico: ideally, the "full introspection" work would make .defs unncessary federico: the ADA binding person was complaining about that too federico: they wanted them installed The copy in gtk+ isn't maintained... federico: but until then, it would probably be a good idea to make our .defs the canonical ones, particularly since they are now generated and thus uptodate matthias: No, this is different owen: ? matthias: federico is talking about gtk.defs, not gtk.def matthias: Actually, I guess we removed gtk.defs from the GTK+ tree some while ago, since it wasn't maintained ah, are that the sexp files ? Yeah what scares me is that gtk-sharp actually parses the .c files as well as headers, mainly to grab AFTER/etc. for signals, and object properties they started doing that when there was no good set of gtk.defs around federico: The story I got was that they started to do it because they didn't know about gtk.defs and were too lazy to change (so they had this bug where gtktreemodel's signals weren't being grokked, because they use a custom marshaler) federico: for signals, shouldn't they be able to get all they need via introspection ? should be possible to generate such a .defs file, shouldn't it? owen: they did use gtk.defs at some point I think we've agrressively refused to fix some coimplaints they've had about the GTK+ .c files not being formattted they way they expected them owen: pre-2002 or so matthias: yeah, but no one has written that yet Sep 27 18:02:09 * tml needs sleep gtkmm uses introspection to get the signals (and pygtk, etc, at run time) * jrb wonders if that's a sign we need to have an earlier meeting I always wonder about that sauna reference when tor leaves... federico: Anyways, whoever I was talking with (don't think it was mkestner, but I forget who it was) didn't really seem interested in cooperation. But once we do the full-introspection stuff, hopefully all the language bindings will get on the train eventually. it would be a fun project, anyway ok, I have to start preparing dinner (the kids will come home soon) see you next week matthias: Later see you, matthias owen: full introspection is 3.0 material, right? federico: There are no plans for a 3.0 federico: We've told the person working on it that if he gets a good looking prototype out soon it is reasonabel for consideration for 2.8 oh, is someone actually working on it? federico: Yeah, Rob Melby was pretty interested. I forget his IRC nick wow, that's good to know! damn, I missed the meeting :( Meeting ended September 20, 18:17 EST (22:17 UTC)