On Mon, Jan 17, 2011 at 6:47 AM, Kristian Lyngstol <[email protected]> wrote: > On Mon, Jan 17, 2011 at 06:29:06AM +0800, Sam Spilsbury wrote: >> On Mon, Jan 17, 2011 at 3:44 AM, Kristian Lyngstol >> <[email protected]> wrote: >> > I had expected the glib-work to be merged with mainline by now. This is a >> > prerequisite for the a11y-work, since we'd otherwise have to do it using >> > the glib-plugin as the test-base, which I'd rather avoid. Specially since >> > I'm not the one doing the actual glib/atk stuff, I'm only pitching in to >> > set up interfaces and mentor Ale a bit. >> >> It wasn't ready yet. It changes a lot of how core works and I want to >> get it signed off by some of the other key players here. There are >> still bugs because it conflicts with the gconf backend for >> libcompizconfig in quite a nasty way. > > Understandable. Is there any chance it'll create sensible pull queues, > though? It'll be hard to review it if it's 6-months worth of work. I've > looked at the code and played with it, mind you, and I wasn't really able > to generate sensible patch sets - it simply grew too big for conventional > patch/merge review.
There is a big pull queue, but the overall diff between it and master is not really that big. > >> > The lack of merging is holding up involvement due to the "waiting for the >> > next great thing!"-phenomenon... >> >> The code has always been available - >> git://git.compiz.org/git/users/dbo/compiz-with-glib-mainloop. Just >> because it hasn't been merged yet, it doesn't mean that we all agree >> that core is going to go in this direction, I just don't want to merge >> it yet since there are bugs that need to be worked out. > > I don't think there's any real chance that it wont be pulled in, unless > it's prolonged (ie: nomad/object framework/etc). Don't you think it would > be easier for everyone to pitch in if we only had one code-base to focus > on? It's not my place to push this agenda further, so "just sayin'". > Of course. I just don't want to merge stuff with bugs :) >> In the meantime I believe the glib plugin should be sufficient to >> provide enough of a glib mainloop to do ATK with. We only needed glib >> dispatching integrated in core for unity since there was the issue of >> timeout accuracy. > > Ok, understandable. I'll go ahead with the glib-plugin. Hopefully it'll > re-kindle my interest enough to help out so we can get the glib-branch > merged. Cool. > >> > So my question becomes: what's the merge plan? >> >> Soon. >> >> I'm currently inundated with fixing bugs and I really haven't had the >> chance to go through the full steps to merge this branch. > > Excellent. > > Just for the record: I'll take massive instability in master over prolonged > used of two different branches. It's much more inspiring. The massive instability in master is actually because I have changed a lot of core code to accommodate reparenting. For example, we now have to be more careful about how we do XGrabButton on windows because there are some applications that don't like it when we activate a passive grab and then deactivate it very quickly (causing enter and leave events on reparenting). Also the menu stacking thing is my fault (due to a change in startup order which was necessary to fix some other bugs) and a fix for that is being worked on as we speak (it is actually 2 bugs in one - one where we are not getting damage events where we should, another where stacking is just completely b0rked). > > - Kristian > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > > iQEcBAEBAgAGBQJNM3WfAAoJEIC1IG5rXEfqh+cH/AosdY2v4ZEJ8BgJ2LbmiKzW > d/BCYbggMmhpR2jwR7geqHs7s5u7Y5GIbPE7k+GJacOzue80xRSTBz/O98BAVAnh > 1JmHgsobE5fivnHVH3x6uB98jCV+QJrZyv5H+2eTU0D2TGfMJXRc/iadW+1Oddux > jM2Qusjx7xD1ImSmCyCTSS2Wvgr/ZIcKPntNrLx1vWHiESb8MseihGr7Gpwap5zL > L0dme7FCqrNpcvMR3CcbOj3wrwR80wSuuhwIelVqV36RfQxilUb/bN803t7qhotZ > mNCCKBwurM5bOTmvds/G1+vPz/ozqD8KXAAH5qmTq7Olr/f0C78rAPPfYKUu2Mg= > =zKBT > -----END PGP SIGNATURE----- > > -- Sam Spilsbury _______________________________________________ dev mailing list [email protected] http://lists.compiz.org/mailman/listinfo/dev
