may 04 21:57:56 no problem may 04 22:02:35 as usual, the agenda is here: http://live.gnome.org/GTK%2B/Meetings may 04 22:02:55 I'll just copy it here for reference may 04 22:03:18 • xi2 branch status (garnacho) may 04 22:03:29 • GtkStyle sealing (garnacho) may 04 22:04:03 • GtkTextView->need_im_reset accessor (jjardon, pbor) may 04 22:04:22 • Session management API (jjardon) may 04 22:04:33 • Application class (ebassi, walters) may 04 22:05:00 • GtkContainer with Builder definitions (tristan) may 04 22:05:24 • GdkRegion → cairo_region_t (Company) may 04 22:05:50 • non-abstract orientable widgets in 2.22 may 04 22:06:02 • GController (ebassi) may 04 22:06:11 • Miscellaneous may 04 22:07:26 ok, am I first to talk then? may 04 22:08:50 about the xi2 branch, I've been recently getting on the wheel again, this morning I've been having a look at kris' patch for the quartz backend, so basic support should end up there soon. may 04 22:09:40 also would like to get basic support for the win32 backend as soon as I learn how to set up a build environment there may 04 22:11:11 there are some problems though in the way multitouch devices are possibly going to be handled in XInput2, so GtkDeviceGroup and multidevice events are a bit on the wire, but the rest of the branch is unaffected may 04 22:11:25 are modifications to stock widgets in scope for this? may 04 22:11:52 * mclasen here now may 04 22:12:06 * mclasen adds 2.90 merge and 2.90 release to the agenda may 04 22:12:21 walters, basic support has been added, but there are parts where its support could be more polished may 04 22:12:35 also, I guess new usecases will appear over time may 04 22:13:40 garnacho: would it make sense to merge without the multidevice parts until things clear up ? may 04 22:14:06 yes I think so may 04 22:14:43 cool may 04 22:15:06 I really hope that gets sorted out soon may 04 22:15:38 (for those not following xorg-deve, the change goes from having multiple subdevices for touches in multitouch, to having a single device with multiple axis sets) may 04 22:15:41 *devel may 04 22:17:44 anything else we need to discuss wrt xi2 ? may 04 22:18:17 garnacho: think it is realistic to have something mergable by the end of next week ? may 04 22:20:27 could be achievable, most critical things are merging kris' patch and doing basic work on win32, extending XEmbed and XDnD could be done on master, the current implementation have a working legacy implementation may 04 22:21:29 yeah, not too worried about those may 04 22:22:39 whats the next topic ? may 04 22:23:05 Also mine :) may 04 22:23:25 about GtkStyle sealing. Honestly, I've rather been working on deprecating it, I've recently pushed a experimental branch to http://github.com/garnacho/gtk/tree/gtk-style-context , I'm planning to do a shallow GtkStyle on top of this may 04 22:24:28 Currently it just features the arch proposed in http://live.gnome.org/CarlosGarnacho/ThemingProposal , CSS-like parser included, I'm looking into adding implicit animations may 04 22:25:13 Also need to add module loading so I can actually do something good looking :) may 04 22:25:35 but I also guess that sealing will be needed prior to this may 04 22:26:40 * mclasen has no opinion (due to not having payed attention so far...) may 04 22:26:55 btw, the css is something like this: http://pastebin.com/TLwYWu9Y , these features are currently supported may 04 22:27:04 garnacho, will be a clear path to apps to port to GTK+3 ? ie, onle a recompilation needed? may 04 22:28:40 jjardon, apps shouldn't have many problems, although most likely there won't be a clear way to add compat for gtk_rc_parse* may 04 22:29:07 engines need to readapt to new API, but I've done it not too differently on purpose may 04 22:29:52 Hi. may 04 22:30:45 and about widgets, at the moment I've got basic code that makes gtk_paint* use the new functions in there, but all color settings are taken from the pseudo-css parser may 04 22:31:24 compatibility on the rc parser level is going to be next to impossible, I guess may 04 22:32:35 yeah, at earlier stages got the idea of making GtkRcStyle implement the interface that provides style settings in that branch, that could be further investigated may 04 22:34:04 but I had to develop something that could explore all possibilities may 04 22:34:08 I said that because lots of apps are currently using direct access to GtkStyle elements may 04 22:34:45 yeah, I'm planning to have a GtkStyle with meaningful data may 04 22:36:14 but well, there are still some missing features there, so I'll be telling about any progress there may 04 22:38:02 garnacho, so, common contructions like style->base[GTK_STATE_NORMAL] or style->text[GTK_STATE_NORMAL] will be a proper accessor or a new API should be used? may 04 22:38:44 * danw_ es ahora conocido como danw may 04 22:39:09 new api should be used, there is already a replacement for these may 04 22:42:28 next topic? may 04 22:45:21 "Discuss possible solutions for GtkTextView->need_im_reset accessor" I think pbor has a solution may 04 22:45:39 well may 04 22:47:02 https://bugzilla.gnome.org/show_bug.cgi?id=163251 may 04 22:47:07 this is the releavant bug may 04 22:47:35 at the end of the day I simply propose to take the easy way out and expose a method to do what we did before may 04 22:48:47 however there is also another case where we need to access im_context may 04 22:49:09 which is when overriding delete_from_cursor may 04 22:49:13 The use case for empathy: https://bugzilla.gnome.org/show_bug.cgi?id=592405#c13 may 04 22:49:45 a possible solution there is to add a value to GtkDeleteType in order to chain up may 04 22:50:22 so that I let the textview handler reset the context without doing the deletion and then do the deletion myself may 04 22:50:24 * mclasen missed some 15 minutes of discussion may 04 22:50:30 though it is a bit of a hack may 04 22:50:46 mclasen: not much of a discussion so far :) may 04 22:51:02 mclasen: http://fpaste.org/cH45/ may 04 22:53:32 so at the end of the day what I propose is: 1) gtk_text_view_im_context_filter_keypress() 2) either gtk_text_view_reset_im_context or add a specail "none" value to GtkDeleteType may 04 22:54:40 * ebassi_ is having connectivity issues may 04 22:55:54 ebassi_, http://pastebin.com/bMJM0d2R may 04 22:56:59 thanks may 04 22:57:12 basically the problem is the im_context would be a "protected" member, but we lack that :) may 04 22:57:54 * ebassi se ha marchado (Ping timeout: 600 seconds) may 04 22:58:12 mclasen, said here that im context is not part of the public api anyway: https://bugzilla.gnome.org/show_bug.cgi?id=163251#c3 may 04 22:59:32 jjardon: exactly, it is not part of the public api, but subclasses need to access it to properly implement some of the vmethods may 04 23:00:26 in particular key-press-event needs to see if im_context filters the keypress and delete-from-cursor needs to reset it may 04 23:00:35 not sure if there are other cases may 04 23:01:21 I propose to add those two methods and document that they are supposed to be used when overriding methods may 04 23:01:55 sounds good may 04 23:02:23 but it seems we'll never reach a conclusion since even comcast hates that bug :) may 04 23:02:41 * mclasen_ is back again - will have to rely on meeting logs to learn about what was discussed... may 04 23:03:18 mclasen_, http://pastebin.com/YtezbUw2 may 04 23:04:06 ok, I commented in the bug may 04 23:04:34 mclasen_, the entire log: http://pastebin.com/527QVumy may 04 23:05:11 mclasen_: thanks may 04 23:05:41 * pbor wonders if jjardon would be so nice to make the patch :) may 04 23:05:51 * mclasen_ would love to get to the orientable and 2.90 topics - anything else before that ? may 04 23:06:30 mclasen_, http://live.gnome.org/action/login/GTK+/Meetings may 04 23:06:51 But I' have no problems in change the items order may 04 23:07:01 lets just keep moving, then may 04 23:07:02 neither do I may 04 23:07:14 in case, we can punt the items for the next meeting may 04 23:07:18 session mgmt ? anything to say about that ? may 04 23:07:42 please, read this before: https://bugzilla.gnome.org/show_bug.cgi?id=79285#c30 may 04 23:08:11 the bug is in the same condition as before may 04 23:08:11 Should the bug closed as invalid or is a valid request? may 04 23:09:07 its not invalid may 04 23:09:34 but havoc is right that all we want nowadays is autostart, session-end-notification and window state saving may 04 23:10:12 I said that because lots of apps are blindly moving from gnome-client to EggSMClient may 04 23:10:15 note that session end overlaps somewhat with the "quit" method on GtkApplication may 04 23:10:33 (actually, entirely overlaps) may 04 23:10:35 only to get rid og libgnome dependencies may 04 23:10:39 jjardon: yeah, thats just blind porting may 04 23:10:58 walters: certainly, the session stuff we want should fall in place after GtkApplication, I think may 04 23:11:30 yep may 04 23:11:45 so, I'd say lets move right onto that topic may 04 23:11:53 maybe we should close the bug and points to the GApplication bug may 04 23:12:20 jjardon: no, I'd leave it open may 04 23:12:21 aright, so...i did some work on both GApplication and GtkApplication over the last few weeks, but haven't been able to come anywhere close to 100% of time on it may 04 23:12:37 for reference, GApplication lives at http://people.gnome.org/~walters/gapplication-standalone.git/ may 04 23:13:05 ebassi_, Maybe make it depends on GApplication ? may 04 23:13:13 and new patches are in http://bugzilla.gnome.org/show_bug.cgi?id=127958 may 04 23:13:21 walters: I've been looking at the repository; I have some fixes for it - I'm going to push them somewhere on github may 04 23:13:33 the biggest picture issue is that we need to require a unique identifier string for apps may 04 23:13:56 my suggestion is that this takes the form of a DBus name (and we recommend apps also name their .desktop files like that, so org.mozilla.Firefox.desktop) may 04 23:14:16 GSettings uses a similar scheme as I understand may 04 23:14:32 yeah, schema names look similar to bus names may 04 23:14:36 there are some smaller picture things like hadess wants legacy unix scripting support (via option processing) etc. may 04 23:14:47 walters: renaming all desktop files is going to be a pretty big GnomeGoal may 04 23:14:55 we can't rename extant ones may 04 23:15:00 we'll need to add a field to the .desktop file may 04 23:15:02 did you and owen reach an agreement on the usefulness of the gapp/gtkapp split ? may 04 23:15:03 but for new apps may 04 23:15:08 we should recommend this may 04 23:15:13 walters: right may 04 23:15:43 one thing to consider is that we are already using the desktop file basename as unique id in places may 04 23:15:46 eg in gnome-session may 04 23:16:49 so...what else. oh, yeah; standardization of the dbus interface will need to go through xdg-list i guess may 04 23:17:01 which i should probably start so it finishes this cycle may 04 23:17:42 what dbus interface is there ? may 04 23:17:42 walters: I'm not so sure we should be dragged into a discussion with kde people at this point may 04 23:17:58 mclasen_: currently, a way to ask an app to quit, and an app can expose GtkActions may 04 23:17:59 walters: if we want to get xfce on board we can always contact them may 04 23:18:15 i'm with ebassi_. nothing good ever comes of trying to coordinate with kde any more may 04 23:18:37 * ebassi_ es ahora conocido como ebassi may 04 23:18:51 and maybe lxde may 04 23:18:53 hmm, well i don't need to block on them, but it seems as good a place as any to be like "hey the way we write apps now has these flaws, here's a fix for that" may 04 23:19:32 * ebassi_ (~ebassi@li19-69.members.linode.com) ha entrado en #gtk-devel may 04 23:19:52 oh, and gapplication blocks on gdbus going in may 04 23:20:37 that should be happening real soon now may 04 23:20:37 any news about gdbus status? may 04 23:20:46 one other thought i had here is that we should consider including a skeleton application generator in GTK+ itself may 04 23:20:47 davidz is finishing up loose ends may 04 23:20:51 walters: jesse pushed a dbus branch of gedit http://git.gnome.org/browse/gedit/log/?h=dbus that uses gdbus for single instance any chance you could check if gapplication would fit all the requirements? may 04 23:21:23 jjardon: I'm working on it... mostly loose ends etc. may 04 23:21:25 application generator is really a huge topic in itself, but i raise it since i think we need to keep it in mind may 04 23:21:34 turned out there was more loose ends than I anticipated... may 04 23:21:50 besides that, minor things - need a lot more docs and polish may 04 23:22:17 walters: in particular the --wait thingie (which is the second instace waits instead of closing right away: think of export EDITOR=gedit for vcs commits may 04 23:22:19 but i'm really hoping to at least get pieces together this week to patch apps and make the Quit button in GNOME Shell actually sane may 04 23:22:58 * mclasen_ watches thunderstorm move in quickly may 04 23:23:09 pbor: i can't ctx switch quite now to look, but the answer is likely to be that you can actually use GtkApplication without affecting anything you're doing now for the most part may 04 23:23:27 if you have a lot of manual option processing it won't be a good fit - yet may 04 23:23:48 walters: I didn't mean check the code, more like catch jesse on irc and chat a little :) may 04 23:23:48 davidz, the convenience api looks really good, BTW may 04 23:24:54 for the curious: http://people.freedesktop.org/~david/gdbus-20100429/convenience.html may 04 23:25:56 walters: so, basically, we're waiting for gdbus to land, then move ahead with gtkapplication ? do you think what you have now is solid enough to get merged soon, or should this be on the burner a bit longer ? may 04 23:26:23 mclasen_: mmm...define soon. weeks? may 04 23:26:27 we also need to consider the time we have to get most of gnome to support at least the quit action may 04 23:26:29 yeah, weeks may 04 23:26:41 i think it's doable yes may 04 23:26:41 my hope is that gdbus can get merged some time next week may 04 23:27:14 excellent may 04 23:27:43 Nice! may 04 23:27:49 * davidz was shooting for early this week actually may 04 23:28:04 but right now late this week looks like a good timeframe... may 04 23:29:20 okay, next topic? may 04 23:29:42 or are there other issues with GtkApplication? may 04 23:30:47 i'll post an update by the end of this week may 04 23:30:49 to gtk-devel may 04 23:33:35 right may 04 23:34:11 I guess tristan_ can talk about the composite containers topic, or Company about the GdkRegion deprecation may 04 23:34:33 i'm here silently waiting for my turn may 04 23:34:55 i guess i'll just start: may 04 23:35:17 http://bugzilla.gnome.org/show_bug.cgi?id=613284 has a replacement of GdkRegion with cairo_region_t may 04 23:35:33 it's completely ABI stable, but has some API issues: may 04 23:35:50 1) it #include's cairo.h unconditionally may 04 23:36:33 2) it changes the GdkRegion and GdkRectangle typedefs, and some (c++) projects predefine those (like webkit) may 04 23:37:01 so i'm wondering how to best handle deprecation in a compatible way may 04 23:38:08 i would just deprecate the functions in 2.x and remove GdkRegion in gtk 3 may 04 23:38:24 and typedef GdkRectangle to the cairo equivalent may 04 23:39:17 but wanted to know if that's ok with everyone may 04 23:41:19 * tristan_ back, had important visit... may 04 23:41:26 Company, fine with me. You should apply your patch in master and then cherry pick in gtk-2-22 may 04 23:41:47 for the deprecateion stuff may 04 23:41:59 Company: deprecation + switch sounds fine to me as well may 04 23:42:14 cool may 04 23:42:20 i'll have a go at that then may 04 23:42:32 Company: is cairo_region_t including all the fixes of the X11 region that have been accumulated over the years? may 04 23:42:41 ebassi: yes may 04 23:42:47 cool may 04 23:42:59 having a single copy will help may 04 23:43:01 ebassi: cairo_region_t exposes pixman_region_t which is the region implementation used in X may 04 23:43:30 right may 04 23:43:38 * mclasen was out for a while again may 04 23:43:40 can you point me to the bug/patch ? may 04 23:43:53 http://bugzilla.gnome.org/show_bug.cgi?id=613284 may 04 23:44:10 mclasen: http://fpaste.org/c9Kn/ - you didn't miss a lot may 04 23:44:20 mclasen: after this, do you want to talk about gtk 2.90 in case you get another outage? may 04 23:44:26 sure may 04 23:44:49 hrm, i guess there's an issue with apis that return GdkRegions, but i'll figure that out may 04 23:46:10 Company: for the record, getting rid of an extra copy of miregion can only be good may 04 23:46:26 yeah may 04 23:46:42 the only question is how to do it as compatible as possible may 04 23:46:53 so, if we can make this work largely compatibly, we should do it may 04 23:47:28 so, 2.90 next ? may 04 23:48:08 the plan was to merge 2.90 to master as soon as a) we have stable branches and b) 2.90 works may 04 23:48:18 we have a) now, and we got pretty close on b), I think may 04 23:48:36 only testtext seemed to fail to build last time I tried may 04 23:49:09 so I'd like to propose that we merge the 2.90 branch asap, before I roll the first 2.90 release may 04 23:49:33 sounds like a plan to me may 04 23:49:36 we can disable testtext for the time being, or maybe somebody gets inspired to port it of GtkItemFactory may 04 23:50:18 +1 from me, we can rebase the branch again if you plan to merge rigth now may 04 23:50:20 as for timing I'd like to get out a devel release with the extended layout stuff soon, like end of this week may 04 23:50:51 so we get some more certainty on regessions may 04 23:51:32 Sorry I haven't been paying enough attention, but is there a 2.22 and will extended-layout go into it? Or is that a straight-to-2.90/3.0 feature? may 04 23:51:43 bratsche: there is a 2.22 branch may 04 23:51:44 bratsche: 2.90 may 04 23:51:53 but it only takes missing accessors may 04 23:52:00 Cool, thanks. may 04 23:52:03 not new features like extended layout, xi2 or csd may 04 23:52:21 Okay cool.. seb128 was asking me to find this out tonight, so mission accomplished. ;) may 04 23:52:27 to make the branching picture more confusing, there's also a regular stable 2.20 branch may 04 23:52:40 but I don't think I'm going to do much more there, after the .1 releases last weekend may 04 23:53:08 getting close to the 2 hour mark may 04 23:53:17 should we very briefly touch orientable ? may 04 23:53:30 mclasen: what's missing in those? may 04 23:53:32 * mclasen is all for getting beyond the impasse, and making things flippable may 04 23:54:00 yeah, me too may 04 23:54:06 ebassi: timj was against making them nonabstract because we had a disagreement on default property values may 04 23:54:23 but nothing ever came out of the default change discussion may 04 23:54:24 which would be solved by changing the default values may 04 23:54:28 so, we shoul dprobably move on may 04 23:54:36 or you were disagreeing on the values themselves? may 04 23:54:45 mclasen, Do you want to merge the gtk-2-90 branch now? I can rebase the gtk-2-90 branch again if you want may 04 23:54:56 ebassi: I don't think there ever was an exhaustive list of proposed changes may 04 23:55:01 afk, brb. may 04 23:55:03 the one that tim felt strongly about was visible may 04 23:55:19 and I'd feel at least a little uneasy about changing that for some widgets, but not all may 04 23:55:28 visible → TRUE by default? may 04 23:56:21 my honest opinion is that people should use interface builders and they should take care of setting sensible initial values for all properties may 04 23:56:33 of course, that gets harder if we change the defaults between versions.... may 04 23:58:25 g_param_spec_boolean_set_default() wouldnt hurt either may 04 23:58:31 okay, so the result is that we're still blocked; it might be good to get the ball rolling on the mailing list again may 04 23:58:33 (and all types...) may 04 23:58:36 are people in favor of changing defaults ? may 04 23:58:49 mclasen: I need to review the list on the wiki may 04 23:59:16 some of them I remember making sense to be changed may 04 23:59:19 I mostly want flippable widgets; if the cost of that is making all widgets visible by default, so be it may 04 23:59:36 but I don't think it makes sense to change the default only for some, formerly abstract types may 05 00:00:14 if for instance, Glade could pull the default values for any given version by keeping a store of girs, then default changing across all versions could hypothetically be transparent (but probably still error prone in some ways) may 05 00:00:35 tristan_: you need to know the default at runtime, no ? may 05 00:00:49 I mean, the .ui file you write out could be used by gtk 2.20, 3.0, ... may 05 00:01:34 hmmm, files that were created post 3.0 will "know the new default" may 05 00:01:51 * bratsche returns may 05 00:02:34 mclasen, Glade resorts to a runtime value at widget creation time may 05 00:02:43 tristan_: I think you need a version marker in your ui file, and have gtkbuilder know what defaults apply to what version may 05 00:03:27 hrm, and have GtkBuilder introspect that for us ? may 05 00:04:14 in our runtime we'll need to know defaults for versions that are not the "current" one may 05 00:04:36 currently really Glade tries to assume they are constant may 05 00:04:46 (i.e. defaults across versions) may 05 00:04:52 tristan_: you either make glade write out all properties explicitly, making defaults irrelevant at runtime may 05 00:05:04 and when they differ we handle them with some brute force if we can may 05 00:05:08 or you have a version marker in the .ui, so gtkbuilder can infer what defaults glade 'implied' may 05 00:05:28 hmmm, well we do have the version marker may 05 00:06:07 but it doesnt give us an introspectable store to check what default for what version ;-) may 05 00:06:20 that's something that might have to be hand-written I guess may 05 00:06:27 or maybe you want to let the app writer say 'write a .ui file that works with gtk versions x y z" may 05 00:06:43 and then glade can be smart about which defaults it can rely on and which changed in those versions may 05 00:07:13 that needs no changes in gtkbuilder may 05 00:07:30 that might be overboard, I think it would be nice if a GtkBuilder dependency can be >= target version may 05 00:07:40 and an exception for 3.0 probably may 05 00:08:08 i think it is really only about 'assume 3.0' vs '2.x compat' may 05 00:09:44 I have to give some thought to what the effects exactly are going to be and the measures needed may 05 00:10:05 I didnt expect the horizontal thing so I might be missing stuff may 05 00:10:18 should we punt GController and GtkContainer+GtkBuilder to the next meeting? may 05 00:10:25 but surely implementing a handmade cache of default value histories will help may 05 00:10:33 ebassi: I think so, getting late may 05 00:10:35 we passed the 2 hours mark already :-) may 05 00:10:45 so, in summary may 05 00:11:04 actions for this week: we merge 2.90, get a 2.90 release out, merge gdbus may 05 00:11:12 should keep us busy :-) may 05 00:12:01 heh may 05 00:12:19 for GController I think I'll have to send an email to the mailing list anyway may 05 00:12:38 that would be great may 05 00:13:10 a 2.90 release! nice :) may 05 00:14:05 okay, let's meet up again in one week - unless there are some issues may 05 00:14:11 Also, I'd like to announce that I'm going to start moving all the GSEAL data to priv structures as my GSoC project. may 05 00:14:20 Thanks to garnacho to be my mentor ;) may 05 00:14:26 jjardon: awesome! may 05 00:14:34 :) may 05 00:14:35 Nice. may 05 00:15:27 2010 will be the GTK+3 year ;) may 05 00:15:28 have a nice evening/a good night everyone may 05 00:15:48 I'll send the minutes to the mailing list; somebody else will have to push the log to the wiki, if possible may 05 00:16:11 in closing, 2.90 is an ok version number to choose, right ? may 05 00:16:17 ebassi, I'll do that may 05 00:16:21 or do we expect to do more than 10 snapshots before 3? may 05 00:17:34 mclasen, we always can use 2.999 may 05 00:17:41 heh may 05 00:17:58 but no - I don't think we'll need more than 10 snapshots may 05 00:18:24 I hope not either may 05 00:18:26 2.99.05.3 may 05 00:18:30 lets not go there may 05 00:19:03 I'll just do a 2.90, and we'll be disciplined about turning it into 3.0 without major detours... may 05 00:19:45 Other releases: 2.17.11 and 2.19.7 may 05 00:20:08 10 should be enough