[03:15] <blakep> Is anyone here?
[04:47] <sidi> Can anyone explain to me what's the difference between Unity starting from the lightdm/unity greeter and unity --advanced-debug on a cleanslate X? I've got a compiz crash that I can't reproduce with --advanced-debug, apparently occurring on dl_init (so I presume when Compiz launches some Unity code), and I don't know how to reproduce the exact same execution envt with an interactive gdb session
[08:18] <everjeje> Hi. Just found a strange behaviour: having the sound settings window open and on top of the rest of the windows, whenever another application triggers a sound effect (like Thunderbird's "new email" sound), the sound settings window will increase it's size (some 30 pixels on the y-axis) while the sound is playing. It will go back to normal after the sound
[08:18] <everjeje> finishes playing.
[10:14] <tsdgeos> mzanetti: https://code.launchpad.net/~aacid/unity8/margins_contribute_to_display_margin/+merge/258854
[10:15] <tsdgeos> at some point we really need auto tests for the display margin stuff
[10:15] <tsdgeos> because we have none at the momeny _/
[10:16] <mzanetti> tsdgeos, thanks
[10:17] <mzanetti> tsdgeos, is this branch missing a prereq?
[10:17] <tsdgeos> ah
[10:17] <tsdgeos> it is
[10:19] <tsdgeos> mzanetti: now, https://code.launchpad.net/~aacid/unity8/margins_contribute_to_display_margin/+merge/258855
[10:23] <mzanetti> tsdgeos, can you create a trello card for the margin tests please
[10:23] <mzanetti> approved the branch. fixes my nichtlustig scope
[10:35] <MacSlow> mzanetti, btw... updated my shellRotation branch with elopio's suggestion regarding QV4_ENABLE_JIT_CACHE
[10:36] <tsdgeos> MacSlow: i disagree with that
[10:36] <tsdgeos> and if we need it, it's showing some other problem in the JIT cache than that bug
[10:37] <tsdgeos> because the problem described with the JIT cache in that bug is that when changing libraries it doesn't clean itself
[10:37] <tsdgeos> what you said yesterday is that even once updated
[10:37] <tsdgeos> between different runs it'll crash
[10:37] <MacSlow> tsdgeos, I can't fix the QML-cache issues just like that... but also don't want to see shellRotation be blocked for ages due to out-of-scope bugs
[10:38] <tsdgeos> MacSlow: i actually do if you are saying that just running the branch with a cache of the same branch makes it crash
[10:38] <tsdgeos> because that is what the phone does
[10:39] <tsdgeos> maybe i didn't understand what you said
[10:40] <MacSlow> tsdgeos, it can crash... it doesn't always happen... and we're being hurt by the qml-cache bug more, because we're using scenarios now for the shellRotation ap-test, which cause multiple unity8 stop/start-cycles (thus qml-cache being recreated, if it was wiped before)
[10:40] <cimi> tsdgeos, after we submit a review in the edit review branch, shall it go back to edit review?
[10:40] <tsdgeos> MacSlow: what does it matter that we start/stop unity8?
[10:40] <tsdgeos> the cache is the same of the code it is
[10:40] <tsdgeos> so it is a good cache
[10:41] <tsdgeos> you don't need to ignore it/wipe it
[10:41] <tsdgeos> cimi: sorry i don't understand what you mean, can you rephrase?
[10:41] <MacSlow> tsdgeos, I've seen otherwise
[10:42] <tsdgeos> MacSlow: then report a bug
[10:42] <tsdgeos> because the bug you're linking is *not* about that
[10:42] <tsdgeos> you're basically saying the qml cache is crashy and should be always disabled
[10:42] <MacSlow> tsdgeos, I would have it I had a consistent reproducable test-case
[10:49] <tsdgeos> MacSlow: still you have it crashing i'm concerned that what you're doing is basically workaround the test
[10:49] <tsdgeos> by making it do not what the real world will do
[10:49] <tsdgeos> so we'll have crashes in real world
[10:49] <tsdgeos> is that what we want?
[10:50] <MacSlow> tsdgeos, no... we want qml-cache to be flawless of course... but I can't do that fix... on the other hand we want to move forward with shellRotation... thus this is my compromise
[10:50] <tsdgeos> your compromise is merging something that will crash randomly
[10:51] <tsdgeos> ok
[10:54] <MacSlow> tsdgeos, in the end it's mzanetti's call, if it'll move in or not.
[10:56] <mzanetti> well, tsdgeos is right in what he's saying...
[10:59] <mzanetti> MacSlow, why is this only an issue with that shellRotation branch? do you know that?
[10:59] <cimi> tsdgeos, I tried with make tryPreviewEditReview
[11:00] <cimi> tsdgeos, but after I submit it doesn't go back to the beginning, with the edit button
[11:00] <MacSlow> mzanetti, I've never seen this causing issues elsewhere (with other tests qml or autopilot)
[11:01] <mzanetti> yeah, the question is *why*
[11:02] <MacSlow> mzanetti, do you imply me hunting for the reason? :)
[11:03] <tsdgeos> cimi: ah, i see what you mean
[11:03] <tsdgeos> pstolowski: so what happens after the user triggers the edit button, do you send a new preview model?
[11:04] <pstolowski> tsdgeos, not the edit button, but send; yes, a new preview is returned
[11:04] <tsdgeos> right sorry
[11:05] <tsdgeos> pstolowski: so we don't actaully need to go back to "display" mode since you're doing it for us
[11:05] <tsdgeos> good :)
[11:05] <tsdgeos> cimi: ↑↑
[11:06] <pstolowski> tsdgeos, right. also that ensures what we actually show is what server has (e.g. the updated review)
[11:11] <cimi> tsdgeos, cool
[13:04] <kgunn> tsdgeos: i see you've got the inline audio card...what's the current thinking on that in terms of design etc
[13:05] <kgunn> before i left, design was sort of nowhere, and JoeO was asking if we could just reuse the playback controls from
[13:05] <kgunn> the indicator panel, and plop them into the dash view
[13:06] <tsdgeos> we don't have playback controls on the dash
[13:06] <tsdgeos> do we?
[14:23] <dandrader> tsdgeos, do you care about the default size of units.gu(40)xunits.gu(68) unity8-dash when you run it on the desktop without -windowgeometry?
[14:25] <tsdgeos> dandrader: not sure i understand the question :D
[14:26] <tsdgeos> you mean if i like the dash having a good size on a regulra start?
[14:26] <tsdgeos> yes i do
[19:18] <cumana`> hello, does anybody else suffers from unity's alt-tab behaviour in multiple-monitor environment? I mean that it shows windows from both screens in switcher, instead of windows from current desktop
[19:24] <ChrisTownsend> cumana`: Hi.  Both monitors are considered the same desktop.  Consider it one big screen.
[19:27] <cumana`> ChrisTownsend, OK, I understand that some people may appreciate this solution, but what about making it configurable?
[19:27] <cumana`> consider having 4 terminals, 2 per screen - alt-tabing than is purely useless
[19:28] <cumana`> *then
[19:29] <cumana`> moreover, considering screens as separate workspaces would also ease moving windows between them - using ctrl-alt and arrows
[19:29] <ChrisTownsend> cumana`: Well, the one big desktop is a fundamental design in Compiz and changing that would not be trivial.  I think there are outstanding requests for that and the likelihood of it ever being addressed is quite low.  I do understand your pain though.
[19:30] <ChrisTownsend> cumana`: I wish I had a better answer:-(
[19:33] <cumana`> okay, thank you
[19:34] <ChrisTownsend> cumana`: np!
[19:34] <cumana`> therefore the only way for me is to: fork compiz and change that behavior
[19:34] <cumana`> :P
[19:35] <ChrisTownsend> cumana`: Well, if you do make it work and not break the original functionality, we could merge it:)
[19:35] <cumana`> are you a Compiz maintainer/developer?
[19:36] <ChrisTownsend> cumana`: yes
[19:36]  * ChrisTownsend hides
[19:38] <cumana`> :-)
[19:40] <cumana`> brave trip from kernelspace into userspace, that's challenge I need!
[19:41] <ChrisTownsend> cumana`: lol, yeah I used to work on device drivers and now do this.
[19:45] <cumana`> ChrisTownsend, has embedded solutions bored you? or did you get annoyed with some bug in compiz? ;)
[19:48] <ChrisTownsend> cumana`: Heh, well, it's kind of a long story.  But the short of it is that I used to work on storage device drivers on fault tolerant servers, but wanted a change.  As far as working on Compiz/Unity/et. al., it kind of landed in my lap:)
[20:15] <greyback_> cumana`: hey, in ccsm, there's an option to "bias alt-tab to prefer windows on the current viewport" - have you tried that?
[20:16] <ChrisTownsend> greyback_: That is per workspace, not per monitor.
[20:16] <greyback_> ChrisTownsend: ah ok
[20:17] <greyback_> my definition of view port differs from unity's
[20:17] <ChrisTownsend> greyback_: Well, that's a Compiz thing.  It's all very confusing, but in the end, Compiz view all connected monitors as one big desktop or mirrored desktops.
[20:18] <ChrisTownsend> viewport == workspace
[20:18] <greyback_> ChrisTownsend: yeah, gets it from X probably too, as a Display is all monitors
[20:18] <ChrisTownsend> greyback_: Yep
[20:19] <ChrisTownsend> greyback_: So that option you pointed out will make Alt-Tab see only windows in the current workspace or all workspaces( ick!).
[20:20] <cumana`> greyback_, yes, I tried, but it doesn't work the expected way
[20:20] <greyback_> oh well, worth a shot
[20:22] <greyback_> I guess a problem is, how do you define the "current desktop" - the one with a window having the keyboard focus, or the one containing the mouse pointer?
[20:23] <ChrisTownsend> greyback_: While I have your attention:)  I have a question about Unity 8 desktop end session.
[20:24] <ChrisTownsend> greyback_: When I log out of the desktop session, I always get a crash in MirOpenGLContext::makeCurrent(QPlatformSurface*) ()
[20:24] <greyback_> ChrisTownsend: known issue, is on my plate
[20:24] <ChrisTownsend> greyback_: Oh good!
[20:24] <ChrisTownsend> greyback_: Thanks!
[20:24] <greyback_> ChrisTownsend: unless you fancy giving it a go?
[20:24] <greyback_> :)
[20:25] <ChrisTownsend> lol, well, um, uh...
[20:26] <ChrisTownsend> greyback_: Is it a matter of things getting destroyed/shutdown in the wrong order or is it something more specific?  Seems that thread should be destroyed early on.
[20:26] <ChrisTownsend> Like Mir has already gone away yet Qt is still trying to do stuff.
[20:27] <greyback_> ChrisTownsend: mostly the wrong order yeah. mir has shut down before qt ad fully cleaned up
[20:27] <ChrisTownsend> greyback_: Ok, that's what it looks like.  The code for this is in qtmir, correct?
[20:27] <greyback_> ChrisTownsend: I wouldn't worry, I've a good idea how to fix it. I'll get it soon hopefully
[20:28] <ChrisTownsend> greyback_: Ah, well then, I won't spend any time on it;-)
[20:28] <greyback_> it links in with improvements I'll be making for multimonitor too
[20:28] <ChrisTownsend> greyback_: Sweet!
[20:30] <cumana`> greyback_, sorry for delay - both of these cases would be beneficial, but please, do not let me switch between *all* windows
[20:31] <cumana`> where 'all' means 'windows from both monitors'
[20:32] <cumana`> it even surprises me a bit, so many people use multiple monitors, many of them with ubuntu, many of them are programmers with documentation, browser, terminal sessions and IDEs launched at once... and nobody bothers alt-tab :)
[20:33] <cumana`> maybe I'm a weirdo :V
[20:44] <greyback_> I do, but maybe I'm just accustomed to the current behaviour
[20:44] <greyback_> as I jump between monitors frequently, I prefer the last-focused-on-my-workspace order
[20:45] <greyback_> I do hate if I minimize a window, then alt-tab, I end up un-minimizing the same window - drives me nuts
[20:45] <greyback_> but that's another issue :)
[21:01] <cumana`> another question: is my issue connected only with compiz, or is workspaces mechanism spread across other entites too? like gnome, unity?
[21:03] <greyback_> cumana`: I've no idea, sorry. You'd need to try gnome-shell or kde or other shells with their own window manager to see
[21:04] <cumana`> OK, thank you guys for all answers and see you