[00:00] davidcalle: mhr3 paste-binned the missing gschema.xml file,I copied that into /usr/share/glib-2.0/schemas/org.compiz.unityshell.gschema.xml and re-ran glib-compile-schemas as root on that directory [00:01] mhall119, could you please paste the paste-bin link? [00:01] http://pastebin.com/e7UEugLi [00:02] mhall119, ty [00:04] np [00:20] fg [00:20] fg [00:22] mhall119, https://plus.google.com/117867558830601601230/posts/A7sAen7HRV7 \o/ [00:23] opps [00:23] * bschaefer keeps killing unity [01:00] * mhall119 is purging the staging ppa [01:00] too unstable atm [17:21] MCR1, yup, np. Though its always better to decrease the growth rate of the algorithm rather then change the linear speed of it :) [17:31] bschaefer: Do you know how it can be that my launcher can hide while the mousecursor still hovers over it ? [17:31] MCR1, yeah, I just fixed a few of those bugs... [17:32] if you click on an icon? [17:32] or exit scale more? [17:32] spread* i think [17:32] no, if I push to reveal with the mouse and stop moving the mouse once it is revealed [17:32] MCR1, yeah it should stay open [17:33] MCR1, do you have trunk? [17:33] * bschaefer updates trunk [17:33] yes, but I had that problem before your fixes, so do not worry [17:33] and still have it [17:34] MCR1, hmm so you just reveal the launcher then keep the mouse over it? Then it autohides? [17:34] maybe it is due to my special config - launcher on autohide, launcher just on main (left) monitor, 3 displays [17:34] yes exactly [17:34] bschaefer: There should be a condition added to NEVER hide the launcher if the mouse hovers over it [17:35] or is there ANY case it should hide then ? [17:35] MCR1, hmm I can't reproduce it, but there were some changes added to unity [17:35] MCR1, well there was an option added TO autohide when certain actions happened. One was an idle mouse [17:35] which I though I removed... [17:35] bschaefer: The last time I asked nobody could reproduce it either, but it is hunting me all the time ;) [17:36] MCR1, hmm it could be a multi monitor problem....hmm Ill have to see if I can reproduce it when I hook my laptop up to a second monitor [17:37] I also have this problem when just using 2 screens (3rd disabled) [17:37] what about 1 screen? [17:38] i'll try - one moment [17:40] still working on it - can be a pain to change displays sometimes... [17:41] have to reboot, brb [17:42] back [17:42] this time it worked :) [17:43] bschaefer: I can reproduce it with one monitor as well [17:43] * MCR1 is turning on sticky edges [17:43] MCR1, very odd...yeah let me know what config options you have on so I can try to reproduce it [17:43] does not change anything either [17:44] hmm are you on trunk unity? [17:44] bschaefer: yes, unity staging ppa and compiz ppa, both trunk [17:44] cause I swear I literally removed that entire option [17:44] MCR1, oo, i don't think my fix has landed in either of those haha [17:45] it was just merged this week [17:45] ie. bzr branch lp:unity -> is where the fix is at [17:46] haha [17:46] no staging should have it then as it rebuilds all the time [17:46] r2583 is the unity version I have [17:47] * bschaefer checks the rev [17:48] o [17:48] MCR1, well I did not know that haha [17:48] * bschaefer doesn't use staging ever [17:48] and the edges stopped being sticky as I just noticed [17:48] but the option in displays is still there [17:49] MCR1, would you be able to make a video showing the launcher autohide thing? [17:49] bschaefer: http://imagebin.org/225027 <- the option is still there [17:49] bschaefer: Don't you trust me ? ;) Yes, I could. [17:50] MCR1, I do, I just want to see whats going on :) [17:50] MCR1, that is also odd... [17:50] MCR1, ill have to test that out later [17:50] * MCR1 is launching kazam [17:50] gtk-recordmydesktop is pretty good [17:51] bschaefer: I jsut do not have an youtube account - where should I share the video ? [17:51] hmm email me it [17:51] umm [17:56] got it ? [17:57] bschaefer: ? [17:57] MCR1, yup, and odd! It looks like the launcher doesn't detect your mouse... [17:58] as you saw - if I move it a few pixels to the right it stops autohiding [17:58] MCR1, yeah, what resolution do you have? [17:58] though that shouldn't matter haha [17:58] 1920x1200 [17:59] I have another mousepointer as well, but that shouldn't matter either [17:59] hmm, that is indeed odd, did you change the size of your icons? [17:59] nope [17:59] wait what? You have 2 mouse pointers? [18:01] no, but two keyboards and two mice and an individual mousepointer (gfx only) - but this should not matter - after all I am also revealing the launcher with the mouse [18:01] and all other mouse-detection stuff works as well (corner detections in Compiz for example) [18:02] MCR1, well Im not with r2583...let me recompile [18:03] bschaefer: I bet you won't have this problem - but I have it since I remember [18:03] so how can this happen code-wise ? [18:03] MCR1, well it doesn't think the mouse is on the launcher :) [18:03] soooo it autohides [18:04] as you can see the launcher icons don't show their tool top [18:04] tip [18:04] they do [18:04] look at the video again [18:04] when it was autohiding right away it wasn't [18:04] I have demonstrated how I am able to maintain the launcher [18:04] yeah let me check...i just broke my ABI with unity sooo I have to recompile [18:05] I have to move the mouse a few pixels to the right - then it stops autohiding, tooltips work, quicklists work on right click (is not in the video) [18:06] MCR1, what im saying is when you had it move far to left and it was autohiding quickly the tooltips didn't show [18:07] MCR1, either way, it looks like the launcher thinks the mouse is outside the launcher... [18:07] bschaefer: I can even make the tooltip show and the launcher still disappears [18:07] hmm [18:07] well i still can't reproduce it :) [18:08] bschaefer: If I move the mouse over an icon, but just a few pixels from the edge, the tooltip appears, but the launcher still hides [18:08] MCR1, well that shouldn't happen... [18:09] I guess so (and it is quite annoying as you might imagine) [18:10] bschaefer: maybe the reveal shadow is over the launcher ? [18:10] yes, I would think....well I suppose you could file a bug and maybe someone else could reproduce it [18:11] and the pointer is detected over the shadow, which is over the launcher ? [18:11] MCR1, hmm I don't think the shadow is a window [18:11] the shadow is a png iirc [18:12] well it could be the problem though Im not sure where that is getting drawn in unity [18:12] for panel shadow is drawn using OpenGL [18:13] which is why I thought that launcher shadow was, which shouldn't cause it to block the mouse... [18:13] bschaefer: I do not want to steal more of your time, especially because this is just MCR specific and noone seems to be able to reproduce it... [18:13] MCR1, yeah, just file a bug :), and link the video [18:14] although I had this problem on all of my machines with precise as well :( [18:15] thats an old problem! [18:15] bschaefer: The best thing that should happen to the launcher would be an intellihide mode [18:16] but I do not mean dodge, but intellihide [18:16] all good launchers/docks have it [18:16] they just hide if the active window dodges [18:16] I think that use to be in... [18:16] * bschaefer isn't sure though [18:16] unity-2d was automatically acting that way as well [18:17] no it was just dodge [18:17] which means the launcher hid from every window [18:18] bschaefer: try docky or cairo dock and set mode to intellihide -> the launcher would be sooo much more useful [18:18] with this feature [18:19] MCR1, hmm yeah it would be nice, but I think any kind of window dodging was shot down [18:19] IIRC [18:19] I do not think this option was discussed (and I almost read the whole bugreport on it) [18:20] it was just -> give us dodge back [18:23] hmm well yeah it would be nice, but the problem your having would still be around [18:23] yeah sure - it was ot [18:23] ;) [18:52] Meh, Unity still isn't working in vmware. [18:53] Screen isnt drawing stuff properly, windows mix into each other, etc. [20:04] MCR1, btw i think you should read http://psankar.blogspot.cz/2011/03/pre-vs-post-increment-performance.html [20:10] mhr3: Interesting. [20:14] MCR1, bottom line with optimizations the two are equivalent for primitive types, for complex types it might still make some difference depending on how smart the compiler is [20:23] mhr3: Thanks for the summary. In my last merge request I also changed a primitive type to prefix, but in the previous ones (already merged) I just changed non-primitive types AFAIK. [20:24] MCR1, that's why i dug it out actually :P === 64MABS484 is now known as CookieM_