15:30:52]  <mclasen>  oh, I think its time
[15:31:48]  <carol^ do you have a list today?
[15:31:58]  <mclasen> i did not send out an agenda, but I think the main topic should be the state of HEAD and how we get to 2.10
[15:32:34]  <mclasen> carol: no idea what list you mean
[15:32:50]  <carol> could you squeeze in a summary of all that print-dialog mail that has been generated recently.  one that is human readible?
[15:32:58]  <mclasen> no
[15:33:05]  <carol^ often, you have a list of things you want to talk about.
[15:33:35]  ***  dom has joined chat #gtk-devel.
[15:33:37]  <carol> really "no"?
[15:33:52]  <mclasen> if you want to know whats in the mail, read it...
[15:34:20]  <carol> i think what i wanted was someone who was concentrating on the whole project to summarize it
[15:34:49]  <mclasen> gtk does printing now. people are still discussing the details.
[15:35:03]  <mclasen> one-line summary
[15:35:17]  <carol> which is what i asked for. thank you.
[15:35:34]  ***  ebassi|out is now known as ebassi.
[15:36:22]  <mclasen> kris: have you had a chance to look at the reported async filechooser crashes ?
[15:41:24]  <mclasen> elijah: are you around ?
[15:41:50]  ***  J5 has joined chat #gtk-devel.
[15:42:27]  <elijah> yup, I'm here
[15:42:45]  <mclasen> picking up the dnd-raise thing again ?
[15:42:51]  <elijah> yeah
[15:43:03]  <elijah> but, whittling it down to a manageabl 
----- Log file opened 1999-11-30T00:02 -----
[00:03:17]  ***  You are now participating in the #gtk-devel discussion. Checking for current participants...
[00:03:17]  ***  Users on #gtk-devel: @yosh bkor carol crazy___- deadchip diego ebassi elijah garnacho gmt grakic halfline ifoox_laptop ijuma ijuma_home J5 j_ali jpe jrydberg_ kris leio mclasen swany vektor
[00:03:17]  <J5> it just replaces the document with the preview
[00:03:25]  <J5> if you want to print the preview you go back up to the menu and select print
[00:04:24]  <J5> My idea is to attach the settings to the preview widget so applications can then send that into the dialog when they select print again.
[16:08:54]  <mclasen^ lots of open questions. I think the "dismiss the dialog" issue only comes up because gedit embeds the preview, right ?
[16:09:03]  <J5> another question remains.  If the app does not take control during blocking operations and we show a print button in the toolbar, do we pop up the dialog in its previous state if they hit print.
[16:09:08]  <J5> mclasen: yes
[16:12:42]  <mclasen^ it might be simpler to just ignore the "embedded preview" for now, and just do the evince thing...
[16:15:13]  <J5^ ok, is there any precedence of calling external helpers from gtk+?
[16:15:46]  <mclasen^ no, I don't think so
[16:16:27]  <J5^ I guess I'll make it up as I go.  I'm still going to make the API as if we had the embeddable widget.
[16:17:06]  <mclasen> ok
[16:17:51]  <mclasen> another printing thing we need to sort out is the async pagination/rendering
[16:18:37]  <J5^ Basically we need to print once to a temp file and have the external helper read it - but we still want to keep the print dialog up, correct?
[16:19:08]  ***  crazy___- has left chat #gtk-devel (leaving).
[16:19:15]  <J5> mclasen: paolo is writing code for the async and pagination stuff
[16:19:32]  <J5> at least he said he was
[16:20:35]  <mclasen> yes
[16:23:02]  <mclasen> ok, I hope we can make some progress on the async issue soon; once that is done, I'll do a 2.9.1
[16:24:27]  <mclasen> anything else we should discuss today ?
[16:25:08]  <elijah> when are you planning on api freeze?
[16:26:03]  * elijah wonders if he can finish 154260 and 341166 in time
[16:28:07]  <mclasen^ I don't think 2.9.1 will be hard frozen yet; although it would be good to get most of the small api things settled soon; printing will probably need some leeway to get the api solid
[16:32:21]  <elijah> I'd like to get some feedback on the patch in 154260 when you get some time (it's functional, but probably ugly), but that's probably something outside the scope of this meeting.
[16:34:00]  ***  garnacho is now known as garnachAFK.
[16:34:15]  <mclasen> elijah: I'll try it sometime
[16:34:41]  <mclasen> if nobody else has something to bring up, lets consider the meeting closed
[16:43:57]  ***  federico has joined chat #gtk-devel.
[16:45:02]  ***  jpe has left chat #gtk-devel.
[16:46:25]  ***  jdahlin has joined chat #gtk-devel.
[16:47:25]  <jdahlin> oh, I missed the meeting
[16:47:29]  <federico> me too!
[16:47:33]  <federico> was having lunch
[16:48:16]  <jdahlin> bummer
[16:48:25]  <jdahlin> it should be announced in #gtk+ before
[16:51:28]  <mclasen> I sent mail...
[16:51:44]  <mclasen> do you have stuff to discuss ?
[16:52:46]  <jdahlin> I wanted to mention the status of GtkBuilder
[16:53:22]  <jdahlin> I'll just send a mail to the mailing list tomorrow instead
[16:53:46]  ***  jean has joined chat #gtk-devel.
[16:54:42]  ***  gmt has left chat #gtk-devel (Leaving).
[16:55:29]  <mclasen> jdahlin: thanks
[16:55:32]  <jdahlin^ one of the thing which is left on my todo is the GtkAction::accelerator property
[16:56:08]  <jdahlin> which currently needs to be set on the action before it's attached to an action group
[16:56:22]  <jdahlin> eg, in g_object_new
[16:56:27]  <mclasen> accelerators vs. actions is bigger problem complex
[16:56:34]  <mclasen> there are multiple issues
[16:57:04]  <mclasen> e.g. the need to associate multiple accelerators with one action
[16:57:19]  <jdahlin> stock icons makes it quite fun too.
[16:57:22]  <mclasen> and the fact that you can't use actions for multiple toplevels
[16:57:24]  <jdahlin> s/icons/items/
[16:58:14]  <jdahlin> hmm, then it can't be a property.
[16:59:35]  <jdahlin> mclasen: do you know of a concrete use case of multiple accelerators per action?
[17:02:40]  <mclasen> I think the gnumeric guys brought that up
[17:03:04]  <mclasen> perhaps because they want to be compatible with excel keybindings, dunno
[17:03:35]  <jdahlin> it might be out of the scope for gtkbuilder
[17:09:11]  <J5> mclasen: I'm having problems with gtk+ in rawhide.  It is saying it can't link to pango
[17:09:32]  <J5> I'm compiling gtk+ from cvs
[17:09:33]  <mclasen^ it shouldn't say that
[17:09:34]  ***  ebassi is now known as ebassi|zzz.
[17:09:38]  <J5> :-)
[17:09:41]  <mclasen> if it keeps saying that, try updating pango...
[17:09:55]  <J5> I just did, this is why I am getting the errors
[17:09:58]  <mclasen> I added a pango 1.13 requirement
[17:10:22]  <mclasen> what does it complain about in detail ?
[17:10:59]  <J5> in configure - checking Pango flags... -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/cairo   -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0
[17:11:11]  <J5> configure: error:
[17:11:11]  <J5> *** Can't link to Pango. Pango is required to build
[17:11:11]  <J5> *** GTK+. For more information see http://www.pango.org
[17:12:24]  <mclasen^ is it picking up an older pango from your tree ?
[17:13:16]  <J5^ this is multilib but I don't remember ever compiling pango.  Cairo, yes, pango, no
[17:14:27]  <mclasen^ can you get at the gcc error message
[17:14:35]  <mclasen> ?
[17:15:04]  <J5> I can extract the test from the m4 files
[17:15:13]  <J5> give me a second
[17:18:11]  <federico> if GtkRecentMonitor absolutely needs to monitor the file, can we make it an implementation detail within gtk, and not put it in glib?
[17:18:36]  <mclasen> we do currently
[17:19:07]  <mclasen> the file monitor thing was an attempt to improve it and bring it out to the open
[17:19:58]  <mclasen> it currently does the usual lame stat-every-so-often thing
[17:22:52]  <mclasen> we can certainly make it less lame, but that does not help at all to avoid the 2-implementations problem
[17:23:10]  <mclasen> because we'll have 2 anyway, one in gnome-vfs and a private one in gtk
[17:26:08]  <leio> I'd like to use an exposed one in another library too.
[17:27:52]  ***  jean has left chat #gtk-devel (Leaving).
[17:28:18]  <federico> mclasen: I really don't want to have yet another monitoring API.  We have inotify, gnome-vfs, fam, glib's...
[17:28:38]  <mclasen> we don't have glibs
[17:28:46]  <federico> well, you know what I mean
[17:29:10]  <mclasen> you'd rather see people use inotify directly ? and have the ifdefs for the corresponding win32 apis in app code ?
[17:29:12]  <leio> in my case, I just can't afford and justify a gnome-vfs/fam dep
[17:35:17]  <federico> mclasen: I'd rather have them use gnome-vfs
[17:36:55]  <mclasen> I don't see gtk picking up a gnome-vfs dependency anytime soon
[17:37:36]  ***  ifoox_laptop has left chat #gtk-devel (Leaving).
[17:38:47]  <federico> so this brings us back to the beginning.
[17:39:08]  <J5> mclasen: ahha, I found the issue, my rpm of gtk+ that I build from a CVS snap is versioned later than the one in rawhide.  It is missing a symbol.
[17:42:39]  <leio> out of curiosity, what stops it happening?
[17:43:03]  <leio> People being against it for good reasons, or just lack of implementation on other platforms or similar?
[17:43:51]  <mclasen^ until recently, lack of implementation on other platforms, but also implementation quality
[17:44:24]  <mclasen> the threading inside gnome-vfs is not exactly easy to understand and have confidence in...
[17:44:58]  <mclasen> maybe that needs to be reevaluated at some point
[17:45:43]  <federico> plus it needs libbonobo
[17:45:47]  <mclasen> in any case, it is not a dependency that we can add lightly
[17:45:50]  <federico> which brings in a lot of crap
[17:46:35]  <mclasen> why on earth does gnome-vfs need bonobo ?
[17:47:15]  <leio> ok, thanks, someone should perhaps do something about this situation
[17:47:21]  * leio looks around, and sees only mirrors
[17:49:05]  ***  grakic has left chat #gtk-devel.
[17:50:39]  <federico> mclasen: it uses bonobo-activation to register/activate gnome-vfs-daemon
[17:51:11]  <federico> which handles certain backends like SMB, and does the volume-monitoring stuff
[17:51:45]  <mclasen> ah, right
[17:54:07]  * mclasen wonders why gnome-session can't start it