mar 23 21:01:22 * tristan (~tristan@74.210.0.150) ha entrado en #gtk-devel mar 23 21:01:34 tristan, just in time ;) mar 23 21:03:02 :) mar 23 21:03:54 garnacho, As you are have the first items in the agenda, Do you have some plan to seal GtkStyle to take a look? mar 23 21:04:45 well, I'm actually working on deprecating it :) mar 23 21:04:50 but yes, that's my plan mar 23 21:08:27 * mclasen (~mclasen@c-98-229-128-128.hsd1.ma.comcast.net) ha entrado en #gtk-devel mar 23 21:09:24 * Company (~Company@e176114193.adsl.alicedsl.de) ha entrado en #gtk-devel mar 23 21:09:38 jjardon, oh, you mean as in some link and such? mar 23 21:09:50 garnacho, yeah ;) mar 23 21:10:08 * mclasen stumbles in mar 23 21:10:39 who leads ? mar 23 21:10:55 seems that ebassi is not available mar 23 21:11:20 * mclasen has roughly an hour mar 23 21:11:48 * mclasen did a 2.20 release today mar 23 21:12:26 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 mar 23 21:12:49 mclasen, really good news, congrats mar 23 21:14:12 yeah, congrants everyone for the new release mar 23 21:14:44 stable glib release to follow later in the week mar 23 21:16:34 * pbor (~paolo@host32-21-dynamic.45-79-r.retail.telecomitalia.it) ha entrado en #gtk-devel mar 23 21:16:36 should we just follow the agend ? mar 23 21:16:38 a mar 23 21:17:21 if you have little time, we can discuss the main topics mar 23 21:17:31 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. mar 23 21:18:21 * mclasen thinks it is 3.0 mar 23 21:18:25 other opinions ? mar 23 21:18:45 * federico (~federico@189.129.80.232) ha entrado en #gtk-devel mar 23 21:19:07 * federico looks GTK_DIRECTION_LEFT mar 23 21:19:11 * federico looks GTK_DIRECTION_RIGHT mar 23 21:19:25 mclasen: was the plan to have 2.90 (=2.2X without the old cruft) abandoned? mar 23 21:19:42 pbor: well, nobody pushed it actively mar 23 21:19:49 ok mar 23 21:19:52 I would have hoped for the 3.0 crowd to do so mar 23 21:19:52 I've rebased the gtk+2-90 branch recently, but It needs to be rebased again, I think mar 23 21:19:58 but that was not the case... mar 23 21:20:10 so we should probably figure out if someone can do that on short notice mar 23 21:20:32 jjardon: is the 2.90 branch in sync with master ? mar 23 21:20:59 yeah, I can rebase it today if you want mar 23 21:21:14 would be cool mar 23 21:21:17 mclasen, btw, what would be the policy for deprecations? mar 23 21:21:26 in this cycle I mean mar 23 21:21:27 the main problem is that some test from testgtk are still using deprecated api mar 23 21:21:33 and build fails mar 23 21:21:49 jjardon, need a hand with that? mar 23 21:22:03 that would probably need fixing before a release... mar 23 21:22:03 garnacho, would be cool :) mar 23 21:22:05 * aruiz (~aruiz@94-192-234-22.zone6.bethere.co.uk) ha entrado en #gtk-devel mar 23 21:22:14 aruiz, hey ;) mar 23 21:22:25 hey jjardon mar 23 21:22:29 sorry guys mar 23 21:22:35 :) mar 23 21:23:35 garnacho: I guess we still add deprecations as needed - I assume you ask because the xi2 stuff obsoletes a bunch of gdk api ? mar 23 21:25:25 mclasen, yes :), was mostly curious/amused about starting 3.0 with deprecated stuff mar 23 21:25:44 but there's no better option mar 23 21:26:18 probably not mar 23 21:27:26 what is the next stable glib release? mar 23 21:27:38 * desrt created a 2.26 milestone today without really thinking about it... mar 23 21:28:25 desrt, I think there is not plans for Glib 3.0, if you are asking that mar 23 21:28:33 ok. cool. mar 23 21:28:52 Hey guys. mar 23 21:28:59 woot for the new release! mar 23 21:29:11 yup mar 23 21:29:23 garnacho, we can remove the deprecated stuff in the 2-90 branch, instead deprecated them mar 23 21:30:09 practical question: once we have a 2.90 release done, do we merge 2.90 to master, and continue there ? mar 23 21:30:34 so I just reopened the treeview-focus can of worms mar 23 21:31:07 mclasen: wouldn't 2.90 be released from master and then branched off for stable updates in the usual way? mar 23 21:31:08 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 mar 23 21:32:43 federico: Can I ping you before you go about a patch to peek at for filechooser? mar 23 21:32:51 garnacho, as mclasen said before, I think there won't be a clean transition anyway mar 23 21:33:02 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 mar 23 21:33:09 we need to continue the sealing business in 2.x, anyway mar 23 21:33:23 so I'd just go with releasing 3.0 mar 23 21:33:30 I think we had a rough agreement that we need to continue to add missing accessors in 2.x mar 23 21:33:43 bratsche: sure mar 23 21:34:09 mclasen, I think the needed accessor are really corner cases mar 23 21:34:51 The main problem is ->need_im_reset, It affects some applications mar 23 21:35:17 so if we can deprecate during 2.90, does that mean I can deprecate GdkRegion? mar 23 21:35:29 jjardon: yeah, that needs to be finished mar 23 21:35:35 as one of the user of ->need_im_reset I can assure that's really the least of the problems mar 23 21:35:56 Company: do we have a replacement, or...? mar 23 21:35:56 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. mar 23 21:36:02 * kalikianatoli (~kalikiana@xdsl-89-0-129-64.netcologne.de) ha entrado en #gtk-devel mar 23 21:36:03 desrt: cairo_region_t mar 23 21:36:07 ah. mar 23 21:36:15 it got added over a year ago but i never noticed mar 23 21:36:28 as an app developer the biggest blocker right now is that switching to 3.0 means wave goodbye to the win32 port mar 23 21:37:09 pbor, really? mar 23 21:37:37 bratsche: old accessors == struct fields, but no, I don't mar 23 21:37:54 but that would be a good topic for a 2.x -> 3 porting guide mar 23 21:37:59 which is something we need to start, I guess mar 23 21:38:03 Well, the Win32 port has fallen into a bit of disrepair since I stopped working on it I'm afraid. :/ mar 23 21:38:26 Company, I think that remove GdkRegion makes sense mar 23 21:38:43 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 mar 23 21:38:59 :/ mar 23 21:39:45 * bag se ha marchado (Ex-Chat) mar 23 21:39:52 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 ? mar 23 21:39:53 jjardon: yeah, i'm all for it mar 23 21:39:57 is there some cairo rectangle type too? mar 23 21:40:07 jjardon: i just like to get an OK before i port all of gtk mar 23 21:40:15 desrt: multiple ;) mar 23 21:40:26 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. :( mar 23 21:40:37 it seems like maybe a reasonable goal would be to kill off all the 'gdk_cairo' functions mar 23 21:40:38 mclasen, I'm afraid I'm not helping there, the win32 backend in the xi2 branch is still undone :/ mar 23 21:41:12 desrt: you need gdk_cairo_create() mar 23 21:41:13 desrt, how would you replace gdk_cairo_create? mar 23 21:41:15 garnacho: what about os x ? mar 23 21:41:20 other than that one :p mar 23 21:41:30 bratsche, I can have a look into the engine mar 23 21:41:33 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. mar 23 21:41:38 although arguably that should be called gdk_drawable_create_cairo() or something mar 23 21:41:42 desrt: i would want to keep set_source_pixbuf(), but i intend to change it mar 23 21:41:51 mclasen, kris has been working on it, I've already got a pile of patches to have a look at mar 23 21:41:57 bratsche, but I actually think I'm gonna need help from someone who understands the backend mar 23 21:42:05 desrt: whats wrong with those 4-5 functions ? mar 23 21:42:06 desrt: once my support for unmultiplied ARGB lands mar 23 21:42:10 Company, maybe you can do it in the 2-90 branch mar 23 21:42:20 mclasen: if we're moving to cairo-based regions/rectangles.... mar 23 21:42:32 aruiz: That's unfortunately basically me and Tor at this point I think. mar 23 21:42:35 there's a couple of them gone mar 23 21:42:41 i guess we still have gdkcolor kicking around mar 23 21:42:41 mclasen, he was also aiming to provide support for the multitouch trackpads, btw mar 23 21:42:42 jjardon: yeah, i'll branch off it and have a go mar 23 21:43:02 desrt: they're slightly different mar 23 21:43:03 Company: any opinions on GdkColor? mar 23 21:43:09 desrt, not in gtk-2-90 mar 23 21:43:12 Company: so, what do we gain by moving to cairo regions ? and how much further deprecation churn are we willing to take ? mar 23 21:43:40 desrt, rather typedef than replacing for now. we can't remove any more cruft anyway unless we slip in another release mar 23 21:43:40 mclasen: we lose the need to do conversions between the region types mar 23 21:43:54 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 mar 23 21:44:04 mclasen: cairo might want to add API to get change regions etc and it'd be way easier to expose mar 23 21:44:37 Company: of course, internally, we still have to deal with Xlib regions mar 23 21:45:15 mclasen: yeah, we'd just do cairo_region_foo() instead of gdk_region_foo() mar 23 21:45:40 If the next version will be 3.0, how about to branch 2.20 and use gtk-2-90 as a master branch? mar 23 21:46:00 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. mar 23 21:46:29 bratsche, I can try to learn how the backend works perhaps? I certainly need your support mar 23 21:47:02 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. mar 23 21:47:11 garnacho: does your xi2 work apply cleanly against 2.90 ? or is it against master ? mar 23 21:47:32 mclasen, it's against master mar 23 21:47:45 if needed my next rebase could be against that mar 23 21:47:52 gtk-2-90 is currently broke mar 23 21:48:40 right mar 23 21:48:47 as said before, some tests from testgtk need to be ported to new api mar 23 21:49:05 * mclasen will give 2.90 a try later tonight mar 23 21:49:11 * kalikianatoli hopes the gdk sealing can get in soon mar 23 21:49:41 I'll rebase 2-90 against master today mar 23 21:50:06 Also, we should decide between a or b here: http://live.gnome.org/GTK%2B/3.0/Tasks#Q2 mar 23 21:50:46 to start the work of remove all structure fields mar 23 21:50:52 * pbor thinks b is best mar 23 21:51:03 b is slow.... mar 23 21:51:22 if its slow we should not have done the sealing in the first place mar 23 21:51:45 the sealing was sold on the premise that the cost is irrelevant mar 23 21:51:52 well. PLT jumps and dynamic symbol lookups are slow too mar 23 21:51:57 * kalikianatoli favours b with exceptions if necessary mar 23 21:52:01 desrt, we can also have private.h headers mar 23 21:52:21 I think is better b too mar 23 21:52:57 i picture a future... mar 23 21:53:05 great, we can also use ->priv instead GET_PRIVATE(), but this can be done later mar 23 21:53:26 b keeps people honest so that when someone needs to extend a class outside gtk, all that is needed is there mar 23 21:53:30 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 mar 23 21:54:11 desrt: would that be you ? mar 23 21:54:35 mclasen: i'm personally interested in reducing the level of hacktastic features in our build system :p mar 23 21:54:45 hah mar 23 21:54:53 clang -O4 ftw! mar 23 21:54:56 doing this would be like galias pain all over again mar 23 21:55:16 desrt, like gmarshaller? :-D mar 23 21:55:18 -O4 promises to inline across file boundaries mar 23 21:55:33 yes. WPO would be nice. mar 23 21:55:47 i guess eventually we'll get there mar 23 21:57:01 So, what about use 2-90 as master branch? mar 23 21:57:56 * mclasen would rather continue with master + stable mar 23 21:58:15 of course, we can only merge 2.90 after it builds and works... mar 23 21:58:19 we'd rather have 2.22, or not? mar 23 21:58:28 since we still need a number of accessors mar 23 21:58:56 kalikanatoli: I guess thats a fair point mar 23 21:59:05 * federico se ha marchado (Ping timeout: 600 seconds) mar 23 21:59:10 to remove and create a new branch: git push :gtk-2-90 && git push gtk-2-90 ? mar 23 21:59:15 as sad as it is, 2.90 is supposed to be less painful by not having new api mar 23 21:59:23 so we need 2.22 mar 23 21:59:50 what about this plan: mar 23 21:59:55 no 2.90 release mar 23 22:00:06 add accessors during 2.20.X mar 23 22:00:19 when all accessors are there tag it 2.22 mar 23 22:00:25 kalikianatoli: not having new api conflicts with the desire to merge xi2 and a bunch of other stuff... mar 23 22:01:25 mclasen, that would go into 2.22, right? so it would be fine mar 23 22:01:44 kalikianatoli: assuming there is a 2.22... mar 23 22:01:47 Also, xi2 would be a good excuse to encourage people to use GTK 3.0 ... mar 23 22:02:20 mclasen, I assume there is because otherwise we simply can't keep the plan :-) mar 23 22:02:43 which was that last abi compat has the same api as 2.90 mar 23 22:03:24 the thing with 'the plan' is that most of the people who wanted to work on it have largely disappeared... mar 23 22:03:38 common-sense question: maybe i missed soemthing mar 23 22:03:45 are we going to continue to support subclass-by-containment? mar 23 22:03:55 gtk-2-90 rebased against master now mar 23 22:04:05 ie: GtkWindow is a GtkBin so the first member of the GtkWindow structure is GtkBin? mar 23 22:04:19 and we are struggling to keep things going with insufficient resources... mar 23 22:05:00 desrt: how could we not ? mar 23 22:05:08 mclasen: that's exactly my point mar 23 22:05:18 doesn't that make it impossible to move the structure definitions to .c files? mar 23 22:05:29 And as I sadi before, the remaining accessors are corner cases, the only important is ->need_im_context mar 23 22:05:38 since you need to have a complete type in order to include it as a requirement for subclassing mar 23 22:05:56 desrt: I assume the private structs will be in C files, and the headers will just have empty public structs mar 23 22:06:19 containing just a priv pointer? mar 23 22:06:20 desrt: widget->priv->window mar 23 22:06:41 desrt, I was thinking something in the line of #define G_DECLARE_OBJECT(_n_, _type_) struct _n_ { _type_ parent_instance; gpointer priv }; mar 23 22:07:02 desrt: yeah, look at GtkStatusIcon, eg mar 23 22:07:04 structs will be struct { gobjectclass; priv; } afair mar 23 22:07:17 ok. so this is a non-question, then mar 23 22:07:27 it's not about moving the location of the definition of any structures mar 23 22:07:33 desrt, see for example: http://git.gnome.org/browse/gtk+/commit/?h=gtk-2-90&id=740c05ff56de32d6e7802e0a369e36b6bcdb9faa mar 23 22:07:37 but rather about moving everything out of the public structure and into ->priv-> mar 23 22:08:13 exactly mar 23 22:08:15 in that case, it's obvious that the private structure should only be in the .c file mar 23 22:08:32 we've been doing it that way forever mar 23 22:08:46 the a/b choice makes it sound like we're hiding the instance structure itself :p mar 23 22:08:55 desrt, the non-obvious cases are crazy interdependencies of eg. gtkwidget and gtkwindow mar 23 22:09:24 where we can't keep them from each other entirely mar 23 22:10:02 pbor, that was the plan for 2.20 ... mar 23 22:10:12 * mclasen drops off mar 23 22:10:20 discuss amongst yourselves... :-) mar 23 22:10:25 * mclasen se ha marchado (There must be some way out of here.) mar 23 22:10:59 so we agree on "b. Move object structures to the local C file", right? mar 23 22:11:07 no... mar 23 22:11:22 rather "c. Do what we already do, but more of it." :p mar 23 22:11:38 we're not moving any structures mar 23 22:11:51 rather, shifting items from one structure to another mar 23 22:12:19 ah, yes, it should be "Move struct members into private structure" mar 23 22:12:33 yes. and the private structure is very obviously private to the .c file mar 23 22:12:50 also, #P2 is done mar 23 22:13:02 class private data got merged into glib this past unstable release mar 23 22:13:12 desrt: mmm can't you just have typedef GtkFoo _GtkFoo in the .h and the real struct in the .c? mar 23 22:13:15 it's there as Done :-) mar 23 22:13:19 pbor: no. mar 23 22:13:38 ah, the paragraph is out of sync with the table mar 23 22:13:39 kalikianatoli: i see #P2 Progress "Not yet started." mar 23 22:13:45 * kalikianatoli goes to fix mar 23 22:13:49 pbor: we subclass by inclusion mar 23 22:13:53 if you try to say mar 23 22:13:56 struct _GtkWindow { mar 23 22:13:59 GtkWidget parent_instance; mar 23 22:14:00 ... mar 23 22:14:00 } mar 23 22:14:07 that obviously fails unless GtkWidget is a complete type mar 23 22:14:20 ok mar 23 22:15:07 on topic of #P4, is that really true? mar 23 22:15:17 jjardon, are you editing the page atm? mar 23 22:15:32 just finished now mar 23 22:15:37 i was under the impression that for every property we sealed/moved-to-private we would have new accessor functions as appropriate mar 23 22:15:48 to corrent "move strcut member" mar 23 22:15:50 ie: g_object_get use will not increase -- you'll use the accessor function directly mar 23 22:16:23 desrt, "to simply access fields" refers to struct members mar 23 22:16:33 you won't be able to use them as they're gone mar 23 22:16:39 kalikianatoli: i know mar 23 22:16:47 kalikianatoli: what i'm saying is that this does not imply increased use of gobject properties mar 23 22:17:13 ah, right. mar 23 22:17:24 therefor #P4 seems slightly ... wrong mar 23 22:18:35 #P12 looks very positive. i already tried this for libglib and i had a lot of success mar 23 22:18:47 talked to mmeeks about it, too. he thinks that it's the right thing to do. mar 23 22:18:56 desrt, I think P4 mostly "we need better convenience api for getting a gobject property" badly worded :) mar 23 22:18:58 i'll gladly take responsibility ofr that task mar 23 22:19:15 garnacho: the justification given for the "need" is completely wrong, though mar 23 22:19:42 right mar 23 22:19:51 i'd argue there's no need at all mar 23 22:20:08 I changed it to say "accessor functions and GObject properties" mar 23 22:20:12 as far as i'm concerned, gobject properties have no place in normal human-written code mar 23 22:20:36 there are a few use cases where only properties exist mar 23 22:20:43 * Company se ha marchado (Remote closed the connection) mar 23 22:20:47 perhaps we should add accessors :p mar 23 22:20:57 think of GtkSettings mar 23 22:21:06 there are api there are purely property based mar 23 22:21:09 GtkTextTag mar 23 22:21:22 properties are annoying to use and they're also slow..... mar 23 22:21:28 so why? mar 23 22:21:53 because you can read and write them in loops, and create config files mar 23 22:22:12 right. and use them for object construction and also for things like GtkCellRenderer mar 23 22:22:17 exactly mar 23 22:22:19 but i mean, why should we have APIs based solely upon them? mar 23 22:22:34 as a programmer, i never want to have to type g_object_set() unless i'm doing something 'special' mar 23 22:22:38 because you want an api forward compatible mar 23 22:23:03 desrt, I think the issue is more, when GTK+ needs an api, we add it then but usually not before mar 23 22:23:12 so that you can add new properties without adding a else if (isbar) foo_set_bar mar 23 22:23:13 pbor: it just shifts the forward-incompatibility from compile-time to runtime mar 23 22:23:17 theres plenty of stuff thats usually not accessed by client code mar 23 22:23:46 desrt: properties are introspectable mar 23 22:23:59 yes. another reason to have them. mar 23 22:24:08 i'm not saying properties are useless mar 23 22:24:20 merely that i don't ever want to have to use them when writing 'normal code' mar 23 22:24:25 desrt, I added your name to #P12 mar 23 22:24:34 I think desrt was just questioning the idea of limiting an API to properties only. mar 23 22:25:28 I dont think anyone is really suggesting the API be property accessor/mutator only mar 23 22:25:43 that's what #p4 was doing, actually :p mar 23 22:25:52 tristan, in fact GtkCellRenderer is :-) mar 23 22:26:04 GtkCellRenderer is a special case that makes sense for properties... mar 23 22:27:09 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 mar 23 22:28:22 if we want to have a GTK 3.0 release in September (with GNOME 3.0), I think is the only solution mar 23 22:28:38 jjardon: what do you gain by that plan? in the end 2.90 would 1) have new features 2) be incompat with 2.2X mar 23 22:28:45 so you may as well call it 3.0 mar 23 22:29:12 pbor, for me 2.90 = 3.0 mar 23 22:29:24 pbor, else we need a 2.22 release in between mar 23 22:29:37 jjardon, you misunderstood the plan then I'm afraid :-) mar 23 22:29:46 unless we decide to change the plan mar 23 22:29:55 2.90 = development branch towards 3.0 mar 23 22:29:55 which is perfectly debately mar 23 22:30:02 ah, maybe :) mar 23 22:30:23 jjardon, 2.90 is the abi break, and 3.0 the first feature release mar 23 22:30:30 or was meant to be mar 23 22:30:44 Is there enough interest in getting more eyes on extended-layout and davidz's resolution independence branches for 3.0 also? mar 23 22:30:56 well, we can hace 3.0 = abi break + features mar 23 22:30:57 bratsche, please mar 23 22:30:59 :) mar 23 22:31:06 bratsche, sure mar 23 22:31:41 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. mar 23 22:32:23 I fully agree, will try to allocate some time for that mar 23 22:33:04 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. mar 23 22:33:16 we can use the reviewed flag, so mclasen only has to accept it mar 23 22:34:02 well, reviewed, need-work flags mar 23 22:35:00 even accept is possible, provided we have capable reviewers :-) mar 23 22:35:14 the problem is that ri and layouting are far from trivial mar 23 22:35:33 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 mar 23 22:36:03 that would work better than everyone & mclasen /me thinks mar 23 22:36:10 but I dont know who that would be ;-) mar 23 22:38:04 jjardon, is there a roadmap-like wiki page? mar 23 22:38:05 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 mar 23 22:38:33 it might be wroth trying to schedule people + features more strongly mar 23 22:38:38 *worth mar 23 22:38:46 kalikianatoli, http://live.gnome.org/GTK%2B/Roadmap mar 23 22:39:01 jjardon, that doesnt solve the problem of stewardship mar 23 22:39:38 jjardon, even if the time wasnt full, an extra "go to" guy dedicated to an old and rusty stable branch will help mar 23 22:40:11 that pages doesn't have any names on it. nobody to poke or talk to mar 23 22:40:48 kalikianatoli, see the bug reports linked mar 23 22:40:57 then again, the 3.0 page has and it didn't help that much... mar 23 22:41:33 jjardon, I mean the page, literally, thinking that it would be easier to kick some butts and get things going :-) mar 23 22:41:46 I don't know if it would really help or not mar 23 22:43:33 ok, but again: what about to use gtk-2-90 branch as the master branch towards 3.0 ? Is somebody against? mar 23 22:43:50 depends on whether there is 2.22 or not mar 23 22:45:18 I think that 2.22 is not needed (correct me if not), we already will add accessor in 2.20.x releases mar 23 22:45:22 could its release cycle be really short-lived? mar 23 22:45:38 jjardon, oh, we already agreed on that? mar 23 22:45:45 we didn't :-) mar 23 22:45:55 let's not stumble over our feet in the hurry mar 23 22:46:16 garnacho, kalikianatoli mclasen and mith agree about that some time ago mar 23 22:46:32 but was an informal IRC chat ;) mar 23 22:46:58 so two people secretly decide the fate of gtk? :-) mar 23 22:47:36 ok, pros and cons mar 23 22:48:29 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 mar 23 22:48:49 otoh, it would be awkward to say 2.22.9 is compatible with 3.0 mar 23 22:49:41 if the period is 1 month, I'd say it sounds unrealistic in terms of manpower mar 23 22:49:51 kalikianatoli, "say" :P mar 23 22:50:25 kalikianatoli, the time frame was completely fictional mar 23 22:50:39 yeah, 2.20 was a very short cycle too, only to add accessors ... mar 23 22:50:52 garnacho, ah, ok mar 23 22:51:13 jjardon, it wasn't. the short cycle would have been 31st of december ;-) mar 23 22:51:24 * Lethalman se ha marchado (Remote closed the connection) mar 23 22:51:34 at least that was what we considered short cycled back then mar 23 22:52:03 but we are off the schedule anyway, so what mar 23 22:52:34 kalikianatoli, if 2.22 only meant finishing sealing, how much time do you think could be needed? mar 23 22:53:51 we expect to get at least xi2 and csw for windows in that, right? mar 23 22:53:58 so we need to take that into account mar 23 22:54:16 aha, right mar 23 22:55:13 about csw you should ask bratsche, and I think that can't be done in a shot cycle because external issues mar 23 22:55:21 and then perhaps client-side decos and diagnostic mode mar 23 22:55:32 csd, I mean mar 23 22:55:45 albeit those are not strictly required, but consume time if we do them mar 23 22:56:22 so if bratsche for instance goes to fix csw on windows, he can't do csd at the same time mar 23 22:56:25 I don't think csd on Win32 is going to be really a big deal. It really doesn't do anything platform-specific. mar 23 22:56:37 csw on windows :-) mar 23 22:57:07 wasn't that what you mentioned earlier? mar 23 22:57:58 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. mar 23 22:58:13 also the xi2 branch is broken win32-wise, putting it back to an usable state shouldn't take that much effort though mar 23 22:58:52 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 mar 23 22:58:53 it's in my todo list if nobody arrives before mar 23 22:59:03 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. mar 23 22:59:30 kalikianatoli: Yeah, so I think I misunderstood him then. I don't think I can commit to fixing that right now. mar 23 23:00:02 Ok, fair enough. mar 23 23:00:18 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. mar 23 23:01:07 Sorry. :( mar 23 23:01:58 so the must-have for 2.22 are xi2, csd and finding someone who looks into fixing up win32 mar 23 23:02:42 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? mar 23 23:03:20 jjardon, if possible both should have the same features mar 23 23:03:33 and you wouldn't add the above to a stable relase mar 23 23:03:36 *release mar 23 23:03:59 jjardon, so that you can test your application, while porting, with old and new gtk mar 23 23:04:25 this is not possible if the breaking release has new features mar 23 23:05:55 ok, what about a fast 3.0 release (It's mostly done) and a 3.2 relsease with new features? mar 23 23:05:58 kalikianatoli, the new release could have new features, but would start off with deprecated api mar 23 23:06:04 which I agree is not ideal mar 23 23:06:14 jjardon: Not really a great idea imo. mar 23 23:06:46 garnacho, if it has any new functions, you can't test it with the old gtk anymore mar 23 23:06:54 in terms of an equal feature set mar 23 23:07:08 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. mar 23 23:07:21 kalikianatoli, you couldn't test the new features yes mar 23 23:07:46 garnacho, so imagine xi2 - hypothetically - breaks in ways that work differently in 2.20 and you don't know what the problem is mar 23 23:08:02 how would you verify if you ported successfully? mar 23 23:08:43 kalikianatoli, port = use accessors ? mar 23 23:08:50 bisecting painfully :) mar 23 23:09:25 yes, port = accessors, no structs, different pkg-config file and so on mar 23 23:09:54 bratsche, agree, I think that is possible a 3.0 release with features like xi or csd on it mar 23 23:10:25 jjardon, that's exactly why we planned 2.90 mar 23 23:10:31 Yup. mar 23 23:11:36 I suspect the reason against 2.22 is that we won't manage to finish up sealing just before any feature additions mar 23 23:11:59 So I guess I half-way give in in practical considerations mar 23 23:12:53 Unless 2.22 could be a branch mar 23 23:13:03 So 2.22 instead of 2.20+api mar 23 23:13:16 Would that make any sense? mar 23 23:14:21 kalikianatoli, I didn't get it, sorry :) mar 23 23:14:49 as opposed to have a 2.22 in master? what would we gain? mar 23 23:17:21 So that 2.22 would cherry-pick changes as needed, ie. missing accessors, deprecations mar 23 23:17:38 But not completely new features like csd mar 23 23:17:50 And no new functions for xi2 mar 23 23:18:13 what about use 2.20 instead 2.22 for that mar 23 23:18:28 only as a special case mar 23 23:18:49 kalikianatoli, oh, so you mean as an early start? mar 23 23:18:56 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 mar 23 23:20:20 garnacho, the main issue are remaining functions and deprecations, right? so we need to get those done somehow mar 23 23:20:42 jjardon, so we're mostly talking about postponing new features after 2.90 and ditching 2.22, right? mar 23 23:20:47 kalikianatoli, indeed mar 23 23:22:06 jjardon, adding anything new to 2.20 disturbs the assumption that it is "stable" mar 23 23:22:43 kalikianatoli, very few accessor are needed currently mar 23 23:23:16 that is because I said as "special case", to push the GTK+ 3 development mar 23 23:23:40 it is easily around 40 or more functions we still need mar 23 23:23:47 not sure if that's very few mar 23 23:23:54 * chpe se ha marchado (Weg) mar 23 23:24:18 40? where are the bug reports? ;) mar 23 23:24:50 I didn't find the need of these functions while porting epiphany, glade3, gedit ... mar 23 23:25:00 if we take into account Gtk(RC)Style, that may be reached easily mar 23 23:25:20 jjardon, https://bugzilla.gnome.org/show_bug.cgi?id=592580 mar 23 23:25:26 gdk as one example mar 23 23:25:52 ah, ok. GDK was still not sealed mar 23 23:27:37 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. mar 23 23:29:07