1 mar 23 21:01:22 *	tristan (~tristan@74.210.0.150) ha entrado en #gtk-devel
   2 mar 23 21:01:34 <jjardon>	tristan, just in time ;)
   3 mar 23 21:03:02 <tristan>	:)
   4 mar 23 21:03:54 <jjardon>	garnacho, As you are have the first items in the agenda, Do you have some plan to seal GtkStyle to take a look?
   5 mar 23 21:04:45 <garnacho>	well, I'm actually working on deprecating it :)
   6 mar 23 21:04:50 <garnacho>	but yes, that's my plan
   7 mar 23 21:08:27 *	mclasen (~mclasen@c-98-229-128-128.hsd1.ma.comcast.net) ha entrado en #gtk-devel
   8 mar 23 21:09:24 *	Company (~Company@e176114193.adsl.alicedsl.de) ha entrado en #gtk-devel
   9 mar 23 21:09:38 <garnacho>	jjardon, oh, you mean as in some link and such?
  10 mar 23 21:09:50 <jjardon>	garnacho, yeah ;)
  11 mar 23 21:10:08 *	mclasen stumbles in
  12 mar 23 21:10:39 <mclasen>	who leads ?
  13 mar 23 21:10:55 <jjardon>	seems that ebassi is not available
  14 mar 23 21:11:20 *	mclasen has roughly an hour
  15 mar 23 21:11:48 *	mclasen did a 2.20 release today
  16 mar 23 21:12:26 <garnacho>	jjardon, at the moment I've just have http://live.gnome.org/CarlosGarnacho/ThemingProposal , I'm developing towards implementing that, but the branch is still missing some features, I think I'll be pushing to a public repo in a few days
  17 mar 23 21:12:49 <garnacho>	mclasen, really good news, congrats
  18 mar 23 21:14:12 <jjardon>	yeah, congrants everyone for the new release
  19 mar 23 21:14:44 <mclasen>	stable glib release to follow later in the week
  20 mar 23 21:16:34 *	pbor (~paolo@host32-21-dynamic.45-79-r.retail.telecomitalia.it) ha entrado en #gtk-devel
  21 mar 23 21:16:36 <mclasen>	should we just follow the agend ?
  22 mar 23 21:16:38 <mclasen>	a
  23 mar 23 21:17:21 <jjardon>	if you have little time, we can discuss the main topics
  24 mar 23 21:17:31 <jjardon>	In my case, I'd like to discuss the plans for the next GTK+ release, ie, will it be 2.22 or 3.0 ? If it's 3.0, there are some work to do and we need to coordinate.
  25 mar 23 21:18:21 *	mclasen thinks it is 3.0
  26 mar 23 21:18:25 <mclasen>	other opinions ?
  27 mar 23 21:18:45 *	federico (~federico@189.129.80.232) ha entrado en #gtk-devel
  28 mar 23 21:19:07 *	federico looks GTK_DIRECTION_LEFT
  29 mar 23 21:19:11 *	federico looks GTK_DIRECTION_RIGHT
  30 mar 23 21:19:25 <pbor>	mclasen: was the plan to have 2.90 (=2.2X without the old cruft) abandoned?
  31 mar 23 21:19:42 <mclasen>	pbor: well, nobody pushed it actively
  32 mar 23 21:19:49 <pbor>	ok
  33 mar 23 21:19:52 <mclasen>	I would have hoped for the 3.0 crowd to do so
  34 mar 23 21:19:52 <jjardon>	I've rebased the gtk+2-90 branch recently, but It needs to be rebased again, I think
  35 mar 23 21:19:58 <mclasen>	but that was not the case...
  36 mar 23 21:20:10 <mclasen>	so we should probably figure out if someone can do that on short notice
  37 mar 23 21:20:32 <mclasen>	jjardon: is the 2.90 branch in sync with master ?
  38 mar 23 21:20:59 <jjardon>	yeah, I can rebase it today if you want
  39 mar 23 21:21:14 <mclasen>	would be cool
  40 mar 23 21:21:17 <garnacho>	mclasen, btw, what would be the policy for deprecations?
  41 mar 23 21:21:26 <garnacho>	in this cycle I mean
  42 mar 23 21:21:27 <jjardon>	the main problem is that some test from testgtk are still using deprecated api
  43 mar 23 21:21:33 <jjardon>	and build fails
  44 mar 23 21:21:49 <garnacho>	jjardon, need a hand with that?
  45 mar 23 21:22:03 <mclasen>	that would probably need fixing before a release...
  46 mar 23 21:22:03 <jjardon>	garnacho, would be cool :)
  47 mar 23 21:22:05 *	aruiz (~aruiz@94-192-234-22.zone6.bethere.co.uk) ha entrado en #gtk-devel
  48 mar 23 21:22:14 <jjardon>	aruiz, hey ;)
  49 mar 23 21:22:25 <aruiz>	hey jjardon 
  50 mar 23 21:22:29 <aruiz>	sorry guys
  51 mar 23 21:22:35 <aruiz>	:)
  52 mar 23 21:23:35 <mclasen>	garnacho: I guess we still add deprecations as needed - I assume you ask because the xi2 stuff obsoletes a bunch of gdk api ?
  53 mar 23 21:25:25 <garnacho>	mclasen, yes :), was mostly curious/amused about starting 3.0 with deprecated stuff
  54 mar 23 21:25:44 <garnacho>	but there's no better option
  55 mar 23 21:26:18 <mclasen>	probably not
  56 mar 23 21:27:26 <desrt>	what is the next stable glib release?
  57 mar 23 21:27:38 *	desrt created a 2.26 milestone today without really thinking about it...
  58 mar 23 21:28:25 <jjardon>	desrt, I think there is not plans for Glib 3.0, if you are asking that
  59 mar 23 21:28:33 <desrt>	ok.  cool.
  60 mar 23 21:28:52 <bratsche>	Hey guys.
  61 mar 23 21:28:59 <bratsche>	woot for the new release!
  62 mar 23 21:29:11 <aruiz>	yup
  63 mar 23 21:29:23 <jjardon>	garnacho, we can remove the deprecated stuff in the 2-90 branch, instead deprecated them
  64 mar 23 21:30:09 <mclasen>	practical question: once we have a 2.90 release done, do we merge 2.90 to master, and continue there ?
  65 mar 23 21:30:34 <federico>	so I just reopened the treeview-focus can of worms
  66 mar 23 21:31:07 <desrt>	mclasen: wouldn't 2.90 be released from master and then branched off for stable updates in the usual way?
  67 mar 23 21:31:08 <garnacho>	jjardon, my concern is that if there is not going to be another 2.x release, there wouldn't be a clean transition to 3.0 if we deprecate+remove stuff
  68 mar 23 21:32:43 <bratsche>	federico: Can I ping you before you go about a patch to peek at for filechooser?
  69 mar 23 21:32:51 <jjardon>	garnacho, as mclasen said before,  I think there won't be a clean transition anyway
  70 mar 23 21:33:02 <pbor>	I think 2.90 does not make much sense to be released if stuff that works on 2.90 will not work on 3.0
  71 mar 23 21:33:09 <mclasen>	we need to continue the sealing business in 2.x, anyway
  72 mar 23 21:33:23 <pbor>	so I'd just go with releasing 3.0
  73 mar 23 21:33:30 <mclasen>	I think we had a rough agreement that we need to continue to add missing accessors in 2.x
  74 mar 23 21:33:43 <federico>	bratsche: sure
  75 mar 23 21:34:09 <jjardon>	mclasen, I think the needed accessor are really corner cases
  76 mar 23 21:34:51 <jjardon>	The main problem is ->need_im_reset, It affects some applications
  77 mar 23 21:35:17 <Company>	so if we can deprecate during 2.90, does that mean I can deprecate GdkRegion?
  78 mar 23 21:35:29 <mclasen>	jjardon: yeah, that needs to be finished
  79 mar 23 21:35:35 <pbor>	as one of the user of ->need_im_reset I can assure that's really the least of the problems
  80 mar 23 21:35:56 <desrt>	Company: do we have a replacement, or...?
  81 mar 23 21:35:56 <bratsche>	Has anyone maintained any authoritative list of mappings between old accessors and new functions?  At some point timj emailed me about the code rewriter and implied that he or someone at Lanedo would continue working on that, but I never heard more about that.
  82 mar 23 21:36:02 *	kalikianatoli (~kalikiana@xdsl-89-0-129-64.netcologne.de) ha entrado en #gtk-devel
  83 mar 23 21:36:03 <Company>	desrt: cairo_region_t
  84 mar 23 21:36:07 <desrt>	ah.
  85 mar 23 21:36:15 <Company>	it got added over a year ago but i never noticed
  86 mar 23 21:36:28 <pbor>	as an app developer the biggest blocker right now is that switching to 3.0 means wave goodbye to the win32 port
  87 mar 23 21:37:09 <aruiz>	pbor, really?
  88 mar 23 21:37:37 <mclasen>	bratsche: old accessors == struct fields, but no, I don't
  89 mar 23 21:37:54 <mclasen>	but that would be a good topic for a 2.x -> 3 porting guide
  90 mar 23 21:37:59 <mclasen>	which is something we need to start, I guess
  91 mar 23 21:38:03 <bratsche>	Well, the Win32 port has fallen into a bit of disrepair since I stopped working on it I'm afraid. :/
  92 mar 23 21:38:26 <jjardon>	Company, I think that remove GdkRegion makes sense
  93 mar 23 21:38:43 <pbor>	aruiz: last working version on win32 is 2.16, so if I use deprecated functions it will not work with 3.0, if I use new accessors it will not work with 2.16 on win32
  94 mar 23 21:38:59 <aruiz>	:/
  95 mar 23 21:39:45 *	bag se ha marchado (Ex-Chat)
  96 mar 23 21:39:52 <mclasen>	bratsche: how serious is the disrepair ? would it make sense to have a catchup period for ports before we do 3.0, or is it just hopeless ?
  97 mar 23 21:39:53 <Company>	jjardon: yeah, i'm all for it
  98 mar 23 21:39:57 <desrt>	is there some cairo rectangle type too?
  99 mar 23 21:40:07 <Company>	jjardon: i just like to get an OK before i port all of gtk
 100 mar 23 21:40:15 <Company>	desrt: multiple ;)
 101 mar 23 21:40:26 <bratsche>	I can probably commit to spend a weekend or two to fix that up at least.  But right now there are bigger issues, with the Win32 theme engine appearing to not work since CSW went in.  That's going to take some more debugging and I'm not willing to spend the time on it right now unfortunately. :(
 102 mar 23 21:40:37 <desrt>	it seems like maybe a reasonable goal would be to kill off all the 'gdk_cairo' functions
 103 mar 23 21:40:38 <garnacho>	mclasen, I'm afraid I'm not helping there, the win32 backend in the xi2 branch is still undone :/
 104 mar 23 21:41:12 <Company>	desrt: you need gdk_cairo_create()
 105 mar 23 21:41:13 <kalikianatoli>	desrt, how would you replace gdk_cairo_create?
 106 mar 23 21:41:15 <mclasen>	garnacho: what about os x ?
 107 mar 23 21:41:20 <desrt>	other than that one :p
 108 mar 23 21:41:30 <aruiz>	bratsche, I can have a look into the engine
 109 mar 23 21:41:33 <bratsche>	I mean, quite frankly I'm finding much less time to work on gtk+ in Linux this past year than I expected to.. and so I don't want to promise more time to the Win32 port since I don't even use it anymore.
 110 mar 23 21:41:38 <desrt>	although arguably that should be called gdk_drawable_create_cairo() or something
 111 mar 23 21:41:42 <Company>	desrt: i would want to keep set_source_pixbuf(), but i intend to change it
 112 mar 23 21:41:51 <garnacho>	mclasen, kris has been working on it, I've already got a pile of patches to have a look at
 113 mar 23 21:41:57 <aruiz>	bratsche, but I actually think I'm gonna need help from someone who understands the backend
 114 mar 23 21:42:05 <mclasen>	desrt: whats wrong with those 4-5 functions ?
 115 mar 23 21:42:06 <Company>	desrt: once my support for unmultiplied ARGB lands
 116 mar 23 21:42:10 <jjardon>	Company, maybe you can do it in the 2-90 branch
 117 mar 23 21:42:20 <desrt>	mclasen: if we're moving to cairo-based regions/rectangles....
 118 mar 23 21:42:32 <bratsche>	aruiz: That's unfortunately basically me and Tor at this point I think.
 119 mar 23 21:42:35 <desrt>	there's a couple of them gone
 120 mar 23 21:42:41 <desrt>	i guess we still have gdkcolor kicking around
 121 mar 23 21:42:41 <garnacho>	mclasen, he was also aiming to provide support for the multitouch trackpads, btw
 122 mar 23 21:42:42 <Company>	jjardon: yeah, i'll branch off it and have a go
 123 mar 23 21:43:02 <Company>	desrt: they're slightly different
 124 mar 23 21:43:03 <desrt>	Company: any opinions on GdkColor?
 125 mar 23 21:43:09 <jjardon>	desrt, not in gtk-2-90
 126 mar 23 21:43:12 <mclasen>	Company: so, what do we gain by moving to cairo regions ? and how much further deprecation churn are we willing to take ?
 127 mar 23 21:43:40 <kalikianatoli>	desrt, rather typedef than replacing for now. we can't remove any more cruft anyway unless we slip in another release
 128 mar 23 21:43:40 <Company>	mclasen: we lose the need to do conversions between the region types
 129 mar 23 21:43:54 <aruiz>	bratsche, fixing the engine was the reason I tried to build GTK+ on windows a few weeks ago, cross compiling seems to be the best way to go still
 130 mar 23 21:44:04 <Company>	mclasen: cairo might want to add API to get change regions etc and it'd be way easier to expose
 131 mar 23 21:44:37 <mclasen>	Company: of course, internally, we still have to deal with Xlib regions
 132 mar 23 21:45:15 <Company>	mclasen: yeah, we'd just do cairo_region_foo() instead of gdk_region_foo()
 133 mar 23 21:45:40 <jjardon>	If the next version will be 3.0, how about to branch 2.20 and use gtk-2-90 as a master branch?
 134 mar 23 21:46:00 <bratsche>	aruiz: I'm not entirely sure if the problem is really in the engine as it appears or not.  I can't remember now, would need to look into it again.
 135 mar 23 21:46:29 <aruiz>	bratsche, I can try to learn how the backend works perhaps? I certainly need your support
 136 mar 23 21:47:02 <bratsche>	aruiz: Yeah, I can help.  I don't have a Win32 machine plugged in anywhere at the moment but I can find space for it again if need be.
 137 mar 23 21:47:11 <mclasen>	garnacho: does your xi2 work apply cleanly against 2.90 ? or is it against master ?
 138 mar 23 21:47:32 <garnacho>	mclasen, it's against master
 139 mar 23 21:47:45 <garnacho>	if needed my next rebase could be against that
 140 mar 23 21:47:52 <jjardon>	gtk-2-90 is currently broke
 141 mar 23 21:48:40 <mclasen>	right
 142 mar 23 21:48:47 <jjardon>	as said before, some tests from testgtk need to be ported to new api
 143 mar 23 21:49:05 *	mclasen will give 2.90 a try later tonight
 144 mar 23 21:49:11 *	kalikianatoli hopes the gdk sealing can get in soon
 145 mar 23 21:49:41 <jjardon>	I'll rebase 2-90 against master today
 146 mar 23 21:50:06 <jjardon>	Also, we should decide between a or b here: http://live.gnome.org/GTK%2B/3.0/Tasks#Q2
 147 mar 23 21:50:46 <jjardon>	to start the work of remove all structure fields
 148 mar 23 21:50:52 *	pbor thinks b is best
 149 mar 23 21:51:03 <desrt>	b is slow....
 150 mar 23 21:51:22 <pbor>	if its slow we should not have done the sealing in the first place
 151 mar 23 21:51:45 <pbor>	the sealing was sold on the premise that the cost is irrelevant
 152 mar 23 21:51:52 <desrt>	well.  PLT jumps and dynamic symbol lookups are slow too
 153 mar 23 21:51:57 *	kalikianatoli favours b with exceptions if necessary
 154 mar 23 21:52:01 <garnacho>	desrt, we can also have private.h headers
 155 mar 23 21:52:21 <jjardon>	I think is better b too
 156 mar 23 21:52:57 <desrt>	i picture a future...
 157 mar 23 21:53:05 <jjardon>	great, we can also use ->priv instead GET_PRIVATE(), but this can be done later
 158 mar 23 21:53:26 <pbor>	b keeps people honest so that when someone needs to extend a class outside gtk, all that is needed is there
 159 mar 23 21:53:30 <desrt>	where somebody comes along and claims a 10% GTK speedup by doing some crazy hack that turns gtk_widget_get_foo() into some inline function or macro
 160 mar 23 21:54:11 <mclasen>	desrt: would that be you ?
 161 mar 23 21:54:35 <desrt>	mclasen: i'm personally interested in reducing the level of hacktastic features in our build system :p
 162 mar 23 21:54:45 <aruiz>	hah
 163 mar 23 21:54:53 <Company>	clang -O4 ftw!
 164 mar 23 21:54:56 <desrt>	doing this would be like galias pain all over again
 165 mar 23 21:55:16 <kalikianatoli>	desrt, like gmarshaller? :-D
 166 mar 23 21:55:18 <Company>	-O4 promises to inline across file boundaries
 167 mar 23 21:55:33 <desrt>	yes.  WPO would be nice.
 168 mar 23 21:55:47 <desrt>	i guess eventually we'll get there
 169 mar 23 21:57:01 <jjardon>	So, what about use 2-90 as master branch?
 170 mar 23 21:57:56 *	mclasen would rather continue with master + stable
 171 mar 23 21:58:15 <mclasen>	of course, we can only merge 2.90 after it builds and works...
 172 mar 23 21:58:19 <kalikianatoli>	we'd rather have 2.22, or not?
 173 mar 23 21:58:28 <kalikianatoli>	since we still need a number of accessors
 174 mar 23 21:58:56 <mclasen>	kalikanatoli: I guess thats a fair point
 175 mar 23 21:59:05 *	federico se ha marchado (Ping timeout: 600 seconds)
 176 mar 23 21:59:10 <jjardon>	to remove and create a new branch: git push :gtk-2-90 && git push gtk-2-90 ?
 177 mar 23 21:59:15 <kalikianatoli>	as sad as it is, 2.90 is supposed to be less painful by not having new api
 178 mar 23 21:59:23 <kalikianatoli>	so we need 2.22
 179 mar 23 21:59:50 <pbor>	what about this plan:
 180 mar 23 21:59:55 <pbor>	 no 2.90 release
 181 mar 23 22:00:06 <pbor>	 add accessors during 2.20.X
 182 mar 23 22:00:19 <pbor>	  when all accessors are there tag it 2.22
 183 mar 23 22:00:25 <mclasen>	kalikianatoli: not having new api conflicts with the desire to merge xi2 and a bunch of other stuff...
 184 mar 23 22:01:25 <kalikianatoli>	mclasen, that would go into 2.22, right? so it would be fine
 185 mar 23 22:01:44 <mclasen>	kalikianatoli: assuming there is a 2.22...
 186 mar 23 22:01:47 <jjardon>	Also, xi2 would be a good excuse to encourage people to use GTK 3.0 ...
 187 mar 23 22:02:20 <kalikianatoli>	mclasen, I assume there is because otherwise we simply can't keep the plan :-)
 188 mar 23 22:02:43 <kalikianatoli>	which was that last abi compat has the same api as 2.90
 189 mar 23 22:03:24 <mclasen>	the thing with 'the plan' is that most of the people who wanted to work on it have largely disappeared...
 190 mar 23 22:03:38 <desrt>	common-sense question: maybe i missed soemthing
 191 mar 23 22:03:45 <desrt>	are we going to continue to support subclass-by-containment?
 192 mar 23 22:03:55 <jjardon>	gtk-2-90 rebased against master now
 193 mar 23 22:04:05 <desrt>	ie: GtkWindow is a GtkBin so the first member of the GtkWindow structure is GtkBin?
 194 mar 23 22:04:19 <mclasen>	and we are struggling to keep things going with insufficient resources...
 195 mar 23 22:05:00 <mclasen>	desrt: how could we not ?
 196 mar 23 22:05:08 <desrt>	mclasen: that's exactly my point
 197 mar 23 22:05:18 <desrt>	doesn't that make it impossible to move the structure definitions to .c files?
 198 mar 23 22:05:29 <jjardon>	And as I sadi before, the remaining accessors are corner cases, the only important is ->need_im_context
 199 mar 23 22:05:38 <desrt>	since you need to have a complete type in order to include it as a requirement for subclassing
 200 mar 23 22:05:56 <mclasen>	desrt: I assume the private structs will be in C files, and the headers will just have empty public structs
 201 mar 23 22:06:19 <desrt>	containing just a priv pointer?
 202 mar 23 22:06:20 <Company>	desrt: widget->priv->window
 203 mar 23 22:06:41 <garnacho>	desrt, I was thinking something in the line of #define G_DECLARE_OBJECT(_n_, _type_) struct _n_ { _type_ parent_instance; gpointer priv };
 204 mar 23 22:07:02 <mclasen>	desrt: yeah, look at GtkStatusIcon, eg
 205 mar 23 22:07:04 <kalikianatoli>	structs will be struct { gobjectclass; priv; } afair
 206 mar 23 22:07:17 <desrt>	ok.  so this is a non-question, then
 207 mar 23 22:07:27 <desrt>	it's not about moving the location of the definition of any structures
 208 mar 23 22:07:33 <jjardon>	desrt, see for example: http://git.gnome.org/browse/gtk+/commit/?h=gtk-2-90&id=740c05ff56de32d6e7802e0a369e36b6bcdb9faa
 209 mar 23 22:07:37 <desrt>	but rather about moving everything out of the public structure and into ->priv->
 210 mar 23 22:08:13 <kalikianatoli>	exactly
 211 mar 23 22:08:15 <desrt>	in that case, it's obvious that the private structure should only be in the .c file
 212 mar 23 22:08:32 <desrt>	we've been doing it that way forever
 213 mar 23 22:08:46 <desrt>	the a/b choice makes it sound like we're hiding the instance structure itself :p
 214 mar 23 22:08:55 <kalikianatoli>	desrt, the non-obvious cases are crazy interdependencies of eg. gtkwidget and gtkwindow
 215 mar 23 22:09:24 <kalikianatoli>	where we can't keep them from each other entirely
 216 mar 23 22:10:02 <jjardon>	pbor, that was the plan for 2.20 ...
 217 mar 23 22:10:12 *	mclasen drops off
 218 mar 23 22:10:20 <mclasen>	discuss amongst yourselves... :-)
 219 mar 23 22:10:25 *	mclasen se ha marchado (There must be some way out of here.)
 220 mar 23 22:10:59 <kalikianatoli>	so we agree on "b. Move object structures to the local C file", right?
 221 mar 23 22:11:07 <desrt>	no...
 222 mar 23 22:11:22 <desrt>	rather "c. Do what we already do, but more of it." :p
 223 mar 23 22:11:38 <desrt>	we're not moving any structures
 224 mar 23 22:11:51 <desrt>	rather, shifting items from one structure to another
 225 mar 23 22:12:19 <kalikianatoli>	ah, yes, it should be "Move struct members into private structure"
 226 mar 23 22:12:33 <desrt>	yes.  and the private structure is very obviously private to the .c file
 227 mar 23 22:12:50 <desrt>	also, #P2 is done
 228 mar 23 22:13:02 <desrt>	class private data got merged into glib this past unstable release
 229 mar 23 22:13:12 <pbor>	desrt: mmm can't you just have typedef GtkFoo _GtkFoo in the .h and the real struct in the .c?
 230 mar 23 22:13:15 <kalikianatoli>	it's there as Done :-)
 231 mar 23 22:13:19 <desrt>	pbor: no.
 232 mar 23 22:13:38 <kalikianatoli>	ah, the paragraph is out of sync with the table
 233 mar 23 22:13:39 <desrt>	kalikianatoli: i see #P2 Progress "Not yet started."
 234 mar 23 22:13:45 *	kalikianatoli goes to fix
 235 mar 23 22:13:49 <desrt>	pbor: we subclass by inclusion
 236 mar 23 22:13:53 <desrt>	if you try to say
 237 mar 23 22:13:56 <desrt>	struct _GtkWindow {
 238 mar 23 22:13:59 <desrt>	  GtkWidget parent_instance;
 239 mar 23 22:14:00 <desrt>	...
 240 mar 23 22:14:00 <desrt>	}
 241 mar 23 22:14:07 <desrt>	that obviously fails unless GtkWidget is a complete type
 242 mar 23 22:14:20 <pbor>	ok
 243 mar 23 22:15:07 <desrt>	on topic of #P4, is that really true?
 244 mar 23 22:15:17 <kalikianatoli>	jjardon, are you editing the page atm?
 245 mar 23 22:15:32 <jjardon>	just finished now
 246 mar 23 22:15:37 <desrt>	i was under the impression that for every property we sealed/moved-to-private we would have new accessor functions as appropriate
 247 mar 23 22:15:48 <jjardon>	to corrent "move strcut member"
 248 mar 23 22:15:50 <desrt>	ie: g_object_get use will not increase -- you'll use the accessor function directly
 249 mar 23 22:16:23 <kalikianatoli>	desrt, "to simply access fields" refers to struct members
 250 mar 23 22:16:33 <kalikianatoli>	you won't be able to use them as they're gone
 251 mar 23 22:16:39 <desrt>	kalikianatoli: i know
 252 mar 23 22:16:47 <desrt>	kalikianatoli: what i'm saying is that this does not imply increased use of gobject properties
 253 mar 23 22:17:13 <kalikianatoli>	ah, right.
 254 mar 23 22:17:24 <desrt>	therefor #P4 seems slightly ... wrong
 255 mar 23 22:18:35 <desrt>	#P12 looks very positive.  i already tried this for libglib and i had a lot of success
 256 mar 23 22:18:47 <desrt>	talked to mmeeks about it, too.  he thinks that it's the right thing to do.
 257 mar 23 22:18:56 <garnacho>	desrt, I think P4 mostly "we need better convenience api for getting a gobject property" badly worded :)
 258 mar 23 22:18:58 <desrt>	i'll gladly take responsibility ofr that task
 259 mar 23 22:19:15 <desrt>	garnacho: the justification given for the "need" is completely wrong, though
 260 mar 23 22:19:42 <garnacho>	right
 261 mar 23 22:19:51 <desrt>	i'd argue there's no need at all
 262 mar 23 22:20:08 <kalikianatoli>	I changed it to say "accessor functions and GObject properties"
 263 mar 23 22:20:12 <desrt>	as far as i'm concerned, gobject properties have no place in normal human-written code
 264 mar 23 22:20:36 <kalikianatoli>	there are a few use cases where only properties exist
 265 mar 23 22:20:43 *	Company se ha marchado (Remote closed the connection)
 266 mar 23 22:20:47 <desrt>	perhaps we should add accessors :p
 267 mar 23 22:20:57 <kalikianatoli>	think of GtkSettings
 268 mar 23 22:21:06 <pbor>	there are api there are purely property based
 269 mar 23 22:21:09 <pbor>	GtkTextTag
 270 mar 23 22:21:22 <desrt>	properties are annoying to use and they're also slow.....
 271 mar 23 22:21:28 <desrt>	so why?
 272 mar 23 22:21:53 <kalikianatoli>	because you can read and write them in loops, and create config files
 273 mar 23 22:22:12 <desrt>	right.  and use them for object construction and also for things like GtkCellRenderer
 274 mar 23 22:22:17 <kalikianatoli>	exactly
 275 mar 23 22:22:19 <desrt>	but i mean, why should we have APIs based solely upon them?
 276 mar 23 22:22:34 <desrt>	as a programmer, i never want to have to type g_object_set() unless i'm doing something 'special'
 277 mar 23 22:22:38 <pbor>	because you want an api forward compatible
 278 mar 23 22:23:03 <tristan>	desrt, I think the issue is more, when GTK+ needs an api, we add it then but usually not before
 279 mar 23 22:23:12 <pbor>	so that you can add new properties without adding a else if (isbar) foo_set_bar
 280 mar 23 22:23:13 <desrt>	pbor: it just shifts the forward-incompatibility from compile-time to runtime
 281 mar 23 22:23:17 <tristan>	theres plenty of stuff thats usually not accessed by client code
 282 mar 23 22:23:46 <pbor>	desrt: properties are introspectable
 283 mar 23 22:23:59 <desrt>	yes.  another reason to have them.
 284 mar 23 22:24:08 <desrt>	i'm not saying properties are useless
 285 mar 23 22:24:20 <desrt>	merely that i don't ever want to have to use them when writing 'normal code'
 286 mar 23 22:24:25 <kalikianatoli>	desrt, I added your name to #P12
 287 mar 23 22:24:34 <bratsche>	I think desrt was just questioning the idea of limiting an API to properties only.
 288 mar 23 22:25:28 <tristan>	I dont think anyone is really suggesting the API be property accessor/mutator only
 289 mar 23 22:25:43 <desrt>	that's what #p4 was doing, actually :p
 290 mar 23 22:25:52 <kalikianatoli>	tristan, in fact GtkCellRenderer is :-)
 291 mar 23 22:26:04 <desrt>	GtkCellRenderer is a special case that makes sense for properties...
 292 mar 23 22:27:09 <jjardon>	about the main topic: what about this plan: 2.20.x releses only to fix bugs and add accessors. Main features (xi...) in the master (gtk-2-90) branch
 293 mar 23 22:28:22 <jjardon>	if we want to have a GTK 3.0 release in September (with GNOME 3.0), I think is the only solution
 294 mar 23 22:28:38 <pbor>	jjardon: what do you gain by that plan? in the end 2.90 would 1) have new features 2) be incompat with 2.2X
 295 mar 23 22:28:45 <pbor>	so you may as well call it 3.0
 296 mar 23 22:29:12 <jjardon>	pbor, for me 2.90 = 3.0
 297 mar 23 22:29:24 <garnacho>	pbor, else we need a 2.22 release in between
 298 mar 23 22:29:37 <kalikianatoli>	jjardon, you misunderstood the plan then I'm afraid :-)
 299 mar 23 22:29:46 <kalikianatoli>	unless we decide to change the plan
 300 mar 23 22:29:55 <jjardon>	2.90 = development branch towards 3.0
 301 mar 23 22:29:55 <kalikianatoli>	which is perfectly debately
 302 mar 23 22:30:02 <jjardon>	ah, maybe :)
 303 mar 23 22:30:23 <kalikianatoli>	jjardon, 2.90 is the abi break, and 3.0 the first feature release
 304 mar 23 22:30:30 <kalikianatoli>	or was meant to be
 305 mar 23 22:30:44 <bratsche>	Is there enough interest in getting more eyes on extended-layout and davidz's resolution independence branches for 3.0 also?
 306 mar 23 22:30:56 <jjardon>	well, we can hace 3.0 = abi break + features
 307 mar 23 22:30:57 <garnacho>	bratsche, please
 308 mar 23 22:30:59 <garnacho>	:)
 309 mar 23 22:31:06 <jjardon>	bratsche, sure
 310 mar 23 22:31:41 <bratsche>	I'd like to pick up some slack on one of these as well, because I think it's asking too much of mclasen to have to be the only reviewer for everything.  It would be nice if more of us could help out in that position.
 311 mar 23 22:32:23 <garnacho>	I fully agree, will try to allocate some time for that
 312 mar 23 22:33:04 <bratsche>	Me and another guy on my team are trying to convince my manager to give me a full day a week to work on upstream stuff, but somehow I doubt it will happen.  But I'd still like to become more active again.
 313 mar 23 22:33:16 <jjardon>	we can use the reviewed flag, so mclasen only has to accept it
 314 mar 23 22:34:02 <jjardon>	well, reviewed, need-work flags
 315 mar 23 22:35:00 <kalikianatoli>	even accept is possible, provided we have capable reviewers :-)
 316 mar 23 22:35:14 <kalikianatoli>	the problem is that ri and layouting are far from trivial
 317 mar 23 22:35:33 <tristan>	if someone had the time to review patches full time then the load could be split across branches - with an extra review come merge time
 318 mar 23 22:36:03 <tristan>	that would work better than everyone & mclasen /me thinks
 319 mar 23 22:36:10 <tristan>	but I dont know who that would be ;-)
 320 mar 23 22:38:04 <kalikianatoli>	jjardon, is there a roadmap-like wiki page?
 321 mar 23 22:38:05 <jjardon>	tristan, I have nobody has "full time" :) . Instead, if any GTK+ contributor try a branch and have any comment or find a bug, It would be great if he post a comment in the bug report
 322 mar 23 22:38:33 <kalikianatoli>	it might be wroth trying to schedule people + features more strongly
 323 mar 23 22:38:38 <kalikianatoli>	*worth
 324 mar 23 22:38:46 <jjardon>	kalikianatoli, http://live.gnome.org/GTK%2B/Roadmap
 325 mar 23 22:39:01 <tristan>	jjardon, that doesnt solve the problem of stewardship
 326 mar 23 22:39:38 <tristan>	jjardon, even if the time wasnt full, an extra "go to" guy dedicated to an old and rusty stable branch will help
 327 mar 23 22:40:11 <kalikianatoli>	that pages doesn't have any names on it. nobody to poke or talk to
 328 mar 23 22:40:48 <jjardon>	kalikianatoli, see the bug reports linked
 329 mar 23 22:40:57 <kalikianatoli>	then again, the 3.0 page has and it didn't help that much...
 330 mar 23 22:41:33 <kalikianatoli>	jjardon, I mean the page, literally, thinking that it would be easier to kick some butts and get things going :-)
 331 mar 23 22:41:46 <kalikianatoli>	I don't know if it would really help or not
 332 mar 23 22:43:33 <jjardon>	ok, but again: what about to use gtk-2-90 branch as the master branch towards 3.0 ? Is somebody against?
 333 mar 23 22:43:50 <kalikianatoli>	depends on whether there is 2.22 or not
 334 mar 23 22:45:18 <jjardon>	I think that 2.22 is not needed (correct me if not), we already will add accessor in 2.20.x releases
 335 mar 23 22:45:22 <garnacho>	could its release cycle be really short-lived?
 336 mar 23 22:45:38 <garnacho>	jjardon, oh, we already agreed on that?
 337 mar 23 22:45:45 <kalikianatoli>	we didn't :-)
 338 mar 23 22:45:55 <kalikianatoli>	let's not stumble over our feet in the hurry
 339 mar 23 22:46:16 <jjardon>	garnacho, kalikianatoli mclasen and mith agree about that some time ago
 340 mar 23 22:46:32 <jjardon>	but was an informal IRC chat ;)
 341 mar 23 22:46:58 <kalikianatoli>	so two people secretly decide the fate of gtk? :-)
 342 mar 23 22:47:36 <garnacho>	ok, pros and cons
 343 mar 23 22:48:29 <garnacho>	if we release 2.22 in say 1 month, I guess there should be maintenance for both 2.20.x and 2.22.x until 3.0 is released
 344 mar 23 22:48:49 <garnacho>	otoh, it would be awkward to say 2.22.9 is compatible with 3.0
 345 mar 23 22:49:41 <kalikianatoli>	if the period is 1 month, I'd say it sounds unrealistic in terms of manpower
 346 mar 23 22:49:51 <garnacho>	kalikianatoli, "say" :P
 347 mar 23 22:50:25 <garnacho>	kalikianatoli, the time frame was completely fictional
 348 mar 23 22:50:39 <jjardon>	yeah, 2.20 was a very short cycle too, only to add accessors ...
 349 mar 23 22:50:52 <kalikianatoli>	garnacho, ah, ok
 350 mar 23 22:51:13 <kalikianatoli>	jjardon, it wasn't. the short cycle would have been 31st of december ;-)
 351 mar 23 22:51:24 *	Lethalman se ha marchado (Remote closed the connection)
 352 mar 23 22:51:34 <kalikianatoli>	at least that was what we considered short cycled back then
 353 mar 23 22:52:03 <kalikianatoli>	but we are off the schedule anyway, so what
 354 mar 23 22:52:34 <garnacho>	kalikianatoli, if 2.22 only meant finishing sealing, how much time do you think could be needed?
 355 mar 23 22:53:51 <kalikianatoli>	we expect to get at least xi2 and csw for windows in that, right?
 356 mar 23 22:53:58 <kalikianatoli>	so we need to take that into account
 357 mar 23 22:54:16 <garnacho>	aha, right
 358 mar 23 22:55:13 <jjardon>	about csw you should ask bratsche, and I think that can't be done in a shot cycle because external issues
 359 mar 23 22:55:21 <kalikianatoli>	and then perhaps client-side decos and diagnostic mode
 360 mar 23 22:55:32 <jjardon>	csd, I mean
 361 mar 23 22:55:45 <kalikianatoli>	albeit those are not strictly required, but consume time if we do them
 362 mar 23 22:56:22 <kalikianatoli>	so if bratsche for instance goes to fix csw on windows, he can't do csd at the same time
 363 mar 23 22:56:25 <bratsche>	I don't think csd on Win32 is going to be really a big deal.  It really doesn't do anything platform-specific.
 364 mar 23 22:56:37 <kalikianatoli>	csw on windows :-)
 365 mar 23 22:57:07 <kalikianatoli>	wasn't that what you mentioned earlier?
 366 mar 23 22:57:58 <bratsche>	I guess now that I think about it, I don't know what the issue was.  pbor was mentioning some missing accessors stuff but now I think he was saying something else.
 367 mar 23 22:58:13 <garnacho>	also the xi2 branch is broken win32-wise, putting it back to an usable state shouldn't take that much effort though
 368 mar 23 22:58:52 <kalikianatoli>	bratsche, I think pbor was referring to windows being partially broken and that you can't use new accessors if it doesn't run on windows
 369 mar 23 22:58:53 <garnacho>	it's in my todo list if nobody arrives before
 370 mar 23 22:59:03 <bratsche>	Honestly I can't commit to working on the Win32 engine at the moment, I'm sad to say.  I'm doing a fraction of the gtk+ hacking on Linux right now that I thought I would be doing this year, and I can't commit to working on stuff outside work right now for personal reasons.
 371 mar 23 22:59:30 <bratsche>	kalikianatoli: Yeah, so I think I misunderstood him then.  I don't think I can commit to fixing that right now.
 372 mar 23 23:00:02 <kalikianatoli>	Ok, fair enough.
 373 mar 23 23:00:18 <bratsche>	So until my personal reasons change or until I change jobs, I just don't want to promise stuff I can't commit to now.
 374 mar 23 23:01:07 <bratsche>	Sorry. :(
 375 mar 23 23:01:58 <kalikianatoli>	so the must-have for 2.22 are xi2, csd and finding someone who looks into fixing up win32
 376 mar 23 23:02:42 <jjardon>	What are the real problems to have latest 2.20.x release compatible with 3.0 ? Can't we add accessors in the 2.20.x releases?
 377 mar 23 23:03:20 <kalikianatoli>	jjardon, if possible both should have the same features
 378 mar 23 23:03:33 <kalikianatoli>	and you wouldn't add the above to a stable relase
 379 mar 23 23:03:36 <kalikianatoli>	*release
 380 mar 23 23:03:59 <kalikianatoli>	jjardon, so that you can test your application, while porting, with old and new gtk
 381 mar 23 23:04:25 <kalikianatoli>	this is not possible if the breaking release has new features
 382 mar 23 23:05:55 <jjardon>	ok, what about a fast 3.0 release (It's mostly done) and a  3.2 relsease with new features?
 383 mar 23 23:05:58 <garnacho>	kalikianatoli, the new release could have new features, but would start off with deprecated api
 384 mar 23 23:06:04 <garnacho>	which I agree is not ideal
 385 mar 23 23:06:14 <bratsche>	jjardon: Not really a great idea imo.
 386 mar 23 23:06:46 <kalikianatoli>	garnacho, if it has any new functions, you can't test it with the old gtk anymore
 387 mar 23 23:06:54 <kalikianatoli>	in terms of an equal feature set
 388 mar 23 23:07:08 <bratsche>	jjardon: And part of it is just psychology I think.. a lot of people kind of raised a lot of shit when OpenGL 3.0 came out without really having real features, and choosing to add the features in 3.x.
 389 mar 23 23:07:21 <garnacho>	kalikianatoli, you couldn't test the new features yes
 390 mar 23 23:07:46 <kalikianatoli>	garnacho, so imagine xi2 - hypothetically - breaks in ways that work differently in 2.20 and you don't know what the problem is
 391 mar 23 23:08:02 <kalikianatoli>	how would you verify if you ported successfully?
 392 mar 23 23:08:43 <jjardon>	kalikianatoli, port = use accessors ?
 393 mar 23 23:08:50 <garnacho>	bisecting painfully :)
 394 mar 23 23:09:25 <kalikianatoli>	yes, port = accessors, no structs, different pkg-config file and so on
 395 mar 23 23:09:54 <jjardon>	bratsche, agree, I think that is possible a 3.0 release with features like xi or csd on it
 396 mar 23 23:10:25 <kalikianatoli>	jjardon, that's exactly why we planned 2.90
 397 mar 23 23:10:31 <bratsche>	Yup.
 398 mar 23 23:11:36 <kalikianatoli>	I suspect the reason against 2.22 is that we won't manage to finish up sealing just before any feature additions
 399 mar 23 23:11:59 <kalikianatoli>	So I guess I half-way give in in practical considerations
 400 mar 23 23:12:53 <kalikianatoli>	Unless 2.22 could be a branch
 401 mar 23 23:13:03 <kalikianatoli>	So 2.22 instead of 2.20+api
 402 mar 23 23:13:16 <kalikianatoli>	Would that make any sense?
 403 mar 23 23:14:21 <garnacho>	kalikianatoli, I didn't get it, sorry :)
 404 mar 23 23:14:49 <garnacho>	as opposed to have a 2.22 in master? what would we gain?
 405 mar 23 23:17:21 <kalikianatoli>	So that 2.22 would cherry-pick changes as needed, ie. missing accessors, deprecations
 406 mar 23 23:17:38 <kalikianatoli>	But not completely new features like csd
 407 mar 23 23:17:50 <kalikianatoli>	And no new functions for xi2
 408 mar 23 23:18:13 <jjardon>	what about use 2.20 instead 2.22 for that
 409 mar 23 23:18:28 <jjardon>	only as a special case
 410 mar 23 23:18:49 <garnacho>	kalikianatoli, oh, so you mean as an early start?
 411 mar 23 23:18:56 <jjardon>	2.20 + accessors, and master = 2.90 = normal development branch towards 3.0. So latest 2.20.x release can be compatible with GTK +3
 412 mar 23 23:20:20 <kalikianatoli>	garnacho, the main issue are remaining functions and deprecations, right? so we need to get those done somehow
 413 mar 23 23:20:42 <garnacho>	jjardon, so we're mostly talking about postponing new features after 2.90 and ditching 2.22, right?
 414 mar 23 23:20:47 <garnacho>	kalikianatoli, indeed
 415 mar 23 23:22:06 <kalikianatoli>	jjardon, adding anything new to 2.20 disturbs the assumption that it is "stable"
 416 mar 23 23:22:43 <jjardon>	kalikianatoli, very few accessor are needed currently
 417 mar 23 23:23:16 <jjardon>	that is because I said as "special case", to push the GTK+ 3 development
 418 mar 23 23:23:40 <kalikianatoli>	it is easily around 40 or more functions we still need
 419 mar 23 23:23:47 <kalikianatoli>	not sure if that's very few
 420 mar 23 23:23:54 *	chpe se ha marchado (Weg)
 421 mar 23 23:24:18 <jjardon>	40? where are the bug reports? ;)
 422 mar 23 23:24:50 <jjardon>	I didn't find the need of these functions while porting epiphany, glade3, gedit ...
 423 mar 23 23:25:00 <garnacho>	if we take into account Gtk(RC)Style, that may be reached easily
 424 mar 23 23:25:20 <kalikianatoli>	jjardon, https://bugzilla.gnome.org/show_bug.cgi?id=592580
 425 mar 23 23:25:26 <kalikianatoli>	gdk as one example
 426 mar 23 23:25:52 <jjardon>	ah, ok. GDK was still not sealed
 427 mar 23 23:27:37 <jjardon>	IMHO I still think that is less work to use 2.20 to add new accessor, and use gtk-2-90 as master. And we don't have a lot of hands. 
 428 mar 23 23:29:07 <jjardon>	garnacho, I've just rebased the gtk-2-90 branch, could you take a look to the failing tests? ;)
 429 mar 23 23:30:03 <kalikianatoli>	jjardon, hence my idea that 2.22 could be a branch where we cherry-pick those accessors
 430 mar 23 23:30:11 <kalikianatoli>	to make it less work
 431 mar 23 23:30:41 <kalikianatoli>	so it would be a sort-of light release with new accessors
 432 mar 23 23:31:04 <jjardon>	kalikianatoli, and keep gtk-2-90 as master?
 433 mar 23 23:31:48 <jjardon>	I think that could be a good idea, yes
 434 mar 23 23:32:12 <kalikianatoli>	yes
 435 mar 23 23:33:52 <jjardon>	Do we agree, then? garnacho ?
 436 mar 23 23:39:38 <jjardon>	kalikianatoli, Could you rename the current master to gtk-2-22 and gtk-2-90 to master ?
 437 mar 23 23:39:50 <jjardon>	Or Do you prefer to talk with mclasen first?
 438 mar 23 23:41:09 <kalikianatoli>	I'd leave it to mclasen when to switch master
 439 mar 23 23:41:29 <kalikianatoli>	Since there usually are a few small fixes for the stable release
 440 mar 23 23:41:42 <kalikianatoli>	So he probably wants to wait a cuple of days
 441 mar 23 23:44:09 <jjardon>	kalikianatoli, we can create 2-20 branch now too, so  problem solved ;)
 442 mar 23 23:44:57 <kalikianatoli>	for what I want,  we 'could' switch. I'm just saying I wouldn't do this over mclasen's head
 443 mar 23 23:45:09 <kalikianatoli>	and he usually wants to wait some time
 444 mar 23 23:46:33 <kalikianatoli>	jjardon, maybe the best idea is to write a short email to the list, where it ends in "switch 2-90 to master as soon as mclasen decides"
 445 mar 23 23:46:41 <kalikianatoli>	something like that
 446 mar 23 23:47:01 *	pachi (~pachi@84.76.212.152) ha abandonado #gtk-devel
 447 mar 23 23:47:16 <garnacho>	jjardon, kalikianatoli, sorry, sounds good to me :)
 448 mar 23 23:49:24 <jjardon>	kalikianatoli, yeah, good idea. Maybe more people can express their opinnion ;)