[01:04] <ppd> hi, I wondered whether a further version of compiz will be released in time for the quantal release? Current unity+compiz in quantal is hell on nvidia multi-monitor
[08:24] <Mirv> andyrock: could you prepare a version of lp:~andyrock/unity/fix-1048274 for unity 6.0 branch as well?
[08:24] <Mirv> now that the trunk branch was merged
[08:25] <andyrock> Mirv, sure
[08:25] <Mirv> andyrock: thanks
[08:32] <andyrock> Mirv, https://code.launchpad.net/~andyrock/unity/fix-1048274-6.0/+merge/129370
[08:38] <Mirv> andyrock: thank you
[08:39] <andyrock> np
[08:39] <didrocks> Mirv: FYI, can you look for the video lens? https://code.launchpad.net/~davidc3/unity-lens-videos/stop-looking-for-recommendations-when-no-remote/+merge/129309
[08:39] <didrocks> Mirv: this one should be in SRU0, not sure if you forked the branch though for those lenses
[08:44] <davidcalle> didrocks, heya, about that, what's the merger issue in this specific case, when he refuses to merge on "No commit message specified"? Where should the message be set?
[08:45] <didrocks> davidcalle: you have a "set commit message" button above the description
[08:47] <davidcalle> didrocks, oh god.
[08:47]  * davidcalle goes back to his cave
[08:48] <didrocks> :)
[08:48] <didrocks> at bat cave at least? ;)
[08:50] <davidcalle> didrocks, shame cave. :p
[08:50] <didrocks> heh ;)
[09:18] <Mirv> didrocks: no separate Q branch for video/scope, and yesI targeted it for sru-0 as indicated in the bug
[09:20] <didrocks> Mirv: excellent, thanks!
[09:31] <Mirv> davidcalle: now that lp:unity-scope-video-remote exists (and I guess it contains everything up to 0.3.9), shouldn't the merge request be against it as well instead of the lp:unity-lens-videos/remote-videos-scope-trunk?
[09:35] <Mirv> just a cosmetic issue, though
[09:39] <Mirv> (...and will need merger changes as well)
[09:41] <davidcalle> Mirv, IIRC, it was decided to wait until the release and SRU0, to move trunk to its lp project.
[09:44] <Mirv> davidcalle: sounds wise
[09:45] <davidcalle> Mirv, I've been manually merging current trunk to the project, though, so it wouldn't be an issue to change now, but since different people have been working on it and  making releases in the current video lens project, I didn't want to add confusion during the cycle.
[09:46] <davidcalle> Mirv, by the way, do you know who is taking care of the merge now?
[09:46] <davidcalle> merger*
[09:49] <Mirv> davidcalle: mmrazik and fginther have the most experience, while me and sil2100 can try to tinker as well if in hurry
[09:50] <davidcalle> Mirv, ty
[09:53] <mhr3> davidcalle, fyi, we'll be moving the u1 music scope into shopping lens (cause they use the same code to create the music previews)
[09:54] <mhr3> i would like if the u1 video scope went there as well
[09:54] <mhr3> so shopping-lens would be actually a u1-services project
[09:55] <mhr3> i suppose that's exactly what you don't want, but it makes sense to keep those in one place
[09:56] <davidcalle> mhr3, got it. I will need to find a way with them to resolve a potential conflict between adding Youtube Online Accounts integration and the Youtube search coming from videosearch.ubuntu.com
[09:56] <mhr3> of course this would make most sense if u1 video was ported to vala and again parts of it could be reused in shopping if necessary
[09:57] <davidcalle> mhr3, indeed
[09:57] <mhr3> but ultimately there's no such request for now...
[09:57] <mhr3> that may change though
[10:01] <davidcalle> mhr3, the only part bothering me is the fact than free online videos would go in the same bag as unfree u1-services. On the other hand, they handle the server behind it. But that's just a *me* problem. I'll focus on video online accounts anyway, and with a merger and deduplication, videos coming form videosearch and ones from online accounts should blend... *brain dumping on you, sorry*
[10:03] <mhr3> well, it allows us to do smartness on the server...
[10:05] <davidcalle> mhr3, yeah, that would be nice too...
[10:08] <davidcalle> mhr3, by the way, there could mergers in every lenses, with a small doc on which fields it happens, for at least proper gdocs merging and third parties too.
[10:08] <mhr3> davidcalle, i meant the fact that we do single query to our servers enables us to do more stuff than requiring the lens to merge results from various scopes and do dedup and everything on its own, it'd get messy on the lens side
[10:09] <mhr3> davidcalle, yea... changes are being brewed :)
[10:09] <mhr3> changes for Unity-7.0
[10:12] <davidcalle> mhr3, sure, but if you add user youtube/vimeo videos via Online Accounts, there still need to be a merger in the lens. Well, unless the server knows about the accounts and can retrieve things like non-public videos and contacts... That would be brilliant, but passing Online Accounts oauth stuff to a server is pretty nasty.
[14:09] <bbbenjy> How to add shortcuts to Unity ?
[14:10] <bbbenjy> How to "see" commands behind the shortcuts ?
[15:10] <MCR1> didrocks: Hi :) Do you have 5 minutes ?
[15:11] <didrocks> MCR1: sure
[15:12] <MCR1> I start with this one: https://code.launchpad.net/~mc-return/unity/unity.merge-fix1006429-fix1006434-fix1063171/+merge/129150
[15:12] <MCR1> It fixes 3 bugs properly, is tested and needs approval.
[15:13] <didrocks> MCR1: looks good to me, approving
[15:13] <MCR1> and then I would need your logic attention for 2 minutes, didrocks - as I know you are a far better coder than me ;)
[15:13] <didrocks> MCR1: if you want that in quantal, you need to make the bugs compliant with the SRU process
[15:14] <MCR1> How should I do that ?
[15:14] <didrocks> and propose a branch for 6.0 :)
[15:15] <didrocks> MCR1: https://wiki.ubuntu.com/StableReleaseUpdates#Procedure
[15:15] <didrocks> just follow the checklist :)
[15:15] <MCR1> Important is that it finally lands, not that it is immediately available, but I'll look - thanx :)
[15:15] <didrocks> all 3 bugs needs it :)
[15:15] <didrocks> so, some logic question? :-)
[15:15] <MCR1> The second thing is about bug 1063249
[15:15] <MCR1> yes
[15:16] <MCR1> please open unity/plugins/unityshell/src/UnityShowdesktopHandler.cpp
[15:17] <didrocks> yep ;)
[15:18] <MCR1> line 148+ says progress_ = 1.0f; state_ = StateInvisible;
[15:18] <didrocks> indeed ;)
[15:18] <MCR1> but then in line 171 opacity is set to max value
[15:19] <MCR1> if progress == 1.0 -> it should be no opacity then, so the fix should be line 171:   if (progress_ == 0.0f)
[15:20] <MCR1> Have you read the bug report and tested what happens ?
[15:20] <didrocks> let me look at the bug I guess :)
[15:20] <didrocks> but without knowing the code path, what you are telling makes sense
[15:21] <didrocks> especially as you have     opacity *= (1.0f - progress_);
[15:21] <MCR1> It is best to enable slow animations in CCSM to see what is happening
[15:21] <MCR1> yes, you are correct
[15:21] <MCR1> but I unfortunately cannot test my fix at the moment
[15:22] <MCR1> CCSM->Composite Plug-in->Slow animations
[15:22] <MCR1> The bug indeed just happens if windows are fully faded out, so I am quite sure I got the right fix
[15:22] <MCR1> but I cannot test here at the moment ;)
[15:23] <didrocks> MCR1: I think your fix is right ;)
[15:23] <MCR1> but this behaviour annoys me a lot
[15:23] <didrocks> why can't you test it?
[15:23] <MCR1> Several reasons: Instability on Quantal, especially when doing large file operations
[15:23] <MCR1> like compiling
[15:23] <MCR1> gfx freeze
[15:24] <MCR1> I am suffering from that for about 5 weeks now
[15:24] <didrocks> urgh, not really nice
[15:24] <MCR1> yep
[15:24] <MCR1> urgh is the right word for it
[15:24] <MCR1> but it might be my SSD dying
[15:24] <MCR1> as I've exchanged all other things already
[15:25] <didrocks> MCR1: can't really test it right now, don't want to loose my session and some other stuff to finish, but I would say removing progress == 1.0 will enable to go until opacity *= (1 - 1)
[15:25] <MCR1> kernel, xorg & co
[15:25] <didrocks> ah, yeah, try booting on an usb
[15:25] <MCR1> yes - and that is what it SHOULD do
[15:25] <didrocks> you can even just:
[15:25] <didrocks> apt-get build-dep unity
[15:25] <didrocks> apt-get source unity
[15:26] <didrocks> and debuild
[15:26] <didrocks> in the live system
[15:26] <didrocks> to see how it goes
[15:26] <didrocks> (persistent usb key is better :))
[15:26] <didrocks> MCR1: I *think* your fix is safe to submit, let me look at the commit itself
[15:27] <MCR1> I will ask bschaefer later if he still is willing to test a fix from me after the merger troubles recently ;)
[15:27] <MCR1> I have not created a branch yet
[15:27] <didrocks> revno: 2164.1.8
[15:27] <didrocks> revno: 2164.1.8
[15:27] <didrocks> revno: 2164.1.8
[15:27] <didrocks> revno: 2164.1.8
[15:27] <MCR1> but this should really go to quantal as show-dektop-fade-back-in is used quite commonly
[15:28] <didrocks> "coding style"
[15:28] <didrocks> urgh
[15:28] <MCR1> ?
[15:28] <didrocks> copy and paste failure ;)
[15:28] <MCR1> ah
[15:28] <didrocks> so yeah "coding style"
[15:28] <didrocks> on that rev ^
[15:28] <MCR1> Pardon ?
[15:28] <didrocks> doesn't help really to know if the == 1 has been adding to fix something else
[15:28] <didrocks> MCR1: I mean, last time the line we are wondering about has been changed is in rev 2164.1.8
[15:29] <didrocks> (bzr blame helps to know that ;))
[15:29] <didrocks> and the commit message associated with it is "coding style"
[15:29] <didrocks> (so probably a refactoring)
[15:29] <MCR1> I will ask bschaefer later if he has 5 min to test my fix so we know for sure then...
[15:29] <didrocks> MCR1: get it under test by bschaefer if he's time, and then propose to unity and 6.0 :)
[15:29] <didrocks> sure :)
[15:30] <didrocks> MCR1: maybe a backport to precise can be interesting if impacted (didn't check)
[15:30] <MCR1> ok, I'll prepare the branch then - thx a lot as always
[15:30] <MCR1> didrocks: yes, afair it is impacted as well
[15:30] <didrocks> thanks a lot for looking at those little pesky bugs which destroy the user experience :)
[15:30] <MCR1> np, it is my user experience as well which gets destroyed
[15:31] <MCR1> but I still want my plug-ins back ;)
[15:33] <didrocks> :)
[15:45] <MCR1> https://code.launchpad.net/~mc-return/unity/unity.merge-fix1063249/+merge/129457
[15:45] <MCR1> bschaefer: Hi :)
[15:45] <MCR1> bschaefer: Sorry for the inconvenience I caused last time ;)
[15:45]  * bschaefer looks
[15:46] <bschaefer> MCR1, also hello
[15:46] <MCR1> bschaefer: Sorry again and I have another "attack" on you :)
[15:47] <bschaefer> MCR1, what sort of attack?
[15:47]  * bschaefer also just woke up
[15:47] <MCR1> bschaefer: Because you are the testing master it would be very nice if you could test the above branch 4 me, but please do not hurry with the coffee ;)
[15:48] <MCR1> I think I've fixed the fade-in showdesktop behaviour, but it is yet untested...
[15:48] <bschaefer> MCR1, I can take a look at making a test. Though looking at the bug/branch it might need to be a manual test
[15:48] <bschaefer> as it is more of a visual change
[15:48] <bschaefer> but let me see what the branch does
[15:48] <MCR1> yes ofc - I want nothing more
[15:48] <MCR1> just a manual test
[15:49] <MCR1> Please enable CCSM->Composite Plug-in->Slow animations to see if it works like intended and to see how it works now :)
[15:49] <bschaefer> well a manual test is always the last resort
[15:50] <MCR1> it is really enough for this one, believe me
[15:51] <MCR1> currently the showdesktop-fade-in is broken (popping in-fading-out-then-fading-back-in)
[15:51] <MCR1> with my fix it *should* be smooth again (if it ever was)
[15:52] <bschaefer> MCR1, hmm everything seems to fade back it as well
[15:52] <bschaefer> with out your branch
[15:52] <MCR1> have you enabled the slow animations ?
[15:52] <bschaefer> yeah
[15:52] <MCR1> and waited until showdesktop has faded out completely
[15:52] <MCR1> ?
[15:52] <bschaefer> ill wait a bit longer
[15:52] <MCR1> you have to wait
[15:53] <bschaefer> oo there we go
[15:53] <conscioususer> mpt: le ping
[15:53] <MCR1> otherwise the progress is not 1.0f or bigger
[15:53] <bschaefer> that is weird
[15:53] <bschaefer> cool, Ill see what your branch does :)
[15:53] <MCR1> and it has to be 1.0f to see the bug (opacity is set to full then)
[15:54] <MCR1> thx
[16:00] <bschaefer> MCR1, awesome, that works
[16:00] <bschaefer> MCR1, sooo writing a manual test is really easy :)
[16:00] <MCR1> \o/
[16:00] <bschaefer> go to unity/manual-test
[16:00] <MCR1> Should I really write one ?
[16:01] <bschaefer> Yeah,
[16:01] <bschaefer> Ill help you
[16:01] <MCR1> I do not really need help to do it
[16:01] <bschaefer> alright :), caause we love tests
[16:01] <MCR1> I've seen the manual tests already - should be able to do it
[16:02] <bschaefer> awesome, WindowManagement.txt should be  a good place for it
[16:02] <MCR1> Could you please comment on my branch, that it is tested ?
[16:02] <bbbenjy> How to add shortcuts to Unity ?
[16:02] <bbbenjy> How to "see" commands behind the shortcuts ?
[16:03] <MCR1> bbbenjy: install ccsm -> open it -> open commands
[16:03] <MCR1> bschaefer: will do
[16:03] <bbbenjy> Thanks
[16:03] <bbbenjy> Regards
[16:03] <bschaefer> MCR1, awesome, let me know when you push the test
[16:04]  * bschaefer goes to make coffee
[16:04] <didrocks> thanks MCR1 ;)
[16:27] <MCR1> bschaefer: Should be ready now :)
[16:28] <bschaefer> MCR1, awesome
[16:28]  * bschaefer looking
[16:29] <MCR1> bschaefer: Thx.
[16:29] <bschaefer> MCR1, the title and description should be a bit more detailed :)
[16:29] <bschaefer> MCR1, as you are fixing something
[16:29] <bschaefer> state what is being fixed,
[16:30] <MCR1> Why ? The bug is linked.
[16:30] <bschaefer> ie. Fading in on Show Desktop should slowly fade back in
[16:30] <bschaefer> must*
[16:30] <bschaefer> never use should
[16:30] <bschaefer> MCR1, yeah also point to the lp
[16:31] <MCR1> bschaefer: Do you mean the test or the commit message ?
[16:31] <bschaefer> MCR1, the test
[16:31] <bschaefer> because that test isn't really detailed in what you are fixing
[16:32] <MCR1> bschaefer: Because the test ofc just describes what should happen if you Show the Desktop/Restore previous state
[16:32] <bschaefer> MCR1, it does, but I think it would be better to state why the test is being written to begin with to prevent regressions
[16:33] <MCR1> bschaefer: hmmm
[16:33] <bschaefer> So: Show Desktop must fade back in
[16:33] <MCR1> maybe exchange "should" with "must"
[16:33] <MCR1> ?
[16:34] <MCR1> and I could also add the time (300ms)
[16:34] <bschaefer> MCR1, that as well
[16:34] <bschaefer> no not ms
[16:34] <bschaefer> MCR1, im just saying a bit more detail in the test would help prevent regressions :)
[16:35] <bschaefer> The test is showing that fading back in happens, as opposed to not
[16:35] <MCR1> bschaefer: IMHO we should improve ShowDesktop anyway in the mid-term...
[16:35] <MCR1> ok, I'll try to re-word that test
[16:36] <bschaefer> MCR1, well we already have an AP test for the Show Desktop behavior
[16:36] <bschaefer> we are more writing a manual test because the visual part is broken, that you fixed
[16:36] <MCR1> ah ok
[16:41] <MCR1> bschaefer: Ready (hopefully) :)
[16:42] <bschaefer> MCR1, cool, thanks :)
[16:43] <bschaefer> MCR1, everything is good except one more thing: 72
[16:43] <bschaefer> Show Desktop
[16:43] <bschaefer> 72
[16:43] <bschaefer> Show Desktop
[16:43] <bschaefer> the title
[16:44] <bschaefer> that is the title of the test, it should be brief but add a bit more detail :)
[16:44] <MCR1> +behavior ? +visual behavior ?
[16:44] <bschaefer> MCR1, noo on line 72
[16:45] <bschaefer> of your diff
[16:45] <bschaefer> the title is just Show Desktop
[16:45] <bschaefer> a bit more detail in the title and that test looks good :)
[16:45] <MCR1> what do you suggest here ?
[16:46] <bschaefer> Show Desktop fades slowly in
[16:46] <MCR1> but it should also fade slowly out
[16:46] <bschaefer> yeah, but that isn't a problem
[16:46] <MCR1> maybe it will be ?
[16:46] <bschaefer> your fixing the fading in
[16:46] <bschaefer> well then
[16:47] <bschaefer> Show Desktop fades slowly in/out
[16:47] <MCR1> and you have to fade out before you can fade in anyway
[16:47] <MCR1> how about smoothly instead ?
[16:47] <bschaefer> that sounds better
[16:47] <bschaefer> and drop the in/out
[16:47] <MCR1> ok
[16:48]  * bschaefer sucks at manual tests
[16:49] <MCR1> done
[16:49] <bschaefer> thanks
[16:50] <bschaefer> MCR1, approved :)
[16:51] <MCR1> thx - that one annoyed me for quite some time now 8-)
[16:53] <MCR1> bschaefer: Together with my other fix all showdesktop issues should now be history :)
[16:53] <bschaefer> MCR1, excellent, I don't normally use showdesktop so I don't notice it as much :)