1 may 04 21:57:56 <ebassi>	no problem
   2 may 04 22:02:35 <ebassi>	as usual, the agenda is here: http://live.gnome.org/GTK%2B/Meetings
   3 may 04 22:02:55 <ebassi>	I'll just copy it here for reference
   4 may 04 22:03:18 <ebassi>	• xi2 branch status (garnacho)
   5 may 04 22:03:29 <ebassi>	• GtkStyle sealing (garnacho)
   6 may 04 22:04:03 <ebassi>	• GtkTextView->need_im_reset accessor (jjardon, pbor)
   7 may 04 22:04:22 <ebassi>	• Session management API (jjardon)
   8 may 04 22:04:33 <ebassi>	• Application class (ebassi, walters)
   9 may 04 22:05:00 <ebassi>	• GtkContainer with Builder definitions (tristan)
  10 may 04 22:05:24 <ebassi>	• GdkRegion → cairo_region_t (Company)
  11 may 04 22:05:50 <ebassi>	• non-abstract orientable widgets in 2.22
  12 may 04 22:06:02 <ebassi>	• GController (ebassi)
  13 may 04 22:06:11 <ebassi>	• Miscellaneous
  14 may 04 22:07:26 <garnacho>	ok, am I first to talk then?
  15 may 04 22:08:50 <garnacho>	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.
  16 may 04 22:09:40 <garnacho>	also would like to get basic support for the win32 backend as soon as I learn how to set up a build environment there
  17 may 04 22:11:11 <garnacho>	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
  18 may 04 22:11:25 <walters>	are modifications to stock widgets in scope for this?
  19 may 04 22:11:52 *	mclasen here now
  20 may 04 22:12:06 *	mclasen adds 2.90 merge and 2.90 release to the agenda
  21 may 04 22:12:21 <garnacho>	walters, basic support has been added, but there are parts where its support could be more polished
  22 may 04 22:12:35 <garnacho>	also, I guess new usecases will appear over time
  23 may 04 22:13:40 <mclasen>	garnacho: would it make sense to merge without the multidevice parts until things clear up ?
  24 may 04 22:14:06 <garnacho>	yes I think so
  25 may 04 22:14:43 <mclasen>	cool
  26 may 04 22:15:06 <garnacho>	I really hope that gets sorted out soon
  27 may 04 22:15:38 <garnacho>	(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)
  28 may 04 22:15:41 <garnacho>	*devel
  29 may 04 22:17:44 <mclasen>	anything else we need to discuss wrt xi2 ?
  30 may 04 22:18:17 <mclasen>	garnacho: think it is realistic to have something mergable by the end of next week ?
  31 may 04 22:20:27 <garnacho>	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
  32 may 04 22:21:29 <mclasen>	yeah, not too worried about those
  33 may 04 22:22:39 <mclasen>	whats the next topic ?
  34 may 04 22:23:05 <garnacho>	Also mine :)
  35 may 04 22:23:25 <garnacho>	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
  36 may 04 22:24:28 <garnacho>	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
  37 may 04 22:25:13 <garnacho>	Also need to add module loading so I can actually do something good looking :)
  38 may 04 22:25:35 <garnacho>	but I also guess that sealing will be needed prior to this
  39 may 04 22:26:40 *	mclasen has no opinion (due to not having payed attention so far...)
  40 may 04 22:26:55 <garnacho>	btw, the css is something like this: http://pastebin.com/TLwYWu9Y , these features are currently supported
  41 may 04 22:27:04 <jjardon>	garnacho, will be a clear path to apps to port to GTK+3 ? ie, onle a recompilation needed?
  42 may 04 22:28:40 <garnacho>	jjardon, apps shouldn't have many problems, although most likely there won't be a clear way to add compat for gtk_rc_parse*
  43 may 04 22:29:07 <garnacho>	engines need to readapt to new API, but I've done it not too differently on purpose
  44 may 04 22:29:52 <bratsche>	Hi.
  45 may 04 22:30:45 <garnacho>	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
  46 may 04 22:31:24 <mclasen>	compatibility on the rc parser level is going to be next to impossible, I guess
  47 may 04 22:32:35 <garnacho>	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
  48 may 04 22:34:04 <garnacho>	but I had to develop something that could explore all possibilities
  49 may 04 22:34:08 <jjardon>	I said that because lots of apps are currently using direct access to GtkStyle elements
  50 may 04 22:34:45 <garnacho>	yeah, I'm planning to have a GtkStyle with meaningful data
  51 may 04 22:36:14 <garnacho>	but well, there are still some missing features there, so I'll be telling about any progress there
  52 may 04 22:38:02 <jjardon>	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?
  53 may 04 22:38:44 *	danw_ es ahora conocido como danw
  54 may 04 22:39:09 <garnacho>	new api should be used, there is already a replacement for these
  55 may 04 22:42:28 <Company>	next topic?
  56 may 04 22:45:21 <jjardon>	"Discuss possible solutions for GtkTextView->need_im_reset accessor" I think pbor has a solution
  57 may 04 22:45:39 <pbor>	well
  58 may 04 22:47:02 <pbor>	https://bugzilla.gnome.org/show_bug.cgi?id=163251
  59 may 04 22:47:07 <pbor>	this is the releavant bug
  60 may 04 22:47:35 <pbor>	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
  61 may 04 22:48:47 <pbor>	however there is also another case where we need to access im_context
  62 may 04 22:49:09 <pbor>	which is when overriding delete_from_cursor
  63 may 04 22:49:13 <jjardon>	The use case for empathy: https://bugzilla.gnome.org/show_bug.cgi?id=592405#c13
  64 may 04 22:49:45 <pbor>	a possible solution there is to add a value to GtkDeleteType in order to chain up
  65 may 04 22:50:22 <pbor>	so that I let the textview handler reset the context without doing the deletion and then do the deletion myself
  66 may 04 22:50:24 *	mclasen missed some 15 minutes of discussion
  67 may 04 22:50:30 <pbor>	though it is a bit of a hack
  68 may 04 22:50:46 <pbor>	mclasen: not much of a discussion so far :)
  69 may 04 22:51:02 <walters>	mclasen: http://fpaste.org/cH45/
  70 may 04 22:53:32 <pbor>	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
  71 may 04 22:54:40 *	ebassi_ is having connectivity issues
  72 may 04 22:55:54 <jjardon>	ebassi_, http://pastebin.com/bMJM0d2R
  73 may 04 22:56:59 <ebassi_>	thanks
  74 may 04 22:57:12 <pbor>	basically the problem is the im_context would be a "protected" member, but we lack that :)
  75 may 04 22:57:54 *	ebassi se ha marchado (Ping timeout: 600 seconds)
  76 may 04 22:58:12 <jjardon>	mclasen, said here that im context is not part of the public api anyway: https://bugzilla.gnome.org/show_bug.cgi?id=163251#c3
  77 may 04 22:59:32 <pbor>	jjardon: exactly, it is not part of the public api, but subclasses need to access it to properly implement some of the vmethods
  78 may 04 23:00:26 <pbor>	in particular key-press-event needs to see if im_context filters the keypress and delete-from-cursor needs to reset it
  79 may 04 23:00:35 <pbor>	not sure if there are other cases
  80 may 04 23:01:21 <pbor>	I propose to add those two methods and document that they are supposed to be used when overriding methods
  81 may 04 23:01:55 <jjardon>	sounds good
  82 may 04 23:02:23 <pbor>	but it seems we'll never reach a conclusion since even comcast hates that bug :)
  83 may 04 23:02:41 *	mclasen_ is back again - will have to rely on meeting logs to learn about what was discussed...
  84 may 04 23:03:18 <jjardon>	mclasen_, http://pastebin.com/YtezbUw2
  85 may 04 23:04:06 <mclasen_>	ok, I commented in the bug
  86 may 04 23:04:34 <jjardon>	mclasen_, the entire log: http://pastebin.com/527QVumy
  87 may 04 23:05:11 <pbor>	mclasen_: thanks
  88 may 04 23:05:41 *	pbor wonders if jjardon would be so nice to make the patch :)
  89 may 04 23:05:51 *	mclasen_ would love to get to the orientable and 2.90 topics - anything else before that ?
  90 may 04 23:06:30 <jjardon>	mclasen_, http://live.gnome.org/action/login/GTK+/Meetings
  91 may 04 23:06:51 <jjardon>	But I' have no problems in change the items order
  92 may 04 23:07:01 <mclasen_>	lets just keep moving, then
  93 may 04 23:07:02 <ebassi_>	neither do I
  94 may 04 23:07:14 <ebassi_>	in case, we can punt the items for the next meeting
  95 may 04 23:07:18 <mclasen_>	session mgmt ? anything to say about that ?
  96 may 04 23:07:42 <jjardon>	please, read this before: https://bugzilla.gnome.org/show_bug.cgi?id=79285#c30
  97 may 04 23:08:11 <ebassi_>	the bug is in the same condition as before
  98 may 04 23:08:11 <jjardon>	Should the bug closed as invalid or is a valid request?
  99 may 04 23:09:07 <mclasen_>	its not invalid
 100 may 04 23:09:34 <mclasen_>	but havoc is right that all we want nowadays is autostart, session-end-notification and window state saving
 101 may 04 23:10:12 <jjardon>	I said that because lots of apps are blindly moving from gnome-client to EggSMClient
 102 may 04 23:10:15 <walters>	note that session end overlaps somewhat with the "quit" method on GtkApplication
 103 may 04 23:10:33 <walters>	(actually, entirely overlaps)
 104 may 04 23:10:35 <jjardon>	only to get rid og libgnome dependencies
 105 may 04 23:10:39 <mclasen_>	jjardon: yeah, thats just blind porting
 106 may 04 23:10:58 <mclasen_>	walters: certainly, the session stuff we want should fall in place after GtkApplication, I think
 107 may 04 23:11:30 <ebassi_>	yep
 108 may 04 23:11:45 <mclasen_>	so, I'd say lets move right onto that topic
 109 may 04 23:11:53 <jjardon>	maybe we should close the bug and points to the GApplication bug
 110 may 04 23:12:20 <ebassi_>	jjardon: no, I'd leave it open
 111 may 04 23:12:21 <walters>	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
 112 may 04 23:12:37 <walters>	for reference, GApplication lives at http://people.gnome.org/~walters/gapplication-standalone.git/
 113 may 04 23:13:05 <jjardon>	ebassi_, Maybe make it depends on GApplication ?
 114 may 04 23:13:13 <walters>	and new patches are in http://bugzilla.gnome.org/show_bug.cgi?id=127958
 115 may 04 23:13:21 <ebassi_>	walters: I've been looking at the repository; I have some fixes for it - I'm going to push them somewhere on github
 116 may 04 23:13:33 <walters>	the biggest picture issue is that we need to require a unique identifier string for apps
 117 may 04 23:13:56 <walters>	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)
 118 may 04 23:14:16 <walters>	GSettings uses a similar scheme as I understand
 119 may 04 23:14:32 <mclasen_>	yeah, schema names look similar to bus names
 120 may 04 23:14:36 <walters>	there are some smaller picture things like hadess wants legacy unix scripting support (via option processing) etc.
 121 may 04 23:14:47 <ebassi_>	walters: renaming all desktop files is going to be a pretty big GnomeGoal
 122 may 04 23:14:55 <walters>	we can't rename extant ones
 123 may 04 23:15:00 <walters>	we'll need to add a field to the .desktop file
 124 may 04 23:15:02 <mclasen_>	did you and owen reach an agreement on the usefulness of the gapp/gtkapp split ?
 125 may 04 23:15:03 <walters>	but for new apps
 126 may 04 23:15:08 <walters>	we should recommend this
 127 may 04 23:15:13 <ebassi_>	walters: right
 128 may 04 23:15:43 <mclasen_>	one thing to consider is that we are already using the desktop file basename as unique id in places
 129 may 04 23:15:46 <mclasen_>	eg in gnome-session
 130 may 04 23:16:49 <walters>	so...what else.  oh, yeah; standardization of the dbus interface will need to go through xdg-list i guess
 131 may 04 23:17:01 <walters>	which i should probably start so it finishes this cycle
 132 may 04 23:17:42 <mclasen_>	what dbus interface is there ?
 133 may 04 23:17:42 <ebassi_>	walters: I'm not so sure we should be dragged into a discussion with kde people at this point
 134 may 04 23:17:58 <walters>	mclasen_: currently, a way to ask an app to quit, and an app can expose GtkActions
 135 may 04 23:17:59 <ebassi_>	walters: if we want to get xfce on board we can always contact them
 136 may 04 23:18:15 <danw>	i'm with ebassi_. nothing good ever comes of trying to coordinate with kde any more
 137 may 04 23:18:37 *	ebassi_ es ahora conocido como ebassi
 138 may 04 23:18:51 <jjardon>	and maybe lxde
 139 may 04 23:18:53 <walters>	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"
 140 may 04 23:19:32 *	ebassi_ (~ebassi@li19-69.members.linode.com) ha entrado en #gtk-devel
 141 may 04 23:19:52 <walters>	oh, and gapplication blocks on gdbus going in
 142 may 04 23:20:37 <mclasen_>	that should be happening real soon now
 143 may 04 23:20:37 <jjardon>	any news about gdbus status?
 144 may 04 23:20:46 <walters>	one other thought i had here is that we should consider including a skeleton application generator in GTK+ itself
 145 may 04 23:20:47 <mclasen_>	davidz is finishing up loose ends
 146 may 04 23:20:51 <pbor>	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?
 147 may 04 23:21:23 <davidz>	jjardon: I'm working on it... mostly loose ends etc.
 148 may 04 23:21:25 <walters>	application generator is really a huge topic in itself, but i raise it since i think we need to keep it in mind
 149 may 04 23:21:34 <davidz>	turned out there was more loose ends than I anticipated...
 150 may 04 23:21:50 <walters>	besides that, minor things - need a lot more docs and polish
 151 may 04 23:22:17 <pbor>	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
 152 may 04 23:22:19 <walters>	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
 153 may 04 23:22:58 *	mclasen_ watches thunderstorm move in quickly
 154 may 04 23:23:09 <walters>	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
 155 may 04 23:23:27 <walters>	if you have a lot of manual option processing it won't be a good fit - yet
 156 may 04 23:23:48 <pbor>	walters: I didn't mean check the code, more like catch jesse on irc and chat a little :)
 157 may 04 23:23:48 <jjardon>	davidz, the convenience api looks really good, BTW
 158 may 04 23:24:54 <jjardon>	for the curious: http://people.freedesktop.org/~david/gdbus-20100429/convenience.html
 159 may 04 23:25:56 <mclasen_>	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 ?
 160 may 04 23:26:23 <walters>	mclasen_: mmm...define soon.  weeks?
 161 may 04 23:26:27 <mclasen_>	we also need to consider the time we have to get most of gnome to support at least the quit action
 162 may 04 23:26:29 <mclasen_>	yeah, weeks
 163 may 04 23:26:41 <walters>	i think it's doable yes
 164 may 04 23:26:41 <mclasen_>	my hope is that gdbus can get merged some time next week
 165 may 04 23:27:14 <walters>	excellent
 166 may 04 23:27:43 <bratsche>	Nice!
 167 may 04 23:27:49 *	davidz was shooting for early this week actually
 168 may 04 23:28:04 <davidz>	but right now late this week looks like a good timeframe...
 169 may 04 23:29:20 <ebassi>	okay, next topic?
 170 may 04 23:29:42 <ebassi>	or are there other issues with GtkApplication?
 171 may 04 23:30:47 <walters>	i'll post an update by the end of this week
 172 may 04 23:30:49 <walters>	to gtk-devel
 173 may 04 23:33:35 <ebassi>	right
 174 may 04 23:34:11 <ebassi>	I guess tristan_ can talk about the composite containers topic, or Company about the GdkRegion deprecation
 175 may 04 23:34:33 <Company>	i'm here silently waiting for my turn
 176 may 04 23:34:55 <Company>	i guess i'll just start:
 177 may 04 23:35:17 <Company>	http://bugzilla.gnome.org/show_bug.cgi?id=613284 has a replacement of GdkRegion with cairo_region_t
 178 may 04 23:35:33 <Company>	it's completely ABI stable, but has some API issues:
 179 may 04 23:35:50 <Company>	1) it #include's cairo.h unconditionally
 180 may 04 23:36:33 <Company>	2) it changes the GdkRegion and GdkRectangle typedefs, and some (c++) projects predefine those (like webkit)
 181 may 04 23:37:01 <Company>	so i'm wondering how to best handle deprecation in a compatible way
 182 may 04 23:38:08 <Company>	i would just deprecate the functions in 2.x and remove GdkRegion in gtk 3
 183 may 04 23:38:24 <Company>	and typedef GdkRectangle to the cairo equivalent
 184 may 04 23:39:17 <Company>	but wanted to know if that's ok with everyone
 185 may 04 23:41:19 *	tristan_ back, had important visit... 
 186 may 04 23:41:26 <jjardon>	Company, fine with me. You should apply your patch in master and then cherry pick in gtk-2-22
 187 may 04 23:41:47 <jjardon>	for the deprecateion stuff
 188 may 04 23:41:59 <ebassi>	Company: deprecation + switch sounds fine to me as well
 189 may 04 23:42:14 <Company>	cool
 190 may 04 23:42:20 <Company>	i'll have a go at that then
 191 may 04 23:42:32 <ebassi>	Company: is cairo_region_t including all the fixes of the X11 region that have been accumulated over the years?
 192 may 04 23:42:41 <Company>	ebassi: yes
 193 may 04 23:42:47 <ebassi>	cool
 194 may 04 23:42:59 <ebassi>	having a single copy will help
 195 may 04 23:43:01 <Company>	ebassi: cairo_region_t exposes pixman_region_t which is the region implementation used in X
 196 may 04 23:43:30 <ebassi>	right
 197 may 04 23:43:38 *	mclasen was out for a while again
 198 may 04 23:43:40 <mclasen>	can you point me to the bug/patch ?
 199 may 04 23:43:53 <bratsche>	http://bugzilla.gnome.org/show_bug.cgi?id=613284
 200 may 04 23:44:10 <Company>	mclasen: http://fpaste.org/c9Kn/ - you didn't miss a lot
 201 may 04 23:44:20 <ebassi>	mclasen: after this, do you want to talk about gtk 2.90 in case you get another outage?
 202 may 04 23:44:26 <mclasen>	sure
 203 may 04 23:44:49 <Company>	hrm, i guess there's an issue with apis that return GdkRegions, but i'll figure that out
 204 may 04 23:46:10 <mclasen>	Company: for the record, getting rid of an extra copy of miregion can only be good
 205 may 04 23:46:26 <Company>	yeah
 206 may 04 23:46:42 <Company>	the only question is how to do it as compatible as possible
 207 may 04 23:46:53 <mclasen>	so, if we can make this work largely compatibly, we should do it
 208 may 04 23:47:28 <mclasen>	so, 2.90 next ?
 209 may 04 23:48:08 <mclasen>	the plan was to merge 2.90 to master as soon as a) we have stable branches and b) 2.90 works
 210 may 04 23:48:18 <mclasen>	we have a) now, and we got pretty close on b), I think
 211 may 04 23:48:36 <mclasen>	only testtext seemed to fail to build last time I tried
 212 may 04 23:49:09 <mclasen>	so I'd like to propose that we merge the 2.90 branch asap, before I roll the first 2.90 release 
 213 may 04 23:49:33 <ebassi>	sounds like a plan to me
 214 may 04 23:49:36 <mclasen>	we can disable testtext for the time being, or maybe somebody gets inspired to port it of GtkItemFactory
 215 may 04 23:50:18 <jjardon>	+1 from me, we can rebase the branch again if you plan to merge rigth now
 216 may 04 23:50:20 <mclasen>	as for timing I'd like to get out a devel release with the extended layout stuff soon, like end of this week
 217 may 04 23:50:51 <mclasen>	so we get some more certainty on regessions
 218 may 04 23:51:32 <bratsche>	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?
 219 may 04 23:51:43 <mclasen>	bratsche: there is a 2.22 branch
 220 may 04 23:51:44 <ebassi>	bratsche: 2.90
 221 may 04 23:51:53 <mclasen>	but it only takes missing accessors 
 222 may 04 23:52:00 <bratsche>	Cool, thanks.
 223 may 04 23:52:03 <mclasen>	not new features like extended layout, xi2 or csd
 224 may 04 23:52:21 <bratsche>	Okay cool.. seb128 was asking me to find this out tonight, so mission accomplished. ;)
 225 may 04 23:52:27 <mclasen>	to make the branching picture more confusing, there's also a regular stable 2.20 branch
 226 may 04 23:52:40 <mclasen>	but I don't think I'm going to do much more there, after the .1 releases last weekend
 227 may 04 23:53:08 <mclasen>	getting close to the 2 hour mark
 228 may 04 23:53:17 <mclasen>	should we very briefly touch orientable ?
 229 may 04 23:53:30 <ebassi>	mclasen: what's missing in those?
 230 may 04 23:53:32 *	mclasen is all for getting beyond the impasse, and making things flippable
 231 may 04 23:54:00 <ebassi>	yeah, me too
 232 may 04 23:54:06 <mclasen>	ebassi: timj was against making them nonabstract because we had a disagreement on default property values
 233 may 04 23:54:23 <mclasen>	but nothing ever came out of the default change discussion
 234 may 04 23:54:24 <ebassi>	which would be solved by changing the default values
 235 may 04 23:54:28 <mclasen>	so, we shoul dprobably move on
 236 may 04 23:54:36 <ebassi>	or you were disagreeing on the values themselves?
 237 may 04 23:54:45 <jjardon>	mclasen, Do you want to merge the gtk-2-90 branch now? I can rebase the gtk-2-90 branch again if you want
 238 may 04 23:54:56 <mclasen>	ebassi: I don't think there ever was an exhaustive list of proposed changes
 239 may 04 23:55:01 <bratsche>	afk, brb.
 240 may 04 23:55:03 <mclasen>	the one that tim felt strongly about was visible 
 241 may 04 23:55:19 <mclasen>	and I'd feel at least a little uneasy about changing that for some widgets, but not all
 242 may 04 23:55:28 <ebassi>	visible → TRUE by default?
 243 may 04 23:56:21 <mclasen>	my honest opinion is that people should use interface builders and they should take care of setting sensible initial values for all properties
 244 may 04 23:56:33 <mclasen>	of course, that gets harder if we change the defaults between versions....
 245 may 04 23:58:25 <tristan_>	g_param_spec_boolean_set_default() wouldnt hurt either
 246 may 04 23:58:31 <ebassi>	okay, so the result is that we're still blocked; it might be good to get the ball rolling on the mailing list again
 247 may 04 23:58:33 <tristan_>	(and all types...)
 248 may 04 23:58:36 <mclasen>	are people in favor of changing defaults ? 
 249 may 04 23:58:49 <ebassi>	mclasen: I need to review the list on the wiki
 250 may 04 23:59:16 <ebassi>	some of them I remember making sense to be changed
 251 may 04 23:59:19 <mclasen>	I mostly want flippable widgets; if the cost of that is making all widgets visible by default, so be it
 252 may 04 23:59:36 <mclasen>	but I don't think it makes sense to change the default only for some, formerly abstract types
 253 may 05 00:00:14 <tristan_>	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)
 254 may 05 00:00:35 <mclasen>	tristan_: you need to know the default at runtime, no ?
 255 may 05 00:00:49 <mclasen>	I mean, the .ui file you write out could be used by gtk 2.20, 3.0, ...
 256 may 05 00:01:34 <tristan_>	hmmm, files that were created post 3.0 will "know the new default"
 257 may 05 00:01:51 *	bratsche returns
 258 may 05 00:02:34 <tristan_>	mclasen, Glade resorts to a runtime value at widget creation time
 259 may 05 00:02:43 <mclasen>	tristan_: I think you need a version marker in your ui file, and have gtkbuilder know what defaults apply to what version
 260 may 05 00:03:27 <tristan_>	hrm, and have GtkBuilder introspect that for us ?
 261 may 05 00:04:14 <tristan_>	in our runtime we'll need to know defaults for versions that are not the "current" one 
 262 may 05 00:04:36 <tristan_>	currently really Glade tries to assume they are constant
 263 may 05 00:04:46 <tristan_>	(i.e. defaults across versions)
 264 may 05 00:04:52 <mclasen>	tristan_: you either make glade write out all properties explicitly, making defaults irrelevant at runtime
 265 may 05 00:05:04 <tristan_>	and when they differ we handle them with some brute force if we can
 266 may 05 00:05:08 <mclasen>	or you have a version marker in the .ui, so gtkbuilder can infer what defaults glade 'implied'
 267 may 05 00:05:28 <tristan_>	hmmm, well we do have the version marker
 268 may 05 00:06:07 <tristan_>	but it doesnt give us an introspectable store to check what default for what version ;-)
 269 may 05 00:06:20 <tristan_>	that's something that might have to be hand-written I guess
 270 may 05 00:06:27 <mclasen>	or maybe you want to let the app writer say 'write a .ui file that works with gtk versions x  y z"
 271 may 05 00:06:43 <mclasen>	and then glade can be smart about which defaults it can rely on and which changed in those versions
 272 may 05 00:07:13 <mclasen>	that needs no changes in gtkbuilder
 273 may 05 00:07:30 <tristan_>	that might be overboard, I think it would be nice if a GtkBuilder dependency can be >= target version
 274 may 05 00:07:40 <tristan_>	and an exception for 3.0 probably
 275 may 05 00:08:08 <mclasen>	i think it is really only about 'assume 3.0' vs '2.x compat'
 276 may 05 00:09:44 <tristan_>	I have to give some thought to what the effects exactly are going to be and the measures needed
 277 may 05 00:10:05 <tristan_>	I didnt expect the horizontal thing so I might be missing stuff
 278 may 05 00:10:18 <ebassi>	should we punt GController and GtkContainer+GtkBuilder to the next meeting?
 279 may 05 00:10:25 <tristan_>	but surely implementing a handmade cache of default value histories will help 
 280 may 05 00:10:33 <mclasen>	ebassi: I think so, getting late
 281 may 05 00:10:35 <ebassi>	we passed the 2 hours mark already :-)
 282 may 05 00:10:45 <mclasen>	so, in summary
 283 may 05 00:11:04 <mclasen>	actions for this week: we merge 2.90,  get a 2.90 release out, merge gdbus
 284 may 05 00:11:12 <mclasen>	should keep us busy :-)
 285 may 05 00:12:01 <ebassi>	heh
 286 may 05 00:12:19 <ebassi>	for GController I think I'll have to send an email to the mailing list anyway
 287 may 05 00:12:38 <mclasen>	that would be great
 288 may 05 00:13:10 <jjardon>	a 2.90 release! nice :)
 289 may 05 00:14:05 <ebassi>	okay, let's meet up again in one week - unless there are some issues
 290 may 05 00:14:11 <jjardon>	Also, I'd like to announce that I'm going to start moving all the GSEAL data to priv structures as my GSoC project. 
 291 may 05 00:14:20 <jjardon>	Thanks to garnacho to be my mentor ;)
 292 may 05 00:14:26 <ebassi>	jjardon: awesome!
 293 may 05 00:14:34 <garnacho>	:)
 294 may 05 00:14:35 <bratsche>	Nice.
 295 may 05 00:15:27 <jjardon>	2010 will be the GTK+3 year ;)
 296 may 05 00:15:28 <ebassi>	have a nice evening/a good night everyone
 297 may 05 00:15:48 <ebassi>	I'll send the minutes to the mailing list; somebody else will have to push the log to the wiki, if possible
 298 may 05 00:16:11 <mclasen>	in closing, 2.90 is an ok version number to choose, right ?
 299 may 05 00:16:17 <jjardon>	ebassi, I'll do that
 300 may 05 00:16:21 <mclasen>	or do we expect to do more than 10 snapshots before 3? 
 301 may 05 00:17:34 <jjardon>	mclasen, we always can use 2.999
 302 may 05 00:17:41 <ebassi>	heh
 303 may 05 00:17:58 <ebassi>	but no - I don't think we'll need more than 10 snapshots
 304 may 05 00:18:24 <garnacho>	I hope not either
 305 may 05 00:18:26 <mclasen>	2.99.05.3
 306 may 05 00:18:30 <mclasen>	lets not go there
 307 may 05 00:19:03 <mclasen>	I'll just do a 2.90, and we'll be disciplined about turning it into 3.0 without major detours...
 308 may 05 00:19:45 <jjardon>	Other releases: 2.17.11 and 2.19.7
 309 may 05 00:20:08 <jjardon>	10 should be enough