[06:43] <Mirv> didrocks: btw was the bamf/precise ok for uploading now?
[06:44] <didrocks> Mirv: well, I think you saw the activity about the other issues that I was kind of alone to deal with :) so not on the bamf thingy yet until we are fine on doing one unity release
[06:45] <Mirv> didrocks: sure, sure, no hurry
[06:45] <didrocks> Mirv: don't worry, you are in my opened tabs! Can you ask me again at the EOW please for safety? :)
[06:45] <Mirv> the big milestone is most important to achieve
[06:45] <Mirv> I hope your browser never crashes in a way that it loses tabs ;)
[06:45] <Mirv> EOW ok
[06:46] <didrocks> Mirv: well, it happens sometimes ;)
[06:46] <didrocks> Mirv: but TBH, I think I can reopen most of them by the history
[06:47] <didrocks> of course, there are maybe some collateral damage ):
[06:47] <didrocks> hence pinging back is nice!
[06:47] <didrocks> Mirv: oh, can you install ~ubuntu-unity/daily-build ppa please?
[06:47] <didrocks> (on raring of course)
[06:47] <didrocks> and shout if anything ugly happens?
[06:56] <Mirv> didrocks: will do
[07:07] <didrocks> smspillaz: FYI, there is no pressure from distro at all about this libmetacity thing
[07:30] <didrocks> mmrazik: I think not all projects are restarted yet, some approved stalled
[07:30] <didrocks> like on unity (https://code.launchpad.net/~3v1n0/unity/ups-empty-menu/+merge/136828)
[07:30] <mmrazik> didrocks: not sure what you mean by restarted but there was some power outage yesterday (again)
[07:30] <didrocks> maybe the things approved during the shutdown?
[07:30] <mmrazik> didrocks: its building
[07:30] <didrocks> ok :)
[07:30] <didrocks> just the backlog was too big?
[07:30] <didrocks> after the power outage
[07:30] <didrocks> or did you have to kick it to restart after this?
[07:31] <mmrazik> didrocks: I had to kick it after the restart. Something got suck there blocking everything else
[07:31] <mmrazik> didrocks: right now nux and compiz and unity are building
[07:31] <mmrazik> and there are 3 more builds for compiz queued
[07:31] <didrocks> mmrazik: excellent, then I can try to do a manual release :)
[07:32] <didrocks> which should unblock the universe and nexus 7 :p
[07:32] <mmrazik> didrocks: the compiz branches need to land in sequence so I think it will take a few hours...
[07:32] <didrocks> mmrazik: ok, no worry
[07:38] <smspillaz> didrocks: k, thx
[08:21] <Mirv> didrocks: so far so good with ppa:ubuntu-unity/daily-build on raring, not seeing anything out of place or crashing
[08:22] <didrocks> Mirv: sweet! do you see close button when you scale an app?
[08:22] <didrocks> like open 2 nautilus windows
[08:22] <didrocks> click on the launcher
[08:22] <didrocks> normally when you hover the 2 windows opened, you can see the close button
[08:22] <Mirv> didrocks: yes, I see it
[08:22] <Mirv> and it works
[08:22] <didrocks> interesting, for me, they work but I don't see them :)
[08:23] <didrocks> thanks Mirv! Do not hesitate if you see anything bad
[08:23] <Mirv> sure, I'll let you know immediately if I notice something bad
[08:46] <popey> didrocks, i get a close button, but on the foreground window I also see the titlebar with the buttons in the titlebar of the hovered app.. sometimes.. hard to trigger http://popey.com/~alan/titlebar.png
[08:46] <didrocks> popey: ah, even funnier :)
[08:46] <davidcalle> popey, confirming
[08:46] <didrocks> I wonder why I don't get the close button at all
[08:46] <didrocks> ever never ever
[08:46] <didrocks> hey davidcalle!
[08:46] <didrocks> davidcalle: can you please install ~ubuntu-unity/daily-build
[08:46] <popey> thats a guest session though.. dunno if that makes a difference?
[08:46] <didrocks> and warn/poke me if anything bad is happening :)
[08:46] <didrocks> popey: let me try
[08:47] <popey> open two nautilus, then open a terminal and close the terminal, then click nautilus in launcher
[08:47] <popey> seems to reproduce it
[08:48] <didrocks> popey: it is indeed working in a guest session
[08:48] <davidcalle> didrocks, hey. Ok.
[08:48] <didrocks> popey: I tried what you say, but doesn't reproduce
[08:48] <didrocks> davidcalle: thanks! (on raring ;))
[08:49] <popey> yeah, it doesn't always happen
[08:49] <didrocks> let's hunt for Trevinho once he's around :)
[08:49] <popey> roger roger
[08:49] <didrocks> but not a first daily-release blocker
[08:49] <popey> nah
[08:49] <didrocks> (I'm not relying on autopilot for it yet though, hence the dogfooding)
[08:49]  * popey hunts for more
[08:49] <didrocks> heh ;)
[08:51] <popey> didrocks, http://popey.com/~alan/unreadable_close.png
[08:51] <popey> bottom right window, the close button overlay is unreadable
[08:52] <didrocks> ah, so not he back black fake title bar
[08:52] <popey> yeah
[08:53] <popey> seems not to resize properly
[08:53] <didrocks> there is really something… some elements don't appear randomly
[08:53] <didrocks> popey: oh it doesn't resize
[08:53] <didrocks> popey: it's a fake, it overlays :p
[08:53] <popey> ah, thats why you can see through on my first screenshot then, yes
[08:53] <didrocks> yeah
[08:53] <popey> its just not appearing
[08:53] <didrocks> I thought it was opaque
[08:53] <didrocks> but it's not :)
[08:54] <popey> whenever i want to open shotwell from the dash, it wants me to buy shot glasses, this can't be good for me
[08:54] <didrocks> popey: ahah, you can argue "but but, it was proposed to me, I needed them for sure!" :)
[08:54] <popey> true!
[08:54] <popey> blame mark
[08:55] <popey> there's a lawsuit in there somewhere
[08:55] <didrocks> heh
[09:02] <popey> didrocks, open two apps, one full screen (e.g. shotwell) and another windowed (e.g. gimp). Click shotwell in launcher, get shotwell full screen. Want to go to a menu in gimp, click gimp in launcher, gimp comes to front. Now without clicking on the gimp window at all, hover over the menu bar, it flicks back to shotwell..
[09:02] <popey> (if you click on the menu)
[09:02] <popey> annoying but not a showstopper IMO
[09:03] <didrocks> popey: convoluted enough to not be a showstopper I guess :) but worth a bug and a ping to bregma :)
[09:28] <didrocks> FYI all: unity stack rebuild for first release into raring in progress :)
[09:29] <duflu> didrocks: My preview of it looks like the old one, minus bugs. But that's good :)
[09:30] <didrocks> duflu: heh, sweet! :)
[13:15] <Trevinho> popey: mhmh... weird
[13:18] <Trevinho> popey, didrocks: never got it here... Mhmhm... the first one it's just probably an opacity issue... But the 2nd...
[13:19] <didrocks> Trevinho: I never have the close buttons here
[13:19] <Trevinho> popey: do you get issues also on the Alt+Tab spread? (i.e. doing Alt+` or alt+tab + down-arrow)?
[13:19] <didrocks> Trevinho: clicking on where they are supposed to be works though
[13:19] <Trevinho> didrocks: mhmh... it could be a problem related to textures loading, I've heard something related to that some time ago
[13:19] <popey> Trevinho, no, spread is fine
[13:20] <popey> this is an intel hd2000 video card, so low-end i7
[13:20] <Trevinho> popey: wierd, it's really the same code-path
[13:20] <didrocks> Trevinho: how can I give you the debug info you need? :)
[13:23] <Trevinho> didrocks: try to put a SetupSharedTextures() above the line with "switch (close_icon_state_)"...
[13:24] <didrocks> Trevinho: will do, not right now as I'm releasing unity, but after, I'll give it a shot :)
[13:39] <didrocks> mmrazik: sil2100: hey, do you know where the autopilot tests results are stored?
[14:23] <mmrazik> didrocks: srry.. missed this again. What do you mean where they are stored. The physical xml files?
[14:23] <didrocks> mmrazik: yeah, once autopilot ran
[14:24] <didrocks> on the machine
[14:24] <mmrazik> didrocks: ~jenkins/results/testresults
[14:24] <didrocks> mmrazik: thanks :)
[14:26] <didrocks> fginther: hey! oh, it seems you implemented the fact to merge the changelog-change only without a rebuild, right?
[14:27] <mmrazik> didrocks: I don't think so as I didn't see any MP....
[14:28] <didrocks> mmrazik: hum? weird that's it's merging all my MP for the unity release blazing fast then
[14:28] <didrocks> mmrazik: even if I sent 10 of them
[14:28] <fginther> didrocks, no, that was put on the todo list as it was not a blocker...
[14:28] <mmrazik> didrocks: I was surprised too
[14:28] <didrocks> so you have maybe another issue where the package isn't built? :p
[14:28] <fginther> didrocks, this is for lp:unity?
[14:29] <didrocks> the whole stack
[14:29] <mmrazik> fginther: I checked the logs (randomly). The build is there
[14:31] <fginther> didrocks, the lens generally build in under 10 minutes
[14:31] <didrocks> yeah, but seeing the amount of requests I had, I'm *shocked* (in the good way ;))
[14:31] <fginther> :-)
[14:46] <didrocks> fginther: mmrazik: seems the bamf test is flacky again
[14:46] <didrocks> I'll merge the changelog by end if you don't mind
[14:47] <fginther> didrocks, grumble, I'll ping somebody about that bamf bug again
[14:48] <didrocks> fginther: thanks, workaround meanwhile :)
[14:56] <fginther> Trevinho, ping
[14:56] <Trevinho> fginther: pong
[14:57] <fginther> Trevinho, can you find someone to take a look at https://bugs.launchpad.net/bamf/+bug/1079329?  It's become a blocker for autolanding bamf
[14:59] <Trevinho> fginther: I see there was someone working onit
[15:00] <Trevinho> fginther: ah, probably you was :)
[15:00] <oml> hello everyone. im trying to figure out how unity works on a broad scale, which processes start the others, how they communicate etc. currently im digging through the src-package of unity and try to understand what "UBusMessage.h" does, or the ubus-server
[15:00] <oml> naming reminds one of dbus, does ubus work the same way? or does it something entirely else?
[15:00] <Trevinho> fginther: isn't your way working?
[15:01] <fginther> Trevinho, I tried a couple of experiments, but ran into another problem
[15:01] <fginther> I'll try to find a log
[15:04] <fginther> Trevinho, here's a log from one of my tests: http://paste.ubuntu.com/1412623/
[15:38] <Trevinho> fginther: can't we just ignore the return value of kill?
[15:40] <fginther> Trevinho, there shouldn't be any harm. I can give it a try
[15:42] <fginther> Trevinho, do you know what causes the "WARNING **: Couldn't register with accessibility bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken."?
[15:42] <Trevinho> fginther: I think it's caused by the fact that running the test in a fake xserver the atk bus is not present
[16:06] <mmrazik> didrocks: FYI -- the nux build takes ~4h (due to arm). Your branch is building, it will just take some time
[16:06] <didrocks> mmrazik: no worry, thanks!
[16:11] <mmrazik> I'll move the builds to pandas tomorrow
[16:31] <MCR1> didrocks: Hi. Are you sure all build-dep are now in lp:unity ? The last time I tried to get the build-dep, the build was failing, because libxcb-dri2-0-dev was missing...
[16:31] <didrocks> MCR1: well, it's building on the ppa :)
[16:31] <MCR1> yeah, sure... but still strange...
[16:36] <MCR1> smspillaz: Hi :) 1. Thanx 4 the reviews. 2. Q: Do you think it might make sense to use register int iterators for huge for loops ?
[16:37] <didrocks> mterry: I just pushed that to distro, quick review? https://code.launchpad.net/~didrocks/bamf/remove-unexisting-dep/+merge/138242
[16:46] <didrocks> mterry: oh, btw, you need to change the global status for https://code.launchpad.net/~didrocks/unity/refresh-build-deps/+merge/138227
[16:46] <didrocks> approving in a comment isn't enough
[17:02] <didrocks> sil2100: can you change the global status as well? :)
[17:02] <sil2100> didrocks: ok ;)
[17:02] <didrocks> thanks!
[17:02]  * sil2100 wanted to give some time for someone else to ACK it as well ;p
[17:03] <sil2100> But this is an obvious change
[17:03] <didrocks> yep :)
[17:03] <sil2100> Something that was bothering everyone since looong time
[17:58] <smspillaz> MCR1: not really, as daneil said micro-optimizations don't help much
[17:58] <MCR1> yeah, probably you are right
[17:59] <smspillaz> MCR1: the best thing to do if you want to improve performance is to do profile guided optimization
[17:59] <MCR1> I saw your new branch (actually I am testing it)
[17:59] <MCR1> Top news !
[17:59] <smspillaz> eg, run it through callgrind
[17:59] <MCR1> 20->30 == + 50%
[17:59] <MCR1> that sounds great
[17:59] <smspillaz> MCR1: actually, I just found the cause of the extremely poor performance when moving opengl windows around
[17:59] <MCR1> yeah
[18:00] <smspillaz> 1) unfortunately its not easy to fix and 2) I really think nvidia should just fix it on their end, there's no reason why it should be like that
[18:00] <MCR1> I am using ATI (currently with latest fglrx)...
[18:01] <MCR1> but window moving is not fully smooth here either
[18:01] <smspillaz> yeah I think fglrx sends theiir command stream over the protocol too
[18:01] <smspillaz> MCR1: try commenting out line 848 in plugins/composite/src/screen.cpp  too
[18:02] <smspillaz> I think that's the only other point where do a flush/wait lots
[18:02] <MCR1> with framebuffer object enabled it stutters more than without, where it is almost fully smooth (with some minor pulsing)
[18:02] <smspillaz> MCR1: which card did you have ?
[18:02] <MCR1> with both fglrx and gallium
[18:02] <MCR1> HD 5750
[18:02] <smspillaz> MCR1: resolution ?
[18:02] <MCR1> 1920x1200+1280x1024
[18:03] <MCR1> or 1920x1200+1920x1080
[18:03] <smspillaz> wouldn't be suprised if we were maxing out the fillrate
[18:04] <smspillaz> unfortunately there's not much we can do - getVideoSync / waitVideoSync require you to block the graphics pipeline and glXSwapBuffers necessarily means that you have to redraw the entire backbuffer on every frame
[18:04] <smspillaz> DRI3 will help that a lot
[18:04] <MCR1> How can I force the compiled Compiz in the staging dir force to use my config ?
[18:04] <smspillaz> MCR1: did you actually install it anywhere ?
[18:04] <smspillaz> or are you just running it from /src/
[18:04] <MCR1> yes to staging
[18:04] <smspillaz> cause that won't work
[18:04] <smspillaz> compiz --replace ccp ?
[18:04] <MCR1> installed
[18:04] <smspillaz> or at least
[18:05] <smspillaz> PATH=/home/user/staging compiz --replace ccp &
[18:05] <smspillaz> might need to set your LD_LIBRARY_PATH too
[18:06] <MCR1> ah, maybe that is what I'm missing as CCSM opens with all my settings correctly enabled, but the freshly compiled Compiz runs without them...
[18:06] <MCR1> so it is hard to compare the performance
[18:06] <smspillaz> #1 reason why I hate fixing performance things
[18:06] <smspillaz> "I made it go from 20FPS to 30FPS!"
[18:07] <smspillaz> "still too slow not fixed"
[18:08] <MCR1> 20->30 sounds awesome
[18:08] <smspillaz> time for me to sleep though
[18:09] <smspillaz> I'll have a look into the opengl related thing tomorrow, I have an idea for that maybe it will work maybe it wont
[18:09] <MCR1> hmm, strange - I've set LD_LIBRARY_PATH...
[18:10] <MCR1> I will retry forcing compiz to load all plugins
[18:16] <MCR1> haha, I've started the wrong CCSM...
[19:53] <mdeslaur> MCR1: hi! What would it take to bribe you into fixing one of my pet-peeve compiz bugs? :)
[19:53] <mdeslaur> MCR1: bug 1037164
[20:18] <MCR1> mdeslaur: How do you "snap it" ? Via keyboard or mouse ?
[20:18] <mdeslaur> oh, I just drag the terminal to the right edge of the screen, and it sticks to the edge
[20:19] <mdeslaur> it's the default compiz snapping windows plugin
[20:19] <mdeslaur> but even if I disable that plugin, as long as the window is a few pixels close to the edge of the screen, it happens
[20:19] <mdeslaur> MCR1: are you not able to reproduce it?
[20:19] <MCR1> hmm, I was not aware that there are still problems with mouse snapped windows...
[20:20] <MCR1> I have to try in a VM
[20:20] <MCR1> it is Grid you are talking about
[20:21] <mdeslaur> no, not grid
[20:21] <seb128> MCR1, it's trivial to trigger, go to a ws, snap something to the right of the screen, go back to ws1, click on it in the unity launcher
[20:21] <seb128> the win is moved a bit over
[20:21] <mdeslaur> as long as a window is within a few pixels from the right edge of workspace 2, the problem happens
[20:21] <seb128> so you have a border on ws1 and the remaining part where you were
[20:23] <MCR1> mdeslaur, seb128: Uh, not nice indeed...
[20:25] <MCR1> Indeed, grid is not needed to trigger the bug...
[20:31] <mdeslaur> MCR1: there seems to be some details in one of the duplicate bugs here: https://bugs.launchpad.net/unity/+bug/834248/comments/29
[20:32] <MCR1> mdeslaur: Yeah, that seems very useful indeed. :)
[20:40] <MCR1> mdeslaur: I can reproduce the issue running yesterday's Raring in a VM, but not when using my 4x1 config.
[20:41] <mdeslaur> interesting
[20:42] <MCR1> But I can also reproduce it using Raring and 4x1 desktop config
[20:44] <MCR1> haha, I never saw this bug before, because I've deactivated Desktop Wall
[20:50] <mdeslaur> I've been hitting it 20 times a day since natty :P
[20:50] <mdeslaur> it's diving me insane :P
[20:51] <MCR1> Sure, the worst things are windows that jump around on their own...
[20:52] <MCR1> You could ofc workaround this special bug, by disabling Desktop Wall and working with the Cube and Expo instead
[20:53] <MCR1> but you would have to change your config quite a bit and change workspaces from 2x2 to 4x1...
[20:53] <MCR1> ofc fixing this bug would be a lot better
[20:53] <mdeslaur> hrm, yeah...it's bad that it's been broken this long in the default configuration
[20:56] <MCR1> the problem is that bugs of this kind seem to be extremely hard to fix - but I'll try (I am currently working on bug 1082001 which is also making windows move across workspaces)
[20:57] <MCR1> This one kills grid keyboard functionality if one wants to work with different workspaces...
[21:11] <mdeslaur> ah, another nice one :)
[21:34] <fginther> bschaefer, can you recommend someone to review this: https://code.launchpad.net/~fginther/nux/add-code-coverage/+merge/138007
[21:35] <bschaefer> fginther, I can look at it...I don't think any other people are around for nux...possibly andyrock :)
[21:36] <fginther> bschaefer, it's not urgent, so if it's better that someone review it tomorrow, I'm fine with that
[21:37] <bschaefer> fginther, alright, well if I can test it, and check things are still working with nux I can approve it :)
[21:37] <fginther> bschaefer, cool!
[21:38] <MCR1> mdeslaur: Time for a test ?
[21:38] <mdeslaur> MCR1: sure!
[21:39] <MCR1> please create a directory named compiz-1 in ~
[21:39] <bschaefer> fginther, so this is for jenkins to get reports from nux pretty much?
[21:39] <mdeslaur> MCR1: ok
[21:39]  * bschaefer hopes he has gcov
[21:39] <MCR1> in compiz-1 create another directory called plugins
[21:39] <fginther> bschaefer, that's the goal, a developer can also run coverage-html to get their own results
[21:40] <bschaefer> fginther, cool, ill do that to test it out, and run some other tests
[21:40] <bschaefer> fginther, it doesn't seem like this touches other code, or really effects nux unless you have --enable-gcov which is good
[21:42] <MCR1> mdeslaur: Download this file: https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1037164/+attachment/3452533/+files/libwall.so and put it in ~/compiz-1/plugins
[21:43] <MCR1> mdeslaur: Now open a terminal and run setsid unity (be sure you are using 12.10 ?)
[21:44] <mdeslaur> yes, I'm on 12.10
[21:44] <MCR1> ok
[21:45] <MCR1> please test and report
[21:45] <mdeslaur> same thing, unfortunately...how do I tell it actually loaded that file?
[21:46] <bschaefer> fginther, Scanning . for .gcda files ...
[21:46] <bschaefer> geninfo: ERROR: no .gcda files found in .!
[21:46] <bschaefer> should I be doing something else before doing coverage-html?
[21:46] <MCR1> if you ran setsid unity it will load the file (be sure that it is in yourhomedir/compiz-1/plugins)
[21:47] <mdeslaur> yes, it's there
[21:47] <fginther> bschaefer, did you do 'make check' or 'make check-headless' first?
[21:47] <bschaefer> fginther, nope ... let me do that
[21:48] <MCR1> named libwall.so, yes ?
[21:48] <bschaefer> fginther, possibly adding make-check-headless to the coverage-html?
[21:48] <fginther> bschaefer, I open to suggestions if there is a smarter way to do that...
[21:49] <mdeslaur> MCR1: yep
[21:49] <bschaefer> or I suppose that would get run how you'll be doing that
[21:49] <MCR1> grmpf
[21:49] <bschaefer> fginther, hmm
[21:49] <fginther> bschaefer, I didn't want to force 'make check' or 'make check-headless'
[21:49] <bschaefer> yeah
[21:49] <bschaefer> fginther, maybe adding another option that doe force it?
[21:49] <fginther> but it's not obvious how to collect coverage either
[21:50] <bschaefer> make check-coverage-html?
[21:50] <bschaefer> hmm
[21:51] <fginther> bschaefer, I can add some make targets to make it easier
[21:52] <bschaefer> fginther, yeah, as make check or make check-headless needs to be ran before doing the coverage
[21:52] <MCR1> mdeslaur - it is .compiz-1 !!!
[21:52] <fginther> bschaefer, ok, I'll figure something out
[21:52] <bschaefer> fginther, or possibly some how adding an error message
[21:52] <MCR1> he's gone...
[21:52] <bschaefer> if no .gcda files were found...
[21:53] <bschaefer> fginther, or you can make a comment in there, Im not the best with makes files haha
[21:54]  * bschaefer needs to fix the make check FTBS
[21:54] <MCR1> mdeslaur: I was giving you wrong directions
[21:54] <MCR1> mdeslaur: Please rename compiz-1 to .compiz.1 ;)
[21:55] <MCR1> and run setsid unity again - sorry
[21:55] <mdeslaur> .compiz-1 or .compiz.1?
[21:55] <seb128> .compiz-1 no?
[21:55] <MCR1> .compiz-1/plugins
[21:55] <seb128> mdeslaur, just copy over the system .so and restart compiz
[21:55] <MCR1> no need to f*ck up the system
[21:56] <seb128> you can always --reinstall the package to get back to normal state
[21:56] <MCR1> true that
[21:56] <seb128> MCR1, it's easier to cp away and back the system one that to figure the .compiz
[21:58] <MCR1> mdeslaur: Now tell me that it worx
[21:58] <mdeslaur> hah, compiz didn't enjoy me copying over the .so while it was loaded :P
[22:01] <MCR1> bschaefer: Hi, btw ;) I also have (easy) work 4 u...
[22:01] <bschaefer> MCR1, hello, link me
[22:01] <bschaefer> if its a review :)
[22:01] <MCR1> yep, 1. https://code.launchpad.net/~mc-return/unity/unity.merge-reduce-scope-of-variables.2/+merge/137949
[22:02] <MCR1> 2. https://code.launchpad.net/~mc-return/nux/nux.merge-reduce-the-scope-of-various-variables/+merge/134787
[22:04] <mdeslaur> MCR1: copiz just dies when trying to open that .so...could you please just give me the patch to try?
[22:04] <bschaefer> MCR1, hmm well I just approved the first one but..hmm
[22:04] <bschaefer> MCR1, 111	[22:05] <bschaefer> you are messing with C files, and the standard for C files are to define things at the top
[22:05] <MCR1> I think it depends if it is C89 or C99, but I can revert the .c file changes
[22:06] <MCR1> but if it complies it worx
[22:06] <bschaefer> MCR1, I think it would be best for the C, and its ansi I believe
[22:06] <bschaefer> but i would prefer to keep to C looking like C
[22:06] <MCR1> bschaefer: ok
[22:06] <bschaefer> MCR1, thank you :)
[22:06] <MCR1> bschaefer: I'll change that then...
[22:07] <MCR1> thanx 4 the review
[22:08] <MCR1> mdeslaur: More or less I tried his solution: https://launchpadlibrarian.net/89746102/fix-762335.patch
[22:08] <mdeslaur> MCR1: and it worked for you?
[22:08] <bschaefer> MCR1, your second one looks good and is approved :)
[22:09] <MCR1> mdeslaur, I did not try yet, as it would mess up my whole config (I am using the cube, not wall those conflict with each other), but I'll try later...
[22:10] <mdeslaur> MCR1: ok, I'll build it locally and try it too
[22:10] <MCR1> bschaefer: For nux not all of the scopes are reduced yet, so there will be a Part 2 ;)
[22:10] <MCR1> mdeslaur: Cool, please report
[22:17] <MCR1> bschaefer: Should be fixed
[22:17] <bschaefer> MCR1, awesome thank you!
[22:18] <MCR1> your fast help is awesome ;)
[22:18] <bschaefer> MCR1, nux needs a bit more help in parts :)
[22:18] <MCR1> you know - I am just a newbie struggling with all this C++ complexity :-D
[22:19] <bschaefer> haha, it takes time
[22:20] <bschaefer> MCR1, also what you think should happen...when you grab a window then use the keyboard to change workspaces?
[22:20] <bschaefer> what do*
[22:20] <bschaefer> just the normal Ctrl+Alt+<arrow>
[22:21] <MCR1> the window should move to the new workspace together with the mousepointer and the new workspace should be selected
[22:21] <MCR1> imho
[22:21] <bschaefer> MCR1, yeah, I find it odd that a huge gab is now present
[22:22] <bschaefer> gap*
[22:22]  * bschaefer looks if a bug for that exists
[22:23] <MCR1> the real problem is that Ctrl+Alt+Cursor + grabbing a window with the mouse is hard to achieve with 2 hands... :P
[22:23] <MCR1> I am really struggling to get this done ;)
[22:23] <bschaefer> haha
[22:24] <bschaefer> i would never imagine it really happening, I was just looking at that other wall/gap bug
[22:24] <MCR1> ah, yeah - the gap
[22:24] <bschaefer> its fixed in 0.9.8, but not in 0.9.7 so im digging through to find what fixed it
[22:24] <bschaefer> to see if it can be backported
[22:25] <MCR1> it is still present here, btw... (without the wall)
[22:25] <bschaefer> MCR1, in 0.9.8?
[22:25] <bschaefer> and with out wall how are you dragging it to another workspace
[22:25] <MCR1> when I grab a window and switch from workspace to workspace to workspace to workspace...
[22:25] <MCR1> I can make the cursor move from its position
[22:25] <bschaefer> MCR1, just dragging it?
[22:26] <MCR1> I am using the cube instead
[22:26] <bschaefer> shoot...I never use that plugin
[22:26] <MCR1> no, dragging on the same workspace is fixed 100%
[22:26] <bschaefer> MCR1, that is what the bug is talking about
[22:26] <bschaefer> open another bug if you could :)
[22:27] <MCR1> maybe this +/- 10 pixel thingy is hidden somewhere else also...
[22:28] <bschaefer> MCR1, hmm well it hasn't reached 0.9.8 yet
[22:28] <bschaefer> so if you bzr branch lp:compiz/0.9.8
[22:28] <bschaefer> the -10 is still there, or at lease it was yesterday
[22:28] <MCR1> I am running trunk of everything (unity staging PPA)
[22:29] <bschaefer> but the problem in 0.9.7 is waaay more then just a -10
[22:29] <bschaefer> it seems to mess up on screen->vp().x()
[22:29] <bschaefer> or it seems to be missing that somewhere
[22:30] <bschaefer> I think it was just backported this morning (for me at lease), the -10 fix
[22:30] <MCR1> I can reliably reproduce it when moving the window to the left from workspace to workspace
[22:30] <MCR1> but not when moving it to the right
[22:30] <bschaefer> just the -10?
[22:30] <bschaefer> just a little at a time
[22:31] <bschaefer> MCR1, it is also UP but not DOWN
[22:31] <bschaefer> that you can do it
[22:31] <bschaefer> (if you are using a 2x2)
[22:31] <MCR1> yes, I am using 4x1 and it is minor and does not happen every time I move to the left...
[22:31] <MCR1> strange indeed
[22:32] <bschaefer> MCR1, it has to be the -10, as after that was removed it was perfect for me
[22:32] <bschaefer> if you grab the top left corner of the window
[22:33] <bschaefer> MCR1, well either way, Im looking for the larger problem :)
[22:34] <bschaefer> the one in 0.9.7
[22:34]  * bschaefer goes off to hunt for it
[22:42] <MCR1> good luck
[22:48] <bschaefer> thanks
[23:24] <krabador> hi, people, have unity some special automatic resolution setting?