[01:01] <hyperair> hmm, compiz needs the equivalent of emacs's C-h k
[08:43] <rperier> Hi all, bug 1019457 is still pending for PS Jenkins Bot, it seems not uploaded yet in ubuntu. That's normal ?
[08:49] <sil2100> rperier: hi! Let me check that
[08:50] <sil2100> rperier: I think it's already in Ubuntu
[08:50] <sil2100> rperier: since the version that includes your fix is 6.12.0daily13.01.25.1-0ubuntu1, and from what I remember that's the one in raring
[08:51] <rperier> I did not see the changelog in raring, I probably missed it :\
[08:57] <jibel> rperier, it will be in unity 6.12.0daily13.01.29-0ubuntu1 but automated tests failed and it didn't land into the distro
[08:59] <rperier> jibel: automated tests failed ? it has something to do with the test case I added for my fix or not ?
[09:00] <sil2100> rperier: I think it was due to a doc-string tab-character instead of space
[09:00] <sil2100> rperier: in the autopilot test - but we fixed that
[09:01] <rperier> sil2100: oh, I saw the commit yeah !
[09:01] <sil2100> jibel: could you also make sure that https://code.launchpad.net/~sil2100/unity/bump_compiz_dep_abi_break/+merge/145330 gets reviewed and included before the release?
[09:01] <jibel> rperier, no it's unrelated to your fix. autopilot run failed this morning with a "unity not installed" error, someone from the unity team have to look into this
[09:01] <sil2100> jibel: it might be due to the ABI bump
[09:02] <rperier> no because I don't like commit crap or broken tests :)
[09:02] <sil2100> jibel: since there was an ABI break in compiz, we bumped the ABI version for compiz, and now I also bumped the compiz-dev build-dep in unity
[09:03] <sil2100> jibel: so, unity might have failed installing because compiz was offering a new ABI version, while unity was still build with the old ABI - therefore installing compiz removed unity
[09:03] <sil2100> jibel: but if we get this merge in, we should be fine
[09:04] <sil2100> Just compiz needs a release as well
[09:04] <jibel> sil2100, yes, very likely, I think mterry does this kind of review while didrocks is away, or is there anyone else?
[09:05] <sil2100> jibel: yes, mterry usually does it, but it'll be some time till he appears - maybe Mirv could take a look right now instead? ^
[09:05] <sil2100> Mirv: ^
[09:08] <rperier> btw, yesterday it was impossible for me to activate the warnings for unity.dash.view even if I export UNITY_LOG_SEVERITY="unity=warning;unity.dash.view=warning"  (I just try to understand what I do, so I add logs locally into my code). This is for unity-R on raring
[09:09] <Mirv> sure I can check and approve that one
[09:10] <rperier> however there's no hurry, I will retry today in the afternoon
[09:12] <Mirv> approved
[09:12] <Mirv> (the sil2100's branch, that is)
[09:22] <sil2100> Mirv: thanks!
[10:37] <rye> uhm, i think something went wrong after fixing the maximize/restore button - now one can't click on indicators when dash overlay is open
[10:37] <rye> bug #1101310 i mean
[10:37] <luv> rye: hi, I got raring installed in VM, I will make sure it compiles fine tonight - but I can't test because compiz is unusably slow in my VirtualBox - so I will send you a link to the patch/lp-branch tomorrow
[10:38] <rye> luv: sure, compiz is slow because you are using llvmpipe rendering in virtualbox - you will want to install guest additions to get hw acceleration working
[10:43] <luv> can i get guest additions for raring?
[10:44] <luv> oh and can i install them without gui? it's that slow ....
[10:49] <rye> luv: looking for info..
[10:50] <rye> luv: http://askubuntu.com/questions/207813/why-does-an-ubuntu-12-10-guest-in-virtualbox-run-very-very-slowly/214968#214968 ?
[10:50]  * rye does not use virtualbox
[10:50] <rye> for now
[10:52] <luv> thanks, i will have a look tonight
[10:53] <popey> sil2100: i have no desktop appearing on my desktop bare metal running staging..
[10:54] <popey> sil2100: http://paste.ubuntu.com/1585460
[10:55] <sil2100> It doesn't look like staging to me
[10:56] <sil2100> It looks more like the daily PPA
[10:56] <popey> oh balls
[10:56] <sil2100> popey: but anyway, let's maybe wait for one merge to go into unity
[10:57]  * popey downgrades and starts again
[10:57] <sil2100> https://code.launchpad.net/~sil2100/unity/bump_compiz_dep_abi_break/+merge/145330 <- this one, I hope it'll get merged soon
[10:57] <sil2100> A bit strange, since it's waiting for merge since an hour already
[11:03] <popey> ok, staging in bare metal and staging in vm are both okay.. phew!
[11:06] <sil2100> Phew! So no VM problems with compiz?
[11:08] <sil2100> mmrazik: is everything ok with the merger right now?
[11:09] <mmrazik> sil2100: didn't see any issues so far
[11:09] <sil2100> mmrazik: since I didn't see any new merges getting in and https://code.launchpad.net/~sil2100/unity/bump_compiz_dep_abi_break/+merge/145330 is approved for 1 hour already
[11:09] <sil2100> Is it busy?
[11:09] <mmrazik> no, not really. looking into ti.
[11:10] <sil2100> Thank you :)
[11:10] <mmrazik> sil2100: its landing
[11:10] <mmrazik> as far as I can see the tests already finished
[11:10] <mmrazik> its just being merged
[11:10] <mmrazik> sil2100: well.. it is merged
[11:11] <sil2100> mmrazik: excellent, phew! Thought something was wrong - thanks
[12:24] <rperier> well, in fact logs work fine :)
[12:24] <rperier> I probably did some craps yesterday ;)
[12:43] <rperier> I found a fix for switching from command.lens to home.lens. Basically, when the DashView receive an ACTIVATE_REQUEST event (dash/DashView.cpp:OnActivateRequest() ), if this one is of type NOT_HANDLED AND the dash is visible AND the new len != the current one, instead of closing the dash we need to switch to this new len using lens_bar->Activate(id)
[12:44] <rperier> and I don't know if you're agree for remember the current len...
[12:47] <rperier> I probably need to open a bug first, then I explain the fix and then I attach a patch or I link a branch... this is probably a better approach
[13:04] <bregma> rperier, yes, that's the preferred approach
[13:11] <mterry> fginther, today's daily build of unity says "UNITY_NOT_INSTALLED"
[13:11] <mterry> (or rather, it has a file in the artifacts called that)
[13:14] <jibel> mterry, it was due to the ABI change that sil2100 fixed this morning. unity was not installable
[13:14] <mterry> jibel, ah makes sense
[13:15] <sil2100> mterry: hi, yes, I fixed it more or less I think ;)
[13:16] <mterry> OK.  Let me try rebuilding unity then
[13:19] <sil2100> We need new compiz and unity released at the same time
[13:20] <rperier> bregma: I will open a bug then :)
[13:21] <jibel> they will because they are part of the same stack
[13:28] <MCR1> ...volunteer for approving MPs needed...
[13:29] <MCR1> very easy (1 minute): https://code.launchpad.net/~mc-return/compiz/compiz.merge-fix1101641-use-snprintf-instead-of-sprintf/+merge/145228
[13:29] <MCR1> easy (1 minute): https://code.launchpad.net/~mc-return/compiz/compiz.merge-fix1101549-and-fix1101561-missing-break/+merge/145161
[13:30] <MCR1> advanced (5 minutes): https://code.launchpad.net/~mc-return/compiz/compiz.merge-fix1106270-showmouse-plugin-needs-port-to-GLES/+merge/145069
[13:30] <MCR1> advanced (5 minutes): https://code.launchpad.net/~mc-return/compiz/compiz.merge-fix1099100-thumbnail-title-text-issues.0/+merge/144954
[13:33] <MCR1>  all of those are already approved and tested, but still need a final green light...
[13:44] <Grottenolm> Hi there, I lost something on my unity desktop: If I minimize XChat to the tray ... where can I find it afterwards? Any helpful hint will be appreciated.
[14:12] <bregma> Grottenolm, is the xchat icon still in the Launcher on the left?
[14:13] <Grottenolm> bregma, no, it is not
[14:14] <bregma> urgh
[14:14] <Grottenolm> but the program is running
[14:14] <Grottenolm> I can't log in again with the same nickname
[14:16] <MCR1> JohnLea: Are you here ?
[14:22] <rye> bregma: i suppose xchat is using old style status icon and you may want to whitelist it
[14:26] <Mirv> MCR1: went through 3/4, leaving the last one for someone else
[14:28] <MCR1> Mirv: Oh, thx a lot :)
[14:28] <MCR1> Mirv: Once they are merged I can start to fix conflicts on their follow-ups ;)
[14:29] <Mirv> np :)
[15:06] <rperier> bregma: bug opened, this is the bug 1108956
[15:06] <bregma> rperier, thanks
[15:07] <sil2100> oh, the other way around
[15:07] <sil2100> heh ;)
[15:20] <davmor2> hey guys is there a way round a system not sleeping or locking if the dash or an indicator are in use ie select one don't move the mouse away system does sleep/lock till the mouse if indicator is closed
[15:23] <Xetius> Is there a way to set an application to override system key bindings when it is active, and have the default system keybindings active when it's not?
[15:32] <mterry> fginther, I started a build 52 for unity-head earlier today from the web interface.  Now it's gone and not on the jenkins dash anymore.  :(
[15:33] <fginther> mterry, looking
[15:43] <fginther> mterry, something weird happend. I received email that the ps-unity-autopilot-release-testing job finished (unstable) but it's not on the server
[15:43] <mterry> fginther, I started this job from the web UI.  That might be an unusual path?  I think didrocks usually uses his script
[15:44] <sil2100> I sometimes use the web panel as well, so hm
[15:44] <fginther> mterry, that shouldn't be a problem.
[15:44] <mterry> nm then  :-)
[15:45] <mterry> fginther, shall I start a new one, and see what number it gives it / if the same thing happens?
[15:45] <fginther> mterry, I saw some other odd behavior, which looked like jenkins was restarting. But I can't find evidence either way
[15:46] <mterry> OK, well.  I guess I'll try again
[15:46] <fginther> mterry, yes, might as well get some good test results :)
[15:46] <mterry> fginther, yup, gave it #53
[15:47] <fginther> #52 must be a ghost
[15:48] <sil2100> Ghost builds, brr
[15:54] <rperier> is it an acceptable proposal to put LensBar::GetActiveLensId() public ? I need it for my fix (see the previous bug that I pasted below)
[15:54] <rperier> s/below/above/
[16:04] <JohnLea> MCR1; hyia, I'm here now ;-)
[16:07] <MCR1> JohnLea: Hey, just wanted to ask you if you could once again okay this: bug 1069165
[16:08] <MCR1> I have solutions for both in mind, but have to discuss it with other devs, because it needs a few changes
[16:09] <MCR1> JohnLea: For the Alt+Enter Fullscreen/Unfullscreen keys we have a lightweight Compiz plugin to do it
[16:10] <JohnLea> MCR1; also when thinking about keyboard shortcuts take a look at https://docs.google.com/a/canonical.com/document/d/1jqeKtIJwqLtl58Wk_fqjr9Rrgxn9zsouCYOo-cZsLSE/edit
[16:12] <MCR1> JohnLea: Very interesting.
[16:13] <MCR1> JohnLea: One big problem is the "Restores or minimises" shortcut -> this is not an easy thing to accomplish
[16:14] <JohnLea> MCR1; if  1) a Windows key combination does not clash with an existing Ubuntu key combination and 2) adding the key combination does not remove any existing Ubuntu keyboard shortcut ...   then I think we should add it.  I don't think we should add all of these to the keyboard shortcut overlay because we have only limited space there.  If you could open up bugs to for each of the new key combos you would like to change, and in the bug
[16:14] <JohnLea>  report say "This keyboard shortcut does not clash with any existing Ubuntu shortcut, and is being added to help windows users transition to Ubuntu.  Also adding this shortcut does not removing any existing shortcut"  (or something along those lines)  I'll ack the bug reports.
[16:14] <JohnLea> MCR1; yes, I know that one is some work to do...
[16:15] <MCR1> JohnLea: I am for removing "minimises" and make a own shortcut to "minimise" until the groundstructure to fix it properly is laid
[16:15] <JohnLea> MCR1; also see all the bugs listed at the bottom of the doc, several are still open and would be good ones to fix
[16:15] <MCR1> JohnLea: because otherwise people see it as a bug
[16:15] <MCR1> JohnLea: Yes, thanks a lot for the document. I have saved it ;)
[16:16] <JohnLea> MCR1; yes, also good luck fixing the restore/minimise bug! ;-)
[16:16] <MCR1> JohnLea: So we should either just remove the words "and minimises" or remove those words and add another shortcut to minimise a window
[16:17] <JohnLea> MCR1; let's not add another shortcut atm, and focus on fixing the bug
[16:17] <JohnLea> but we can change the text until it is fixed
[16:17] <MCR1> JohnLea: ok, that is what I meant
[16:17] <JohnLea> MCR1; cool ;-)
[16:17] <MCR1> JohnLea: because the fix is really complicated
[16:19] <JohnLea> MCR1; I know, we have fixed many of the easier bug already, a lot of the bugs we have now are the hard ones.  If this was easy to do it would prob. be fixed by now!
[16:19] <MCR1> (I do not want to nerve you with details)
[16:19] <JohnLea> MCR1; I'll let you bother Sam about that ;-)
[16:19] <MCR1> ok ;)
[16:52] <ricotz> Trevinho, hi
[16:56] <Trevinho> ricotz: hey
[16:57] <ricotz> Trevinho, please let me know if you figured out the "Unable to find default local directory monitor type" problem ;)
[16:57] <ricotz> meaning this one https://jenkins.qa.ubuntu.com/job/bamf-mbs-ci/build=pbuilder,distribution=quantal,flavor=amd64/37/console
[16:57] <Trevinho> ricotz: I've noticed that...
[16:57] <Trevinho> ricotz: but I don't know what happens, it seems pretty random
[16:58] <ricotz> Trevinho, i got reports for other apps even a mono-app failing on that one
[16:58] <Trevinho> ricotz: I didn't go into the glib internals, however
[16:58] <ricotz> Trevinho, weirdly this happened on precise too
[16:59] <Trevinho> ricotz: of coure I can calm-down the builder (by hiding the warning), but don't see why this happens...
[17:00] <ricotz> Trevinho, yeah, but it seems to be some real problem
[17:00] <Trevinho> ricotz: all happens here http://codesearch.debian.net/show?file=glib2.0_2.33.12%2Breally2.32.4-3%2Fgio%2Fglocaldirectorymonitor.c&line=287&numfiles=3182#L287
[17:00] <ricotz> can't reproduce it myself though
[17:10] <MCR1> Haha - I think I've found the best (and proper) solution for bug 966099 \o/
[17:13] <MCR1> andyrock, bregma, bschaefer, Trevinho: ^^ http://pastebin.com/K0ZzRLyZ
[17:13] <MCR1> I am proud I found a easy solution
[17:14] <andyrock> MCR1, do you have a branch?
[17:14] <MCR1> not yet
[17:14] <andyrock> MCR1, ping me when it's ready
[17:14] <bschaefer> MCR1, can you do a bzr diff > x and paste bin that? Or a branch would be nice
[17:14] <MCR1> but in a moment (gotta eat somethin' before)
[17:14] <Trevinho> MCR1: nice! ;)
[17:14] <MCR1> bschaefer: Sure, I'll make a branch
[17:14] <bschaefer> MCR1, and nice, go eat
[17:14] <bschaefer> :)
[17:15] <MCR1> andyrock, bschaefer, Trevinho: Thx (& will do ;))
[17:15] <andyrock> MCR1, btw my overlay does not say "ctrl+super+down"
[17:15] <MCR1> what does it say ?
[17:16] <MCR1> if it is just the shortcut itself, which is different - it does not matter
[17:38] <seb128> so, does anyone know why libdbusmenu is not daily landing in raring?
[17:38] <seb128> mterry, ^?
[17:38] <seb128> or is that a didrocks secret?
[17:39] <mterry> seb128, I don't know how to tell yet if the "auto push" button is on or not.  But it seems OK according to the autopilot tests
[17:39] <mterry> seb128, unity stack isn't OK.  But libdbusmenu isn't part of that
[17:39] <seb128> ok
[17:39] <mterry> seb128, so didrocks secret I guess  :-/
[17:39] <seb128> I wonder if we should just manually backport the 2 leak fixes from chrisccoulson
[17:40] <seb128> and wait for didrocks then
[17:40] <mterry> seb128, we can manually push....
[17:40] <seb128> mterry, do you know how to do that?
[17:40] <mterry> seb128, oh wait.  No.  We thought we could, but there's something missing that we have to investigate to fix.  We need a credentials file that we have to create.  Let me see
[17:41] <seb128> mterry, I just want those leaks fixed in raring so people don't get confused by then in their new valgrinds logs
[17:42] <jibel> seb128, didrocks disabled autolanding of libdbusmenu on Jan. 15th but the commit message doesn't say the reason: "  disable dbusmenu and better wording for publishing not happening"
[17:42] <seb128> jibel, at the time the tests were still broken, cyphermox fixed them since
[17:44] <mterry> jibel, seb128: it was already re-enabled
[17:44] <mterry> jibel, maybe that bzr commit wasn't propogated to the jenkins?
[17:46] <mterry> jibel, does jenkins have commit 197?
[17:47] <jibel> mterry, right, didier reenabled it a week ago but last run was 18 days ago. He apparently didn't republish the stack.
[17:47] <jibel> mterry, do you know how to do it or should I do it?
[17:49] <mterry> jibel, I don't know how to publish from web UI.  And I need credentials file for script (working on it).  So if you could do it, it would be swell
[17:49] <rye> bschaefer: hi, re bug #1101310 - it looks like indicators are no longer clickable when dash is open, not sure whether they were intended to be clickable though
[17:50] <bschaefer> rye, hmm well, that could be why the dash was designed to close when clicking on the panel
[17:50] <jibel> mterry, ok, I have to run now but I'll do that this evening before next run of the indicators.
[17:50] <bschaefer> or how it was...shoot
[17:50]  * bschaefer has broken indicators atm
[17:51] <seb128> jibel, thanks
[17:52] <bschaefer> rye, let me fix that
[18:03] <seb128> cyphermox, https://launchpadlibrarian.net/129872662/buildlog_ubuntu-raring-amd64.libdbusmenu_12.10.3-0ubuntu1%2Bbzr440%2Bpkg0~raring1_FAILEDTOBUILD.txt.gz
[18:04] <seb128> cyphermox, one test failed there ... not sure if that's concerning the daily landing though
[18:04] <cyphermox> huh, right
[18:04] <cyphermox> yeah, it would
[18:04] <cyphermox> where was that?
[18:04] <cyphermox> charles_: ^^ did you end up figuring out what's up with that glib-events test?
[18:06] <charles_> cyphermox, I think so. Also I've got the libappindicator fix for you, just getting the bug tickets all up-to-date before I MP
[18:07] <cyphermox> ok
[18:07] <rye> bschaefer: hud still works with indicators (closes when they are clicked). But in unity2d indicator menus could pop-up over opened overlay so I don't know what's the proper way
[18:07] <bschaefer> rye, yeah, ill talk with design
[18:08] <bschaefer> rye, I removed that, because I thought that was causing the problem at first, and left it in
[18:08] <bschaefer> rye, its an easy fix, if its needed
[18:08] <bschaefer> rye, and actually the dash just closed when clicking on the panel, the Hud can handle things much nicer :)
[18:08] <bschaefer> (as it doesn't eat up the panel height)
[18:11] <rye> bschaefer: erm.. why does dash eat the panel height? for min/max/close buttons?
[18:11] <bschaefer> rye, for the dash dash preview
[18:12] <bschaefer> rye, as the ghost image of the preview is drawn over the panel, and when the launcher is resized the dash is over top the window buttons
[18:14] <rye> bschaefer: oooh
[18:16] <bschaefer> yeeah, otherwise it would have been an easy fix by add the panel height to the dash view (which is how the Hud can handle things easily)
[18:29] <ian__605> #0  0x00007fbb283f74b3 in ccsGSettingsValueChanged () from /usr/lib/libcompizconfig_gsettings_backend.so
[18:29] <ian__605> Can anyone give me some advice for debugging an app? A user gets inconsistent crashes with a SIGSEGV in ccsGSettingsValueChanged(). I can't reproduce it but it seems to happen every 7-8 program starts for him. Starting with gdb never reproduces it, but an apport bug report gives some info. seems that SegvReason is reading unknown VMA
[18:29] <ian__605> Sorry first post was the beginning of the stacktrace. Problem seems to come from compiz-gnome package
[18:31] <fginther> mterry, have you seen the ps-unity-autopilot-release-testing results? There is a noticable uptick in failed tests
[18:32] <mterry> fginther, hadn't looked yet.  let me see
[18:35] <mterry> fginther, they seem to be all a similar problem.  sil2100 , you around?  A lot of autopilot errors like:
[18:35] <mterry> Traceback (most recent call last):
[18:35] <mterry>   File "/usr/lib/python2.7/dist-packages/unity/tests/test_switcher.py", line 125, in test_switcher_move_next
[18:35] <mterry>     start = self.switcher.selection_index
[18:35] <mterry>   File "/usr/lib/python2.7/dist-packages/unity/emulators/switcher.py", line 72, in selection_index
[18:35] <mterry>     return self.controller.model.selection_index
[18:35] <mterry>   File "/usr/lib/python2.7/dist-packages/unity/emulators/switcher.py", line 240, in model
[18:35] <mterry>     i = self.get_children_by_type(SwitcherControllerImpl)[0]
[18:35] <mterry> IndexError: list index out of range
[18:35] <mterry> }}}
[18:36] <fginther> mterry, agreed. There are 28 failures due to that IndexError trace
[18:36] <fginther> in the ati test
[18:38] <sil2100> Ok, so
[18:38] <sil2100> It looks like another problem with switcher refactoring
[18:38] <sil2100> mterry: what packages are those tests based on? What versions?
[18:39] <fginther> sil2100, unity is revision 3083
[18:39] <sil2100> That's strange
[18:41] <sil2100> Need to check if they changed anything in the source again
[18:42] <fginther> sil2100, https://code.launchpad.net/~bregma/unity/refactor-switcher-controller-2/+merge/145025 removed switchercontrollerImpl from introspection
[18:43] <bregma> cripes
[18:43] <sil2100> Ah, eh
[18:43] <sil2100> fginther: just found the same thing
[18:43]  * sil2100 sighs
[18:43] <sil2100> Again need to modify the tests to fit the new source changes
[18:45] <sil2100> Eh eh
[18:45] <bregma> sorry about that
[18:45] <bobweaver> Hello there should I fix bugs that are in unity 2d ?  or is it a waste of time ? No I do not want to program NUX and C++ , I just like qml
[18:45] <sil2100> fginther: can I deal with it tomorrow?
[18:46] <bregma> the code under test got modified to fix the tests and the tests were modified to fit the hidden internals of the code again and there was a mid-air collision
[18:46] <sil2100> mterry, fginther: will you guys have anything against the fix waiting for tomorrow morning my time?
[18:47] <bregma> bobweaver, you can propose fixes to unity-2d, they'll require SRUs to get them picked up in 12.04 or 12.10 though
[18:47] <mterry> sil2100, no that's fine
[18:47] <sil2100> mterry, fginther: thanks! See you tomorrow then ;)
[18:47] <fginther> sil2100, later
[18:51] <bobweaver> thanks bregma
[18:59] <rperier> this patch looks good http://bazaar.launchpad.net/~rperier/unity/command-lens-switching/revision/3083 ?
[19:00] <rperier> (I am not sure at all about the autopilot test :\ )
[19:04] <rperier> I will propose a merge a link the corresponding bug to it
[19:20] <MCR1> andyrock: Ping :) https://code.launchpad.net/~mc-return/compiz/compiz.merge-fix966099-add-unmaximize-or-minimize-window-key/+merge/145464
[19:20] <MCR1> andyrock: The Unity overlay shortcut also needs adjustment... but functionality is provided by Compiz
[19:21] <MCR1> *Unity Help Overlay->change unmaximize_window_key to unmaximize_or_minimize_window_key
[19:24] <rperier> when you have time, someone could confirm bug 1108956 ?
[19:26] <bschaefer> rperier, hmm im not sure if thats a bug, for example if you do a Super + a, then press super the dash closes as wel
[19:27] <bschaefer> rperier, though, just to be safe, ill assign the design team to take a look at it
[19:27] <MCR1> the problem is (once again) -> too many functionality on one key :)
[19:27] <MCR1> *functionalities
[19:29] <MCR1> bschaefer: Do you have time to check the branch above ?
[19:31] <MCR1> It just adds a shortcut, which will act intelligently and restore a maximized window, while also being able to minimize a non-fullscreen window...
[19:31] <MCR1> *non-maximized
[19:31] <MCR1> maximized != fullscreen
[19:34] <bschaefer> MCR1, hmm sure, ill have to compile a bunch of things so it'll take a bit
[19:34] <MCR1> no stress...
[19:34] <andyrock> MCR1, first of all you need to fix the indentation
[19:34] <MCR1> ok
[19:42] <MCR1> andyrock: Should be fixed - well, the CompScreenImpl::* all have wrong indentation, but I've not fixed the others, just the newly added stuff...
[19:42] <rperier> bschaefer: so that's a bug when switching from the dash to command lens but not from the command lens to the dash ?
[19:42] <rperier> mhh
[19:43] <rperier> let check the design team yeah
[19:43] <bschaefer> rperier, i assigned the design team, as they have the real say in it
[19:43] <rperier> yeah I saw
[19:43] <bschaefer> but you would think going from Super + a -> Super should go to home dash, if your bug is a bug
[19:43] <bschaefer> unless they are both bugs
[19:44] <rperier> what Super+a does exactly ? (I am not on unity right now)
[19:45] <bschaefer> it goes to the application lens
[19:45] <bschaefer> super+m, the music, super+f the file lens
[19:48] <rperier> useful shortcuts :)
[19:59] <MCR1> andyrock: Here the corresponding Unity MP: https://code.launchpad.net/~mc-return/unity/unity.merge-fix966099-shortcut-fails-to-minimize-just-restores/+merge/145474
[20:00] <andyrock> MCR1, adding the review to my TODO list
[20:00] <andyrock> thanks ;)
[20:00] <MCR1> thx
[20:01] <MCR1> && ofc I hope your TODO list is small, but I guess it's not
[20:01] <MCR1> ;)
[20:02] <MCR1> :-X
[20:03] <andyrock> MCR1, well reviews have the priority ;)
[20:03] <MCR1> \o/
[20:03]  * bschaefer is almost done compiling everything...
[20:04]  * MCR1 also needs some double xeon machines ;)
[20:21] <bschaefer> MCR1, hmm sometimes when I do that shortcut the window goes to a different workspace...
[20:24] <MCR1> bschaefer: strange - can you define sometimes ? is it generally working ?
[20:24] <bschaefer> MCR1, well it seems to only do it after a compiz --replace
[20:24] <MCR1> hmm
[20:25] <MCR1> if you look at the compiz code -
[20:25] <bschaefer> which makes me think the windows don't update their workspace when forced onto the first one
[20:25] <MCR1> I've just merged the functions minimize and restore to one - so it should not be able to do that...
[20:26] <bschaefer> MCR1, also, I don't think its always guaranteed that the window on top is the focused window
[20:27] <bschaefer> though it does seem to ignore the correct ontop windows
[20:30] <bschaefer> MCR1, also why did you move those functions together? Usually when a function name as an Or in it, it should be split up
[20:30] <bschaefer> SRP
[20:36]  * bschaefer goes to eat lunch
[20:38] <MCR1> I moved them together to make it a core functionality as CCSM and thus Compiz rebell if two different actions are mapped to one shortcut
[20:40] <MCR1> I made it act intelligent, depending on the state of the window and mapped that combined-smart-function on one key to avoid CCSM from rebelling
[20:41] <MCR1> To not change any users' shortcuts it is a new shortcut and name now
[20:43] <MCR1> I think it is the most intelligent way to fix the bug, otherwise CCSM would probably have to be rewritten, now we simply got a smart shortcut... :)
[21:07] <bschaefer> MCR1, hmm well what I mean is there is a shortcut for Ctrl+Super+Up and a different one for Ctrl+Super+Down
[21:07] <bschaefer> MCR1, which each one should have a different callback function
[21:08] <MCR1> bschaefer: Have you seen the unity MP and the bug report ?
[21:09] <MCR1> The problem is that Ctrl+Super+Down should restore a maximized window, but also minimize a non-maximized window
[21:09] <bschaefer> MCR1, hmm I just saw the compiz branch, and i haven't looked at the bug report :(
[21:10] <MCR1> ah okay - then everything is clear now :)
[21:12] <bschaefer> MCR1, o hmm, well Ctrl+Super+Down doesn't minimize a window for me :(
[21:12] <MCR1> please open CCSM->General
[21:13] <MCR1> there (in Key bindings tab) you should find the new shortcut
[21:13] <MCR1> try to change it and see if it works 100% then
[21:14] <MCR1> "Unmaximize or Minimize Window"
[21:14]  * bschaefer looks
[21:14] <MCR1> if you change it CCSM will warn if it collides with something else
[21:15] <MCR1> so we can exclude that
[21:15] <bschaefer> MCR1, oo i see, its Alt+F5 for me...
[21:15] <jibel> mterry, FYI, i reconfigured the indicator stack and verified the libdbusmenu is enabled.
[21:15] <bschaefer> MCR1, hmm well i just don't like having an OR in a name of a function :(
[21:17] <MCR1> probably it is some ubuntu patch that is missing then (which is changing shortcut keys) -> gotta find that -> I kept the default the same (did not even look what it was)
[21:18] <MCR1> the Alt+F5 problem
[21:19] <MCR1> I will have to change that to "Ctrl+Super+Down" ? then and remove "Ctrl+Super+Down" from the ubuntu distro patch also...
[21:20] <bschaefer> MCR1, well thats if its what is wanted, why don't we just have a toggle bool for having both?
[21:20] <MCR1> The Or in the function is somehow needed to describe what it does as it will Restore OR Minimize, depending on the state of the window
[21:20] <bschaefer> MCR1, 67	privateScreen.optionSetUnmaximizeWindowKeyInitiate (CompScreenImpl::unmaximizeWin);
[21:21] <bschaefer> does that function do the same thing that your function does?
[21:21] <bschaefer> minus the
[21:21] <MCR1> ups, typo
[21:21] <MCR1> sry
[21:21] <bschaefer> minimize?
[21:21] <MCR1> I'll fix it immediately
[21:21] <bschaefer> MCR1, wait, that function is already there...
[21:21] <bschaefer> MCR1, im just trying not repeat our selfs
[21:21] <MCR1> no it is not the same
[21:22] <bschaefer> MCR1, i mean does it do what half your function does...
[21:22] <MCR1> this will JUST restore
[21:22] <bschaefer> yes
[21:22] <MCR1> yes
[21:22] <bschaefer> which means that functions does half of what your does, which means we are repeating our selfs, which means we should step back and re think this
[21:22] <MCR1> I have re-thought this, but give me your idea
[21:23] <bschaefer> MCR1, so, instead of a function callback for what you want, can we have a toggle button to say minimize
[21:23] <mterry> jibel, thanks
[21:23] <bschaefer> MCR1, so we remove that other function that is there, and use your function
[21:24] <bschaefer> but check that the toggle is true before minimizing?
[21:24]  * bschaefer isn't sure how clear this is sounding
[21:25] <bschaefer> this way, the ctrl+super+down wont have to change anywhere, and we just have to put in the ubuntu patch to enable this feature by default
[21:27] <MCR1> bschaefer: I have found room for optimization, I could check for (w) only once, but I do not understand your toggle thing as this function is not toggling any state
[21:28] <bschaefer> MCR1, the toggling would be in CCSM (a bool)
[21:28] <MCR1> bschaefer: Ah, -> toggle behaviour
[21:28] <bschaefer> MCR1, and you would remove the other unmaximizewin function, and only use your own
[21:28] <bschaefer> yes, this way we don't repeat our selfs here
[21:28] <MCR1> the shortcut would have the same problem then...
[21:29] <bschaefer> and this way there will only be 1 shortcut you can do for this, but enable the minimizing feature
[21:29] <MCR1> the help overlay hint
[21:29] <bschaefer> MCR1, but we are going to enable this by default in ubuntu
[21:30] <MCR1> but if you toggle it off -> the shortcut hint will be false again
[21:30] <bschaefer> I just don't like implementing a whole new shortcut just to have a nicer wording in a shortcut overlay
[21:30] <bschaefer> and then we repeat our selfs in the code
[21:30] <MCR1> we are also adding functionality
[21:30] <bschaefer> urg, dam you shortcut overlay
[21:30] <bschaefer> DRY (Dont repeat yourself)
[21:30] <bschaefer> hmm
[21:32] <MCR1> it is a new, more powerful shortcut, than the old one -> used as default now in Ubuntu -> while for old-time Compiz users and their shortcuts nothing changes
[21:32] <MCR1> another advantage
[21:32] <bschaefer> but its doing 50% of the same thing...
[21:33] <MCR1> look at the others there -> all do 50% of some other function ;)
[21:33] <MCR1> but they are still not the same
[21:33] <bschaefer> this decision shouldn't be made based on the the overlay shortcut
[21:33] <bschaefer> hmm
[21:33] <bschaefer> yeah, but they should reuse that function :)
[21:33] <MCR1> no, I mean actions.cpp
[21:34] <MCR1> this would bring another problem
[21:34] <bschaefer> yes?
[21:34] <MCR1> CCSM does not allow 2 functions on the same key
[21:34] <MCR1> It would start rebelling LOUD
[21:34] <bschaefer> MCR1, we would be dropping 1 function key with how im imaging it
[21:34] <bschaefer> imagining
[21:35] <bschaefer> MCR1, also the OR should be an AND or THEN
[21:35] <bschaefer> really I like Then
[21:35] <bschaefer> but hmm
[21:36] <MCR1> bschaefer, if you worry about that bit of code duplication please take another look at actions.cpp and the other cases
[21:36] <bschaefer> yeah, Im worried to now :)
[21:36] <bschaefer> MCR1, it isn't much of a duplication anyway
[21:36] <MCR1> but you are right -> we can discuss the name and also the logic could be simplified a bit
[21:37] <bschaefer> Yes, im just trying to get the best readability,
[21:37] <bschaefer> so the problem with AND or THEN is it implies those happen at the same time so hmm
[21:38] <bschaefer> I personally don't like shortcuts that can do more then 1 thing
[21:38] <MCR1> yep, it is not easy to find a *short* name for it
[21:38] <bschaefer> (ie. the ShowDesktop has a problem with this as well)
[21:38] <bschaefer> MCR1, because a problem I see, is a semi max window, then your function will minimize it :(
[21:39] <MCR1> design wanted it that way (and IMHO makes sense in this case)
[21:39] <bschaefer> which some people will think hey, it should restore this!
[21:39] <bschaefer> s/will/may
[21:39] <MCR1> yep that is true
[21:39] <MCR1> and adjustable
[21:39] <bschaefer> i just don't like overloading to much on short cuts *cought* *cough* super
[21:40] <bschaefer> but can we check if its semi maxed?
[21:40] <MCR1> yep, hehe
[21:40] <MCR1> yep also
[21:40] <MCR1> the check is easy
[21:40] <bschaefer> cool, well if we add that check in, that should reduce confusion, from there it doesn't look to bad
[21:40] <bschaefer> its a small readable function
[21:40] <MCR1> but this was not part of the original bug and I did not want to change too much
[21:41] <bschaefer> well to me maxed and semi max share the same state of being maxed
[21:41] <bschaefer> MCR1, we can open a new bug about that
[21:41] <MCR1> yeah, I also think we should restore them then...
[21:41] <bschaefer> and get design to have input on it
[21:41] <MCR1> yeah probably we should
[21:41] <MCR1> :)
[21:42] <bschaefer> yup :), you can do it in a bit, so lets look at the function
[21:42] <bschaefer> one thing, is you check if (w) twice
[21:42] <MCR1> yep, noticed that
[21:42] <bschaefer> lets just check it once, then check which state it is
[21:42] <bschaefer> if (w) { if (max) else if (min) }
[21:42] <MCR1> yep - it is done that way in the toggle functions as well
[21:42] <MCR1> good point
[21:43]  * MCR1 is fixing
[21:43] <MCR1> I will have to find the Ubuntu patch that modifies the shortcuts also
[21:44] <MCR1> and remove the standard there
[21:44] <bschaefer> MCR1, and once you find the ubuntu patch, disable the old shortcut, and enable your new one with Ctrl+Super+Down
[21:44] <bschaefer> yeah
[21:44] <MCR1> yep
[21:44] <bschaefer> im not 100% sure where that is
[21:44] <MCR1> hehe
[21:44] <MCR1> I'll find it
[21:44] <MCR1> once I fixed all of that I'll ping you
[21:44] <bschaefer> alright :), i've seen it somewhere...it might be in a different branch
[21:44] <bschaefer> alright :)
[21:45] <MCR1> urgh - could you remove the shortcut then ?
[21:45]  * MCR1 hates those patches
[21:45] <bschaefer> hmm ill talk with duflu when he gets on
[21:46] <bschaefer> as he'll have to review it anyway
[21:46] <MCR1> I think I know where those are...
[21:46] <bschaefer> if its in a different branch
[21:46] <MCR1> yeah
[21:47]  * MCR1 is repeating himself: ***MCR1 hates those patches
[21:48] <bschaefer> yeeah, they are like dark magic ...
[21:49] <MCR1> *dark magic that tends to break and introduce bugs no coder ever finds the reason for... :P
[21:51] <bschaefer> yeah, well its hard to find a bug in the patches when you don't know the patches exists :)
[21:51]  * bschaefer spent a day doing just that
[21:52] <MCR1> I still have not succeeded in convincing the merger to accept my branch, because of some magic patch failures :P
[21:55] <bregma> more.  dark.  magic.
[21:56] <bschaefer> bregma, its everywhere
[21:56] <bregma> there wasn't a witch or wizard who went bad that hadn't patched compiz
[21:57] <MCR1> haha
[21:58] <MCR1> In reality we need a lot more wizards hacking on Compiz ;)
[22:03] <MCR1> bschaefer: Thinking about it - we probably should implement the same functionality for semi-maximized windows as well -> first restore -> then minimize
[22:03] <MCR1> bschaefer: Otherwise it would be inconsistent
[22:03] <bschaefer> MCR1, yeah, throw it in
[22:03] <MCR1> ok
[22:04] <bschaefer> it makes more sense to me
[22:04] <MCR1> yes
[22:04] <MCR1> good point (again)
[22:11] <MCR1> bschaefer: Found a new bug - haha
[22:11] <bschaefer> MCR1, sweet, what is it?
[22:12] <MCR1> bschaefer: Currently restoring semi-maximized windows does not work via shortcut
[22:12] <MCR1> it will first maximize
[22:12] <MCR1> and then restore
[22:12] <MCR1> as it is not recognized as maximized
[22:12] <bschaefer> MCR1, hmm it should though, because when you do a semi maxed window, then drag it, it restores
[22:12] <bschaefer> MCR1, hmm possibly look at how the draging from a semi maxed window works
[22:13] <MCR1> yeah - and fortunately for us the correct coordinates are saved
[22:14] <bschaefer> MCR1, I noticed, when doing a max, then doing a unmax, it doesn't restore it to its real state
[22:15] <bschaefer> MCR1, eek, and try this with your branch
[22:15] <bschaefer> MCR1, drag the window to a maxed state, then drag it away
[22:15] <bschaefer> it goes to the correct window state, then goes to the larger state
[22:16] <MCR1> toggle win maximized works here
[22:17] <MCR1> maximize->unmaximize as well
[22:17] <bschaefer> well im talking about draging it
[22:18] <bschaefer> it might not be your branch, but im noticing something odd with restoring windows
[22:18] <MCR1> grid needs more fixes
[22:18] <bschaefer> yeah, wasn't the grid fixed not to long ago?
[22:18] <MCR1> it is still in a bad state
[22:18]  * bschaefer just implemented a feature in there and this wasn't the case
[22:19] <MCR1> grid also works
[22:20] <MCR1> x and y size restore correctly with grid
[22:20] <mhall119> http://www.iloveubuntu.net/ubuntu-1304s-unity-demoed-and-available-installation-archlinux
[22:20] <bschaefer> mhall119, awesome!
[22:21] <bschaefer> MCR1, hmm well ill make a video
[22:34] <bschaefer>  /me ubuntu ones isn't working
[22:34] <bschaefer> meh
[22:35] <bschaefer> MCR1, umm so yeah, something for me is messed up with draging a maxed window to get it to restore
[22:35] <bschaefer> it flashes from its correct state it was before being maxed, to the size of the maxed window wiht out being maxed
[22:36] <bschaefer> MCR1, i sent you a video...
[22:40] <MCR1> bschaefer: I saw, but I do not know what to tell you... looks ugly
[22:41] <MCR1> looks like grid weirdness
[22:41] <bschaefer> MCR1, o well, i just didn't think you could repro it haha
[22:41] <bschaefer> yeah
[22:41]  * bschaefer isn't blaming your branch
[22:41] <MCR1> :)
[23:28] <MCR1> bschaefer: Everything ready (except the patching the ubuntu-config.patch in ubuntu/compiz/debian/patches)
[23:29] <bschaefer> MCR1, cool, Ill review the branch and talk to duflu when he gets around
[23:29] <MCR1> bschaefer: TBH, I do not know how to hack that patch without a bad hack ;)
[23:30] <bschaefer> :(
[23:30] <bschaefer> well Ill talk with duflu about it, hopefully he'll have some experience with it
[23:30] <MCR1> yes - he has for sure ;)
[23:33] <MCR1> unmaximize_window_key is in the file ubuntu-config.patch -> simply removing that manipulation of this key from the patch should be enough to make everything work smoothly *hopefully*
[23:33] <bschaefer> MCR1, well you'll have to make sure your new shortcut is disabled by default for compiz atm
[23:33] <bschaefer> (trunk that is)
[23:34] <bschaefer> and for the patch you'll have to make sure its pointed to Ctrl+Super+Down, because you can't change the default behaviour of compiz trunk
[23:34] <MCR1> I did not change default, because it was not there before ;)
[23:34] <MCR1> but I get your point
[23:35] <MCR1> so I'll clear it for now, and it will have to be added via this patch black magic later
[23:35] <bschaefer> well if the default behaviour is it isn't there, then it shouldn't be enabled :)
[23:36] <MCR1> yep, probably - it might collide with someone's other shortcut
[23:36] <bschaefer> dang, and you broke the ABI, now ill have to rebuild unity haha
[23:36] <MCR1> I wanted to ask if this will break the ABI...
[23:36] <MCR1> :-[
[23:36] <bschaefer> umm yes it will, but and you'll have to bump the ABI number
[23:37] <MCR1> ok, ack
[23:37] <bschaefer> i was mostly joking because i had built your branch, but some fixing you did changed it, so ill have to rebuild :)
[23:37] <bschaefer> hmm well actually I need to look at it some more, if you are just adding new functions then it might not
[23:42] <MCR1> ok - could you please test functionality again (with grid disabled) ?
[23:42] <MCR1> for the grid stuff I did some investigation also
[23:43] <MCR1> problem seems to be that core does not know about grid resized windows, just grid seems to do...
[23:43] <MCR1> but it needs further investigation
[23:43] <bschaefer> well if thats the problem, then for now we should just leave of the semi, and file a bug about it
[23:43] <MCR1> no, no problem with this branch as it is completely unrelated
[23:44] <MCR1> I just looked at grid if those windows also get a flag set
[23:44] <MCR1> and it seems they get one, but not globally (it seems)
[23:45] <MCR1> but this is completely unrelated to this branch
[23:45] <MCR1> but I would like to be able to restore grid windows via this shortcut also, which is currently not possible for those that are in the corners for example
[23:46] <MCR1> but - once again - this is unrelated to the shortcut, it is a problem that is reproducable in current trunk as well
[23:48] <bschaefer> alright
[23:48] <MCR1> for example: place a window via grid shortcut or mouse in a corner - now try to restore it with Ctrl+Super+Down -> does not work
[23:48] <MCR1> but will work with semi-maximized
[23:49] <MCR1> should work with all of them
[23:49] <MCR1> but that is another grid story...
[23:50] <MCR1> Does it work as intended ?
[23:51] <bschaefer> sorry, im looking at something else
[23:52] <bschaefer> MCR1, yeah, i've noticed that with semi max
[23:52] <bschaefer> MCR1, like you were saying, it doesn't think its maxed, so it mins it
[23:52] <MCR1> yep
[23:53] <MCR1> semimax *should* be fixed now
[23:53] <bschaefer> o nice, let me try that
[23:54] <bschaefer> MCR1, hmm you set your shortcut to ctrl+super+down?
[23:54] <bschaefer> as I have 2 shortcuts that are set to the same thing...
[23:55] <MCR1> in the latest version I've cleared the default, should be empty
[23:55] <bschaefer> its not for me, and we can't change the shortcut of another shortcut
[23:56] <MCR1> I have removed it
[23:57] <bschaefer> MCR1, we can't change the default behaviour...we have to change it in the patch
[23:57] <bschaefer> for ubuntu only
[23:57] <MCR1> sure
[23:57] <MCR1> I know
[23:57] <MCR1> It is empty in my MP :)
[23:58] <bschaefer> MCR1, hmm why is it set to Ctrl+Super+Down in the branch I compiled then...odd
[23:58] <MCR1> look at the diff -> no shortcut changed, none added -> https://code.launchpad.net/~mc-return/compiz/compiz.merge-fix966099-add-unmaximize-or-minimize-window-key/+merge/145464