Meeting in yarrr Meeting started April 26 2005 16:04 EST (22:04 UTC) In attendence: Matthias Clasen (mclasen), Seth Nickell (seth), Alex Larsson (alex), Federico Mena Quintero (federico), Jonathan Blandford (jrb), Owen Taylor (owen), Colin Walters (walters), Johan Dahlin (jdahlin), Shawn T. Amundson (shawn) Hi hi seth squeeeeeeeek Hey everybody ... when you join you should change your name from 'anon' And shorter nicks are better right now due to CSS stupidity :-) alex: Would it be ok to create one or two? Or do they just keep leaking? ick! It still says proponents. seth: unknown so, the first thing we need to figure out (after the yarrr excitement settles) is the agenda for today seth: make them as needed jrb: yeah, that's what I was saying... I hope they use them if its relevant, we just shouldn't go tempting fate for no good reason ;-) owen - i would have left that comment open seth: eg, if you have an actual GTK+ thing that needs drawing out. Maybe owen can grace us w/ a drawing of his thing Yes, I realized that after I closed it - "Add" didn't seem like "Close" to me owen and I think it would be a good idea to check up on where we stand wrt to 2.8 owen: i'd just open a new one and copy/paste oops, comments never got changed to newest first basically discuss the status of the things on www.gtk.org/plan/2.8 Umm, what happened to the text in my comment when federico edited it and closed it :-) ok, i'll try ah, I didn't notice owen already used his superior yarrr ability to set up an agenda... the gray area below is a "Live Comment" think of it kind of like a shared email at least, that's the way I think of it walters: Shoosh! walters: You're interfering with my observation when we come to a conclusion on it, someone clicks "Send" seth: oops =) walters: Shoosh! did we miss people from #gtk-devel, or is everybody here now ? Test stuff in [PlayPen] OK, on Cairo, we are getting close to API stability ... we should get a 0.5.0 out with the last *changes* (not additions) in a week or so The work I was doing on converting GTK+ to use GTK+ cairo got somewhat stalled because I got bored ... replaces rectangles with rectangles wasn't very interesting why can't I open a new comment? owen: does it buy us anything? owen: I saw pixbuf formats on your 1.0 roadmap for libpixman jrb: It buys us a couple of things: federico: hmmm...not sure - We get rid of mixed drawing with Cairo and Xlib, which allows additional optimization - Helps people if they are working on a GDK backend without native drawing (though implementing gdk_draw_* on top of cairo would be good before that) Also, gdk_draw_* will be deprecated eventually (though probably not formally in GTK+-2.8) /me is not looking forward to a clientside gdk_draw_arc implementation... /me is broken I don't think we'd require pixel-by-pixel accuracy Is cairo going to make rendering slower (in the short term) ? federico: The server admin must have turned on access controls for you in response to your vandalism ;-) owen: that is breaking historical requirements for gdk_draw though jdahlin: Right now, it's slower federico: why not ask your question in the chat? There's even spiffy wiki support alex: It's not clear what those requirements are jrb: because I like the anyone-can-edit-this windows :) "RecentFilesAndBookmarks" wiki page federico: I think they're cool too The windows backend has never had pixel-by-pixel matching owen: historically, haven't we used the X pixel requirements? Urr, new comment vs. Add is *confusing* owen: already noted :) alex: Only for a few things like horz/vertical lines, rectangles .. things we could match alex: it was never explicitly documented (Open Comment is unclickable for me as well) owen: i think you need to click more to the right on the button owen: do you want to make gdk-pixbuf use libpixman anytime soon ? alex: OK, next time I'll try that owen: it seems like a lot of work for little gain owen: eg, shouldn't we just consider gdk_draw_ deprecated, and suggest people use cairo directly if they're drawing anything jrb: I think it's actually not much work at all, especilaly if we are willing to drop XOR jrb: I think we do consider gdk_draw_* deprecated, but it will be a long time before all such are gone from code owen: so, would you expect gdk_draw_ to use cairo on X? jrb: the one argument in favour of redoing gdk_draw on top of cairo is that backends get easier what are the "me too" things on the left side? quick polls? oh, you said that already.... alex: Not sure, maybe eventually. It would help a lot on the no_RENDER case since you could then do all rendering licent side Anyways, I think the work items inside GTK+ are: Anyways, I think the work items inside GTK+ are: owen: gdk_draw without xor will likely break some aps - Fix clipping of text won't that suck on old X servers (sun, whatever) - Finish the GtkStyle drwaing code conversion - (Not really inside GTK+) work on a theme that actually shows of Cairo ... might involve finish the draw-outside-widget-bounds work that started on the rendering-demo branch The basic idea of that was that a widget had a style property that said how far outside its bounds the theme woudl draw, then you propagate up the tree and use that for queue_draw(), propagate_expose() and so forth owen: for the out-of-bounds drawing, is there some form of stacking control ? are child widgets always drawing on top of their parents ? mclasen: Stacking is just like today ... determined by draw order This really won't work well in Eclipse which puts every widget inside a window so, do you draw on the parents GdkWindow (for window widgets) alex: Hmm. I was hoping we could avoid that issue because we don't have many subwindows, but I'm not sure if that always works. as an aside, vektor was mumbling about a patch to add z-order to gdk -- presumably for eclipse Yes, I've talked about it some. (with him) I have some cool ideas about how to do Z-order mixing window and no-window widgets - but that's more blue-sky stuff. mclasen: Do you want to give a summary where we are with introspection? I'll try I put my introspection prototype work into bugzilla some time ago It is still fairly incomplete I have - an xml format - a binary format - a compiler to convert from xml to binary - a repository api and implementation - a utility to regenerate xml from binary metadata using the repository api and roundtrips xml->binary->xml work for simple testcases hi guys - verbum.org memory usage is nearing 90%. The server seems to be holding so far, but I think we have a reference leak somewhere there is a lot of things that need work: just a note that you may encounter problems soon. If so I can restart the server and any closed comments will be persisted, along with their related chat - I haven't started on a scanner for going from (annotated) headers -> xml - invoke functionality is not implemented at all - I'm not very happy with the current repository api, it may need to be redone and there are many smaller things missing as well There are quite a range of scanners around ... we'll have to look around ot figure out which (if any) should be started from for the header scanner gtk-doc, for one. Then a bunch in different language bindings. that was the plan, basically. the xml format started out from the one used by gtk# and evolved a bit so it may make sense to look at the scanner used by gtk# mclasen: Is the gtk# scanner written in something usable, or is it in c#? it is in perl IIRC (Some people may be finding "perl usable" "C# unusable" a bit of a stretch" ... but in terms of what I'd want to make GTK+ depend upon...) The pygtk one is written in python and is basically a big hack of regexps and that is one thing we need to do, too mclasen: Does the XML reggeneration utility use the introspection API? owen: Funny how working on it the night before a demo tends to destabilize things ;-) Funny how having to demo something tends to destablize things :-) ha ha what's the intended way to create language bindings once introspection is done? federico is still a vandal (= does it work again ? test It's going to be different for dynamic and static languages, clearly For static languages, you'd probably generate the bindings much like today, but from the canonical introspection information rather than from manually maintained .defs files safari doesn't much care for this page owen: the xml regeneration utility uses the introspection api, yes shawn: no, only firefox for now shawn: [BrowserCompatibility] For dynamic languages, you could theoretically just generate the bindings completely at runtime owen: seems slow So in theory 'import libgtk-x11-2.0.so' is all you need to use GTK+ once you have the GObject binding jrb: It might actually be a lot faster because you don't have huge piles of code sitting around for stuff you never use jrb: the bindings would be generic and just interprete the metadata kde has a pretty magical "turn this qobject into a dcop service" jrb: the bindings would be generic and just interprete the metadata jrb: There is no reason that walking the introspection information to go from Python to C has to be slower than walking Python bytecode to do the same jrb: The dynamic marshalling stuff wasn't a bottleneck for CORBA::ORBit when I did that that way Meeting moved back and forth between yarrr and IRC at some points, here are some partial logs of the IRC parts of the meeting: ok, so it is 4pm, and yarrr hasn't appeared yet, so I guess we should start the old way, and maybe give the yarrr team another week to fix OOM issues... we might be able to give it a shot, though it's fallen over a few too many times today should we try now, or not ? lets give it a shot and if it falls over in 5 min, we can fall back to irc http://verbum.org:8080/yarrr/topic/gtk-devel-meeting exciting... maybe you need to give a 60 second intro to using jarr, yrb I think we are just supposed to try it out and see if we can figure it out ah, ok. I'll try did everybody get over to yarrr, or did we loose some people ? mclasen: I think everyone here was around when it was posted Hmm, seems to be unresponsive. Did we kill it? owen: its down for me too time to restart restarting... 35 minutes, not bad mclasen: yeah. and the closed comments/logs will stick around restarted Reload the page are we stuck again ? yo-yo can someone repaste the url? http://verbum.org:8080/yarrr/topic/gtk-devel-meeting but it's broken it'll be back in a sec hopefully for longer It did so well the first time yosh: can you set the topic to be "meeting held at http://verbum.org:8080/yarrr/topic/gtk-devel-meeting" when you join, be sure to change your name from anon OK, meeting moving back here Yay! :) * mclasen would have loved to see some whiteboard fun It was staying up too long for you? well, we can demo that after the meeting Yeah, we should restart just to show the wihteboard (especially for federico ) Its the best part... ok, so what i was unsuccessfully trying to say in yarr: work needed for introspection: - experiment with the prototype to see if the api is reasonable, if information is missing, and where the implmentation is broken/incomplete - write an xml description of a small library to see how that works (thanks guys for being patient) - eventually we will have to test how the stuff scales to something the size of gtk, but that is probably more practical when we have a scanner regarding possible slowness: we discussed adding hashes to the binary format for common lookups e.g to look up functions in interfaces I don't see that I will be able to complete the introspection stuff on my own so help on any of the outlined work items would be highly welcome mclasen: I think to really make progress we'll have to get to the point where it is semi-useful for something pretty quickly owen: my plan for the near future is to work on the icon view features for the rest of this week hoping to get them to committable state sometime next week and then go back to introspection work oh yeah mclasen: I want a get_visible_rows()/"::visible-rows-changed" pair thats for the icon view, or the tree view, or both ? both mclasen: more pressing for the icon view, as you can kinda do it w/ the TreeView already how would you return the visible rows ? list of paths ? mclasen: yeah or maybe just a range first path/last path tberman wants something like that as well for the icon view its a bit more complicated, since it can be a nonconsequtive set of rows jrb: I'm not sure what's best, really. mclasen: can it? he actually wants a custom widget to do DB lookups based on what you type, sort of a fancy gtkentrycompletion, but still... with a fixed number of columns, you can mclasen: oh, of course it can, yeah have items hidden to the left and the bottom, eg jrb: if you promise to look into the treeview implementation, I will look at the icon view side the icon view probably needs some scalability love, in general mclasen: okay. TreeView should be easy mclasen: though it probably wont' be treeview and easy don't go together ok, I want to jump on the bike in a few minutes I seem to recall there was a dbus topic on the agenda mclasen: that was federico oh yeah asking about recently used files I want to implement RecentFilesAndBookmarks so that the file chooser can use it federico: I don't think a dependency on dbus for 2.8 is reasonably wouldn't the implementation live in the filesystem backends anyway ? federico: You could do it in gnome-vfs backend maybe if alex is more lenient..... dbus isn't 1.0 yet, I don't think making gtk+ depend on it at this point is a good idea hmm (cairo)... haha but I agree owen: that's the thing - I don't want to reimplement things just for the unix backend Well, it's clearly not applicable to Windows can we have gtk+/gtk/x11 like in gdk? I'd like gtk's implementation of RecentFiles to be usable by any app Should there be a pbulic cross-platform recent files API? Apr 26 17:21:25 --> mathrick (~mathrick@195.116.35.55) has joined #gtk-devel at what kind of functionality are we looking here, I guess basically just adding files to recent-files and setting some app id, the rest would be handled by the file chooser ? well, we would probably need a way to list the recent files, for constructing menus and such owen: I don't care about windows; I care about the file chooser and gnome apps :) federico: Sorry, if you want to propose GTK+ APIs, you at least need to think cross platform mclasen: yeah, basically that. Think of a sanitized EggRecent API (If we don't think cross platform, then the APIs get ported cross platform anyways, and suck on Windows... that's the history) ok, I'll ask tml about it I guess the same principle holds for the (currently not public) mime api We do have a problem somewhat in GNOME that we don't have a good place to put libgfreedesktop libggnomedesktop stuff that isn't cross platform, but people seem to always want stuff cross-platform in any case mclasen: yeah mclasen: confusingly enough, I have a patch from tml to make xdgmime compile/work on windows mclasen: but w/ the xdgmime database (See above comment about "anways, and suck on WIndows") jrb: does it embed a cache in the libary ? owen: one thing that concerns me is that at some point we'll have to make gtk depend on freedesktop-ish stuff like d-bus ... if we are to get a nice platform federico: For? federico: A platform specific dependency on dbus is no different from a platform-specific dependency on X mclasen: 'embed a cache'? dbus will presumable get ported to win32 at some point, or is it already ? federico: If you want to make dbus part of the public API, that's a different set of considerations jrb: thats how I would do it. the cache is just a blob you can stuff into a const variable mclasen: I think jrb meant "with the", not "without the" - as opposed to using native file type facilities on windows ah, ok doesn't w/ mean with? its kind of ambiguous I think owen: I'm not sure at the moment. But doing Interesting Stuff(tm) with a notification API is very tempting :) mclasen: if it's ambiguous, I'd better not use it I don't think it's ambiguous, I think it always means with :) I think it means with, but it's close to a tpo for w/o jrb: I saw things like "meet w/ bla" in peoples notes jrb: which meant "meet with bla" rather than meet without bla gotta go Apr 26 17:30:38 --- federico is now known as f_lunch okay. enough discussing w/ w/o consensus anyway, the meeting is w/o /me from now on... see you next week we'll have a better yarrr for then I hope the yarrr crew can secure todays logs mclasen: I mailed you them c-n-p'ed out of my browser cool, thanks (I think I missed the first short-lived restart, but got most of it) Below are the "Summaries written during the meeting in Yarrr. Closed by alex - Today 16:04 Please don't create any whiteboards. There is some memory leak problems with them. Proponents: alex Closed by owen - Today 16:05 Today's topic: GTK+-2.8 planning - where we are on - Introspection - Cairo Proponents: Closed by federico - Today 16:06 This is a test Proponents: federico Closed by federico - Today 16:07 What? did I change anything? Proponents: Closed by owen - Today 16:15 Can d-bus live below gtk+? I want to implement live.gnome.org/RecentFilesAndBookmarks in terms of d-bus to avoid all apps doing their own lockingI Proponents: Closed by owen - Today 16:29 Left to be done for cairo (summarization): - Fix clipping of text - Finish the GtkStyle drawing code conversion - work on a theme that actually shows off Cairo (interesting themes often involve drawing outside a widget's allocation, so depends on support for that which is currently prototyped in a branch in cvs) Proponents: Closed by owen - Today 16:30 gdk_draw_* using cairo: Pro: Makes writing backends easier Automatically get pure Cairo Con: Wouldn't match pixelixation requirements (Do we have them? Win32 never has matched exactly) Lines/rectangles are easy to (re)match - for rounded radio buttons and such, we may as well rewrite their expose methods to use real curves Proponents: