Meeting in yarrr Meeting started May 10 2005, 16:10 EDT In attendence: Jonathan Blandford (jrb) Colin Walters (walters) Matthias Clasen (mclasen) Scott Arrington (muppet) Owen Taylor (otaylor) Ray Strode (halfline) Dave Malcolm (dmalcolm) Federico Mena Quintero (federico) Johan Dahlin (jdahlin) Maciej Katafiasz (mathrick) Seth Nickell (seth) 16:07 jrb so, I don't know if/when matthias is goign to be here 16:09 walters anon: don't forget to change your name : 16:10 seth (walters, swalter) 16:12 mclasen I seem to be completely confused wrt to timezones 16:13 mclasen is it 4pm now ? 16:13 mclasen if yes, in what timezone :-) 16:13 jrb mclasen: I can never figure them out. I'm just glad that indiana fixed itself 16:13 muppet Tue May 10 16:14:54 EDT 2005 16:13 muppet note EDT, not EST 16:14 swalter indiana didn't fix themselves, they're just consistently broken now 16:14 otaylor 16:15 walters sweet 16:15 mclasen hmm, so is EST somewhere else currently ? or are we meeting in nomanstimezone ? 16:16 otaylor it's only 3:30 EST, 20:30 UTC, so we still haven't reached your posted meeting time 16:16 muppet EST == Eastern Standard Time. EDT == Eastern Daylight Time. same place, different clock setting. 16:16 jrb mclasen: it'll be EST here in half a year 16:16 otaylor (Standard Time vs. Summer Time ... very confusing) 16:17 GTKool yes, Summer time ... GMT is less confusing, no ? 16:18 mclasen anyway, do we have agenda items beyond the ones I posted below ? 16:21 jrb mclasen: only other issue I came up with was those overwrite dialogs 16:21 * mclasen wonders where colins server is hosted - why is it around noon in the logs ? 16:21 walters mclasen: longstanding bug in java->javascript date conversion IIRC 16:23 mclasen jrb: overwrite dialogs as in "ask before returning an existing filename from a save dialog" ? 16:23 jrb mclasen: yeah 16:23 jrb mclasen: hang on 16:24 jrb http://mail.gnome.org/archives/desktop-devel-list/2005-May/msg00045.html 16:24 walters oops 16:24 walters did anyone else just get an error dialog? (jrb, halfline, mclasen) 16:24 swalter yep 16:24 mclasen me too 16:24 GTKool also me 16:24 halfline walters: synchronization error 16:24 jrb alright -- ignore that 16:25 * jrb tries once more 16:25 jrb mclasen: the mail was http://mail.gnome.org/archives/desktop-devel-list/2005-May/msg00045.html 16:26 * dmalcolm notes you could have multiple documents open when _quitting_ an app 16:26 dmalcolm oops 16:27 * dmalcolm goes back to sleep 16:28 mclasen jrb: is there much to discuss about this ? I think we clearly cannot provide a dialog thas suitable for complicated multi-document situations 16:29 federico something like array_of_bools confirm_for (array_of_document_titles), perhaps? 16:29 jrb mclasen: possibly not. It was more that I wanted to note the existence of the issue. I think we have a bug in bugzilla against the file chooser for it already 16:29 mclasen but we could provide a dialog that covers simple situations, and just return the information wether the file exists or not otherwise 16:29 federico and the dialog would present a list with check boxes 16:30 federico possibly with a signal to indicate when a document must be brought to the front, to let the user double-check for them 16:31 jrb federico: is there a bug for this? 16:31 otaylor jrb: The file chooser is something else right? for overwriting? 16:31 mclasen I think these are two different dialogs 16:31 mclasen one is a check-for-overwrite dialog in connection with the save dialog 16:31 mclasen the other one is unsafed-changes-before-quit 16:32 jrb mclasen: we should definitely be able to provide the first 16:32 federico jrb: I don't think so 16:33 federico but yes, we definitely want a check-for-overwrite thingy for the file chooser 16:33 mclasen i think there is a bug, federico 16:34 mclasen it is GNOME bug 152850 16:35 mclasen hey, it even converts urls into "GNOME bug" shortcuts 16:35 federico mclasen: that's for confirm-on-overwrite 16:35 federico oh my god 16:35 federico tab completion works for nicks! 16:35 federico nice! 16:35 mclasen i would have expected the expansion to be one-way 16:37 mclasen ok, maybe I should say a little bit about the introspection prototype 16:37 jrb (as an aside, that error dialog earlier looks to be a bad bug.) 16:37 * muppet perks up 16:37 jrb (people can't reload the page at all or join until we fix it. ) 16:37 mclasen it is in cvs in the gobject-introspection module 16:38 jrb (so don't reload) 16:38 mclasen it has a long TODO list in there 16:38 jrb (also, don't post url's on a line by itself without some preceding text) 16:39 mclasen and it would be really helpful if people would start toying around with it 16:39 jrb to that extent, I made a poppler gidl file 16:39 jrb (posted to gtk-devel-list) 16:39 mclasen jrb's poppler idl file already nailed quite a few segfaults 16:40 muppet was there intent to add a way to invoke functions without libffi? (jrb) 16:40 mclasen yes, there is the intent to add some way to invoke functions 16:40 jrb I started writing code to load it in from disk, but quickly ran out of interesting things to do with it 16:40 jrb jdahlin: so I need your help. (= 16:41 mclasen I would actually be happy if someone would look into writing the invoke functionality 16:41 mclasen probably by borrowing bits and pieces from libffi or xpcom 16:41 federico has anyone made a prototype or something, or thought about how a language binding will look once this is finished? 16:42 federico e.g. does it read the gidl and intern a bunch of objects into the runtime, or what? 16:42 muppet i'd love to have gtk2-perl be just a binding engine that does everything dynamically. 16:43 muppet at boot time, we'd make GType to perl package mappings, and use AUTOLOAD magic to create subs on first use 16:43 jrb federico: that's what I was looking at. 16:43 muppet the subs will thunk down to gtk+ through the introspection data. 16:43 jrb federico: I wanted to try quick Python bindings 16:43 mclasen jrb: you don't really need to write the code to load it, you are supposed to use the repository api to navigate the metadata... 16:43 federico jrb: nice! 16:44 jrb mclasen: er, yeah. by load it I mean do something interesting with it 16:44 mclasen ah ok 16:45 muppet torsten is working on perl bindings for the instrospection api to try to write the engine in perl, but we need a way to invoke functions through it. 16:45 jrb mclasen: eg, I feel like I just got a dom node. Which is cool, but pretty useless inof itself 16:45 mclasen sure, without invoke its rather sterile 16:45 jdahlin jrb: neat 16:46 jdahlin jrb: so what is the next step? 16:46 jrb jdahlin: I don't understand pyobject well enough. I need to create a class object 16:47 jdahlin jrb: perhaps we should create a separate branch or a separate module in cvs which we can work on, creating a class for example is easy 16:47 jrb jdahlin: should be fairly straightforward (I imagine) 16:47 otaylor muppet: I don't think perl bindings to the introspection API are ever going to give the necessary performance 16:48 muppet otaylor: i agree, but it's an easy way to prototype. 16:48 swalter jrb: I'd be interested to see what code you have for python as well 16:48 jdahlin otaylor: one thing we are pondering to do in pygtk is to have a dynamic namespace, where types/classes are created lazily 16:48 jrb jdahlin: yeah. I think that would be good. Do you think that this could be done external to pygtk? Or are we going to need to make changes to it 16:49 jrb mclasen: oh, one other issue we touched on is namespace resolution/mapping 16:49 mclasen yes 16:49 jdahlin jrb: not quite sure on that, but I'm leaning towards external 16:51 mclasen regarding namespace resolution, the current repository code just knows the namespaces that have been registered, ie you need to link against/dlopen a library to get the metadata 16:51 mclasen to go beyond that, we would need some registry that maps namespace ids to shared objects containing the metadata 16:52 muppet wouldn't that have to be part of the bindings? 16:55 mclasen sorry, I have to drop out at this point 16:56 mclasen ...family business 16:58 walters ok, javascript error should be fixed 16:58 jrb (just in time for meeting's end)( 16:58 seth ha ha ha 16:58 jrb jdahlin: so, should we just make a new module and try something out, then? 16:59 * walters looks expectantly at everyone else 16:59 seth 17:00 muppet it seems like the invocation is a really important bit (jrb) 17:00 muppet anybody have the itch to do that? 17:00 jrb muppet: you do! 17:00 muppet well, i have the itch, but not the time. 17:01 * halfline hates untimely itches 17:01 muppet earliest i could work on it would be when the mother-in-law comes to keep the kids 17:01 muppet weeks away 17:02 jrb we may need it sooner than that.. 17:02 * jrb shrugs 17:03 swalter what's wrong with libffi? 17:03 muppet portability, mostly 17:04 muppet that, and i'm not incredibly familiar with it ;-) 17:04 otaylor swalters: Well, it's not actually a standalone *lib* 17:04 jdahlin jrb: sounds like a plan 17:04 otaylor That is, nobody is packaging it standalone .. there's a copy in libgc, and hten a copy that was released about 5 years, ago and some tarball somebody random made 17:05 swalter does xpcom have anything sufficiently independent? 17:08 seth (walters) 17:09 jrb /me removed the 'seth is a vandal' comment prematurely... 17:09 jrb swalter: we might be able to steal code from it. But again, someone has to do the work 17:12 jrb anyway, looks like we're reaching the end or useful discussion, especially w/ mclasen AFK 17:12 muppet damn 17:12 jrb muppet? 17:13 federico 17:13 muppet i came for the introspection stuff. i'm really tired of hand-maintaining bindings. 17:13 jrb muppet: yeah. 17:14 jrb muppet: have you actually looked at them yet? 17:14 seth 17:14 muppet i've been following since the first email on the list 17:15 muppet i think i have a sound plan for using the i11n stuff, but without a way to make it actually *do* anything 17:15 muppet it's just messing around. 17:16 jrb 'i11n'? cute 17:16 mathrick how do I make it not scroll when someone says something? 17:16 mathrick it makes reading backlogs kinda annoying 17:16 jrb mathrick: er, hrm. good question. I think hold down the scrollbar 17:17 muppet otherwise, the prototype's API looks like it's complete enough 17:17 mathrick jrb: no worky :\ 17:17 jrb mathrick: yeah -- I'll add a bug 17:17 muppet have you tried doing a method lookup or anything like that? 17:17 mathrick muppet: are you talking about introspection now? 17:20 federico ping 17:20 seth federico: pong 17:20 mathrick federico: pong 17:21 walters test 17:22 federico so, guadec meeting 17:22 federico sandino's slot will be open 17:22 federico we can steal the room for an hour 17:23 jrb is an hour enough? 17:23 federico jrb: it's never enough, but you can probably not bring beer in there, either :) 17:24 jrb federico: when is it? 17:24 mathrick muppet: there? 17:25 federico jrb: sunday 12:00 17:25 federico umm 17:25 federico that's the same time as owen's talk on cairo 17:26 muppet mathrick: here 17:26 jrb yeah, bad time 17:28 mathrick muppet: how does tree api look in perl? 17:28 mathrick muppet: I was thinking about what'd be needed to implement PyGTK's one 17:28 muppet what sort of tree? 17:28 mathrick muppet: and I don't really have clear idea yet 17:29 mathrick muppet: TreeModel and friends 17:29 mathrick muppet: I mean in context of introspection 17:29 muppet how so? the iface versus class? 17:29 mathrick muppet: it's going to be problematic, pygtk currently heavily relies on availability of python idioms 17:30 mathrick like: 17:30 mathrick for row in treemodel: 17:30 mathrick .... 17:30 mathrick gah, it eats indentation 17:30 mathrick jrb: make it not do that :) 17:30 walters hm, could be our xml parser 17:31 muppet mathrick: i think i get it 17:31 muppet for the most part, you just use the C api. we have a SimpleList, which uses tie magic to make the model look like a native perl array 17:31 muppet but the tie magic is implemented in perl using the normal api. 17:32 swalter how would you do that through introspection, though? 17:32 mathrick muppet: yeah, but now we enter bindings fully autogenerated 17:32 muppet but this tie magic is pure perl code. 17:32 mathrick muppet: when you need to infer all that from metadata only 17:32 mathrick muppet: but it's gtk-specific 17:32 muppet well, we need to retain backwards compatibility with existing code. 17:33 mathrick introspection by definition is to be agnostic 17:33 mathrick muppet: sure, but how? 17:33 muppet so there will be many bits of the API that must be hand-tweaked. 17:33 mathrick muppet: well, if introspection means we need to give away idiomatic code, it's not all that sweet deal :\ 17:33 jrb muppet: there may be. eg, we don't really have a good way of indicating that a method maps nicely to things like brackets 17:34 muppet exactly. 17:34 muppet for example, GnomeCanvasPoints are represented as normal perl arrays instead of an opaque boxed type. 17:34 swalter something like an is_iteratable flag on objects? 17:34 swalter something like an is_iteratable flag on objects? 17:34 mathrick I need to think about adding attributes to prototype, annotations like that could help a lot 17:34 jrb swalter: rough with GtkTreePath, but maybe 17:34 mathrick swalter: yeah, but better make it free-form data 17:34 muppet we do that with a custom boxed wrapper class at the binding level. i can't see that going away. 17:35 mathrick rather than hardcode into metadata format 17:36 muppet my lag seems to be really bad 17:37 muppet something like GtkTreeIter is already hard to bind with hand-coded bindings (from the implementing a model in X language POV) 17:37 muppet i can't imagine we'd be able to do pure introspection on that, either. 17:37 muppet there will have to be some sort of special-case code. 17:37 muppet but it would be nice to keep it to a bare minimum. 17:38 mathrick muppet: we could create language-specific annotations, as kind of middle-ground 17:38 muppet but why would i want gtk2-perl's annotations down in gtk+? 17:38 mathrick muppet: this way you would at least keep all the info in one place, together with library you're binding 17:39 mathrick muppet: because some of the could be shared 17:39 swalter what's language-specific about "use the list of rows when this object is in list context?" 17:39 mathrick for example, iterator concept is pretty common 17:39 swalter exactly 17:40 muppet i'm perfectly happy with conceptual annotations, but language-specific ones don't make sense. 17:40 muppet expressions like " 17:40 muppet represent this type as a language-native data structure" would be good 17:41 mathrick muppet: why? if you keep all the annotations together with library, it's already a win 17:42 swalter who picks what languages get to have annotations in the library? 17:42 muppet it's really a logistics problem. 17:42 mathrick swalter: I guess library maintainers 17:43 muppet it makes an upstream know what is downstream. 17:43 mathrick well, yes, but if amount of really language-specific stuff isn't very high, it should be doable 17:43 muppet but it means if a binding decides to change an internal implementation, he has to communicate with the upstream to change an annotation 17:43 muppet which causes versioning issues, yadda yadda yadda 17:44 muppet i don't know yet how much specific tweaking we'll need. 17:45 muppet it has to do with how much work it is to maintain existing API with the new tools. 17:46 mathrick yes 17:47 mathrick which is why we need to see how easily can the prototype be made to work acceptably with something like trees 17:47 muppet well, like i said, as long as the C-ish API works, the perlish one will be happy 17:47 mathrick jrb: poppler has something iterable, you mentioned it, no? 17:47 muppet i'm more worried about GtkTreeIter 17:48 muppet i jumped through very unnatural hoops to implement a TreeModel in perl code 17:48 jrb mathrick: nah 17:48 jrb mathrick: poppler is really simple. Two GObjects, a couple structs, and a bunch of enums 17:49 mathrick jrb: k 17:50 mathrick muppet: exactly treeiter is issue here, it's easy to get binding that will just map C to python/perl names :> 17:51 muppet how thick is the python wrapper for TreeIter and friends? 17:51 muppet as i recall, custom treemodels inherit from a C model implemented in pygtk's C code, right? 17:51 mathrick hmm, jdahlin ? 17:51 mathrick muppet: yes, something like that 17:51 jdahlin mathrick: fairly thin, just a class wrapping the most important methods 17:52 jdahlin the GtkTreePath is opaque, you can use numbers, strings or tuples. 17:52 muppet with lifetime gotchas for putting python objects in the treeiters? 17:53 jdahlin well, you're not actually putting anything inside the iters, they are just iterators, like in C 17:54 muppet but you need to fill out the iters when you're implementing a custom model 17:56 muppet i think most things should be doable with abstract annotations 17:57 mathrick polimorphic indexing will be fun 17:57 mathrick but doable 17:57 muppet it's these dark alleys of the API that will be problematic 17:57 muppet it's these dark alleys of the API that will be problematic 17:57 muppet oos 17:58 mathrick muppet: obviously, it's hard part that will be hard :) 17:58 muppet that's why i say it will be unlikely that we get a 100% pure introspection binding. 17:58 muppet for new libraries with brand-new bindings created in the future, maybe so. 17:58 muppet but for gtk+, and other existing bindings, it's unlikely. 17:59 muppet somebody was talking about on-demand type loading 18:00 muppet how are you thinking of doing that? 18:00 mathrick muppet: that's out of scope 18:00 mathrick I think 18:00 muppet maybe not 18:01 muppet i can't think of a way to avoid having some code in the bindings that provides a mapping from GType names to perl package names. 18:01 mathrick hmm, why did yarrr start showing "19:xx" (wrong) in timestamps, instead of "23:xx" (right, and that was shown before)? 18:01 muppet e.g. GtkWidget => Gtk2::Widget 18:02 mathrick muppet: that will be namespacing only 18:02 mathrick shouldn't be that hard 18:02 muppet does GdkEvent get its own namespace? 18:03 muppet GdkEventButton => Gtk2::Gdk::Event::Button 18:03 mathrick muppet: yes 18:03 muppet aaaah, i was thinking it was toplevel namespace for the whole library 18:04 mathrick no, don't be silly :) 18:04 muppet forgive me, it's been a long day 18:05 mathrick heh 18:08 muppet hate to run but i need to get food for the family 18:08 mathrick cya 18:08 muppet mathrick: continue some other time? 18:09 mathrick muppet: sure 18:09 mathrick muppet: we should discuss it as prototype advances 18:10 * muppet runs off to hunt and gather 18:11 mathrick :) Summary of the discussion: Possible agenda items: - guadec meeting - introspection prototype TODO items that would be interesting projects: - implement invoke functionality - complete a language binding (eg poppler) - start the header scanner to create idl - (relation to dbus?) - Confirmation dialog (http://mail.gnome.org/archives/desktop-devel-list/2005-May/msg00045.html)