Meeting on irc.gnome.org:#gtk-devel
Meeting started Nov 16 2005 16:00 EDT


In attendence: 

Matthias Clasen (matthias)
Kristian Rietveld (kris)
Anders Carlsson (ac_school)
Tim Janik (rambokid)
Federico Mena Quintero (f_lunch)
Carol (carol)
Carlos Garnacho (garnacho)
Michael Natterer (mitch)
Emanuelle Bassi (ebassi)
Jean Brefort (jean)
Behdad Esfahbod (behdad)


[16:00:14]  <matthias> hey, so we should probably start
[16:01:06]  <kris> oh
[16:01:06]  <matthias> so, I don't have any specific agenda items
[16:01:08]  <kris> yeeh
[16:01:13]  * kris forgot about the meeting :/
[16:01:18]  <kris> but i am still here in time!
[16:01:24]  <ac_school> matthias, I do
[16:01:36]  <matthias> bring them up
[16:01:40]  <ac_school^ so I guess I'm ready to add the gtk+ and pango macosx parts to CVS now
[16:01:48]  <matthias> ah, cool
[16:02:14]  <ac_school^ I figure the best way would be to create patches and make bugzilla bugs, right?
[16:02:23]  <ac_school> at least for pango and the parts in gtk which are changed
[16:02:32]  <ac_school> (such as configure.in)
[16:02:34]  <carol> matthias: too bad about the agenda. i would have liked to add tickling ac_school to it.
[16:02:45]  <matthias> ac_school: if the patches are huge, I'm not sure they buy us much over a cvs branch
[16:03:18]  <ac_school^ would there be any problem with adding them to HEAD if they don't break anything?
[16:03:21]  <kris> q
[16:03:23]  <kris> eek
[16:03:46]  <matthias> ac_school: not really, no.
[16:04:11]  <ac_school^ but I'd really like someone to review the diffs to configure.in and Makefile.am
[16:04:18]  ***  rambokid has joined chat #gtk-devel.
[16:05:02]  <matthias> although we may want to keep macosx support out of pango head, if we go for a performance-only pango release for 2.14
[16:05:14]  <ac_school^ oh, ok
[16:05:39]  <ac_school> I guess that's not a problem...
[16:05:41]  <matthias^ if you have diffs, putting them in bugzilla would be good
[16:05:58]  <ac_school> I'll definitely do that tomorrow then
[16:05:59]  <ac_school> cool!
[16:06:34]  <matthias> while you are all here, I wanted to say that I'm really happy to see the amount of GTK+ work done by you Imendians recently
[16:06:44]  <matthias> greatly appreciated
[16:06:51]  <ac_school> :)
[16:07:43]  <matthias> rambokid: you said you have only a few minutes...anything you want to discuss while you are here ?
[16:08:44]  ***  f_lunch has joined chat #gtk-devel.
[16:08:44]  <kris> last week we had the filechooser async stuff on the agenda, i dont think anyone has anything to mention on that right now?
[16:08:48]  <rambokid> matthias: i said i'll be late. i'm gone again this second but will be around in 15min or so ;)
[16:08:49]  <kris> since it was mostly discussed on the list
[16:08:58]  <kris> (and i need to write a reply or 1 or 2)
[16:09:06]  <f_lunch^ go ahead on the plan - make a branch as we discussed, etc :)
[16:09:10]  <kris> yeah
[16:10:10]  <matthias^ I really liked the longterm plans federico mentioned, with delayed loading of icons and multipass mimetype determination
[16:11:44]  <f_lunch> it's a double-edged sword... it's more or less what nautilus tries to do
[16:11:54]  <f_lunch> with about 347 layers of abstraction
[16:12:17]  <f_lunch> anyway
[16:12:28]  <f_lunch> I think I fucked up GtkFileChooserButton for 2.8.current
[16:12:39]  <f_lunch> will try to fix it this week
[16:12:40]  <matthias> how ?
[16:12:51]  <f_lunch^ it doesn't work in folder mode
[16:12:57]  <f_lunch> it appears blank, and spews warnings
[16:13:00]  <carol^ when?
[16:13:22]  <matthias> Smells like a quick 2.8.8...
[16:13:25]  <f_lunch> carol: when I committed my patch for "don't load the current folder before getting mapped"
[16:15:15]  <carol> 10-07. thanks
[16:16:08]  <matthias> when is the next gnome 2.12.x ? we should probably fix the filechooserbutton before that
[16:16:39]  <f_lunch> tarballs are today, I think
[16:16:47]  <f_lunch> or maybe that is 2.13.x
[16:17:06]  <matthias> 2.12.2 tarballs are due nov 28
[16:17:11]  <f_lunch> ah, ok
[16:17:18]  <f_lunch> no problem
[16:18:19]  <matthias> mitch: how well is display closing working in HEAD now ?
[16:18:32]  <f_lunch> has anyone continued the printing stuff?
[16:18:41]  <matthias> no
[16:18:58]  <matthias> we need to pick that up again
[16:19:00]  <f_lunch> we should nail that soon
[16:19:17]  <f_lunch> on a totally unrelated note...
[16:19:28]  <f_lunch> you know the mandelbrot guy on #gtk+
[16:19:51]  <f_lunch> newbies have a *horrible* time understanding this async window system thing, with no retained graphics
[16:19:53]  <rambokid> i'm back.
[16:19:55]  <f_lunch> and I was thinking
[16:20:04]  <f_lunch> what if we had a GtkEasyDrawingArea
[16:20:17]  <f_lunch> that keeps a cairo image surface of its own, exposes it when needed
[16:20:27]  <f_lunch> somehow gets to know when the surface gets dirtied, and queues an expose
[16:20:27]  <f_lunch> etc.
[16:21:39]  <matthias> we can do that as soon as we finish wrapping GtkTreeView in GtkEasyTreeView...
[16:22:29]  <kris> (i also need to look at tooltips still btw)
[16:22:59]  <garnacho^ and I should have sent my work in progress patch...
[16:23:04]  <kris> ;)
[16:23:14]  <matthias> f_lunch: but don't you think gtk as a whole gets more confusing if we add "easy" widgets which use a different model ?
[16:23:36]  <f_lunch^ well
[16:23:52]  <f_lunch> people seem to handle signals more or less fine
[16:23:56]  <f_lunch> but they *all* stumble with drawing
[16:24:01]  ***  ac_school has left chat #gtk-devel (Remote closed the connection).
[16:24:44]  <garnacho> matthias: maybe such widgets should be in a separate pack? just an idea, dunno if you have discussed it previously
[16:27:39]  <ebassi> f_lunch, that would mean we need better documentation for drawing
[16:28:04]  <ebassi> like the gobject and the treeview tutorial helped understanding gobjects and the treeview
[16:28:19]  <matthias> updating/expanding the tutorial would be nice
[16:28:31]  <f_lunch> ebassi: oh, hi!
[16:28:37]  <f_lunch> what's the status on recent-files, btw?
[16:29:27]  ***  Hallski has joined chat #gtk-devel.
[16:29:34]  <ebassi> f_lunch, pretty much stalled - I'd like some more review
[16:29:50]  <ebassi> I've got a patch for Glib HEAD containing the parser object
[16:30:13]  <f_lunch^ stupid question - why can't we use libxml or something?
[16:30:23]  ***  Hallski has left chat #gtk-devel (leaving).
[16:30:25]  <ebassi> f_lunch, gtk+ won't depend on libxml
[16:30:32]  <f_lunch> or whatever parser fontconfig uses
[16:30:56]  <ebassi^ they use expat, but it would mean making it an hard dependency on every platform
[16:32:27]  ***  GTKool_2kx has left chat #gtk-devel.
[16:32:34]  <ebassi> f_lunch, anyway, the gmarkup-based parser is a bit more solid, at this moment
[16:32:42]  <f_lunch^ what was the performance on the gmarkup parser?
[16:33:46]  <ebassi^ I/O plays a big role. a file with 3000 bookmarks gets parsed in 2 seconds, more or less (cold cache).
[16:33:57]  <ebassi> which, I think, is as good as it gets
[16:34:14]  <f_lunch^ any estimates for a 120 KB file?  my ~/.recently-used is 120 KB right now
[16:34:19]  <ebassi> (3000 bookmarks == ~1.5 MB on disk)
[16:34:35]  <f_lunch> that would be 0.2 sec
[16:34:37]  <f_lunch> too slow :)
[16:35:15]  <mitch> matthias: was not here
[16:35:41]  <ebassi> I don't think it cat get much faster, even using expat.
[16:36:19]  <matthias^ I thought you had identified one or two api additions that could speed up gmarkup-based parsers
[16:36:56]  <matthias> like constant time lookup for attributes
[16:36:57]  <ebassi^ the hash-based access to attributes is one, and the building of the namespaces is the other
[16:37:21]  <ebassi> I tried to consolidate the code inside my parser in order to get it right
[16:37:32]  <ebassi> I'll try and port it under gmarkup
[16:38:04]  <ebassi> that would cut down some time, I think
[16:38:08]  <matthias^ does it make sense to look at the current libegg code, or should I wait for your next commit ?
[16:38:11]  <f_lunch> ok, bbiab
[16:38:24]  <matthias> mitch: did you see my question ?
[16:39:46]  <ebassi^ it makes sense - the parser is pretty much ready
[16:40:03]  <mitch> matthias: yes, wanna hear the status?
[16:40:18]  <matthias> yes, that would be interesting
[16:40:46]  <ebassi^ I'd like to try to use mmap() and g_file_set_contents() instead of locking the file, but this should only impact reading and portability
[16:41:02]  <mitch> ok, it's working pretty well, but definitely leaks
[16:41:19]  <mitch> things missing in gdk (that i know of) are input devices
[16:41:38]  <mitch> and scratch gdkimage caches
[16:42:11]  <mitch> in gtk, the gtkgc cache needs to be flushed and the other stuff owen mentioned in the original bug report
[16:42:14]  <matthias> oh, those are per-display ?
[16:42:36]  <mitch> they are x resources and per display, yea
[16:42:42]  <mitch> you mean the input devices?
[16:43:37]  <mitch> apps that "behave" (implement unrealize and screen_changed) are easily migratable
[16:43:40]  <matthias> the gdkimage cache, I mean
[16:43:43]  <mitch> gimp works fine for example :)
[16:43:55]  <matthias> thats already very cool
[16:44:31]  <mitch> hm yea i guess so, they have colormaps and stuff
[16:44:47]  <matthias> do you think it makes sense to add an migration-initiation protocol like I had in my patch ?
[16:45:01]  <mitch> well, gimp crashes badly as soon as input devices are involved, like when opening a window ;)
[16:45:37]  <mitch> didn't look at that patch for quite a while :/
[16:46:17]  <matthias> hmm, so there seems to be quite a bit work left.
[16:46:28]  <matthias> are you still working on the remaining issues ?
[16:46:44]  <mitch> yes, i just fixed one today
[16:47:14]  <mitch> oh you mean the protocol that allows apps to migrated without having them implement everything themselves?
[16:47:41]  <matthias> some protocol which allows the wm to send a 'move to display x' message
[16:47:51]  <mitch> (gimp crashing is its own fault btw)
[16:48:03]  <mitch> yes, just had a look at the patch again
[16:48:29]  <mitch> yea i guess in the long run we definitely want toolkit support for such a protocol
[16:48:31]  ***  _Legion_ has left chat #gtk-devel (Read error: 113 (No route to host)).
[16:49:02]  <mitch> it should be possible to migrate any gtk app without special per-app code
[16:49:27]  <mitch> (except for the apps having to behave of course, like implementing unrealize and screen_changed correctly)
[16:49:31]  <jean> Hi all, I'd like to know if anybody made real work on the canvas ?
[16:50:12]  <mitch> matthias: and actually, i forgot the meeting and have to run now :(
[16:50:20]  <matthias^ those apps have problems anyway
[16:50:24]  <matthias> see you
[16:50:26]  <mitch> exactly
[16:50:32]  <mitch> bbl :)
[16:50:36]  ***  mitch is now known as mitchAway.
[16:51:36]  <matthias> jean: alex larsson did quite a bit of work on making it possible to redirect widget drawing offscreen, which is necessary to embed widgets in a canvas
[16:52:40]  <jean> OK, I'll contatct him and David Bellot
[16:52:58]  <matthias> alex' patch is in bugzilla
[16:53:32]  <jean> thanks
[16:55:29]  <garnacho> matthias: there hasn't been any progress in the GtkAssistant code reviewing process? nothing I've got to fix? :)
[16:56:23]  <matthias^ some progress...its moving up in my list of patches to review
[16:56:39]  ***  behdad has joined chat #gtk-devel.
[16:56:48]  <garnacho> good news
[16:57:24]  <matthias^ sorry for being a bottleneck, but without owen and jrb, throughput is reduced...
[16:57:51]  <garnacho^ yeah, I guess so :/
[16:58:02]  <behdad+ any plan for glib devel release?
[16:58:05]  * garnacho would also like to point to patch in bug 156023, having a GtkCellRendererSpin would be a nice addition to HEAD
[16:58:33]  <matthias> behdad: waiting for rambokids g_slice_ implementation, basically
[16:58:41]  <behdad> ah, right.
[16:59:00]  <behdad> I wish we could make it to 2.13.2
[16:59:13]  <matthias> we could do one with the current dummy implementation, but we missed 2.13.2 anyway
[17:12:33]  <matthias> ok, I need to go


Meeting ended 17:12