[03:15] Is anyone here? [04:47] 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] 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] finishes playing. === vrruiz_ is now known as rvr [10:14] mzanetti: https://code.launchpad.net/~aacid/unity8/margins_contribute_to_display_margin/+merge/258854 [10:15] at some point we really need auto tests for the display margin stuff [10:15] because we have none at the momeny _/ [10:16] tsdgeos, thanks [10:17] tsdgeos, is this branch missing a prereq? [10:17] ah [10:17] it is [10:19] mzanetti: now, https://code.launchpad.net/~aacid/unity8/margins_contribute_to_display_margin/+merge/258855 [10:23] tsdgeos, can you create a trello card for the margin tests please [10:23] approved the branch. fixes my nichtlustig scope [10:35] mzanetti, btw... updated my shellRotation branch with elopio's suggestion regarding QV4_ENABLE_JIT_CACHE [10:36] MacSlow: i disagree with that [10:36] and if we need it, it's showing some other problem in the JIT cache than that bug [10:37] because the problem described with the JIT cache in that bug is that when changing libraries it doesn't clean itself [10:37] what you said yesterday is that even once updated [10:37] between different runs it'll crash [10:37] 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] 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] because that is what the phone does [10:39] maybe i didn't understand what you said [10:40] 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] tsdgeos, after we submit a review in the edit review branch, shall it go back to edit review? [10:40] MacSlow: what does it matter that we start/stop unity8? [10:40] the cache is the same of the code it is [10:40] so it is a good cache [10:41] you don't need to ignore it/wipe it [10:41] cimi: sorry i don't understand what you mean, can you rephrase? [10:41] tsdgeos, I've seen otherwise [10:42] MacSlow: then report a bug [10:42] because the bug you're linking is *not* about that [10:42] you're basically saying the qml cache is crashy and should be always disabled [10:42] tsdgeos, I would have it I had a consistent reproducable test-case [10:49] MacSlow: still you have it crashing i'm concerned that what you're doing is basically workaround the test [10:49] by making it do not what the real world will do [10:49] so we'll have crashes in real world [10:49] is that what we want? [10:50] 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] your compromise is merging something that will crash randomly [10:51] ok [10:54] tsdgeos, in the end it's mzanetti's call, if it'll move in or not. [10:56] well, tsdgeos is right in what he's saying... [10:59] MacSlow, why is this only an issue with that shellRotation branch? do you know that? [10:59] tsdgeos, I tried with make tryPreviewEditReview [11:00] tsdgeos, but after I submit it doesn't go back to the beginning, with the edit button [11:00] mzanetti, I've never seen this causing issues elsewhere (with other tests qml or autopilot) [11:01] yeah, the question is *why* [11:02] mzanetti, do you imply me hunting for the reason? :) [11:03] cimi: ah, i see what you mean [11:03] pstolowski: so what happens after the user triggers the edit button, do you send a new preview model? [11:04] tsdgeos, not the edit button, but send; yes, a new preview is returned [11:04] right sorry [11:05] pstolowski: so we don't actaully need to go back to "display" mode since you're doing it for us [11:05] good :) [11:05] cimi: ↑↑ [11:06] tsdgeos, right. also that ensures what we actually show is what server has (e.g. the updated review) [11:11] tsdgeos, cool === MacSlow is now known as MacSlow|lunch === alan_g is now known as alan_g|lunch === ralsina_ is now known as ralsina === dandrader_ is now known as dandrader === MacSlow|lunch is now known as MacSlow === alan_g|lunch is now known as alan_g [13:04] tsdgeos: i see you've got the inline audio card...what's the current thinking on that in terms of design etc [13:05] before i left, design was sort of nowhere, and JoeO was asking if we could just reuse the playback controls from [13:05] the indicator panel, and plop them into the dash view [13:06] we don't have playback controls on the dash [13:06] do we? === ltinkl is now known as ltinkl_ === ltinkl_ is now known as ltinkl__ === ltinkl__ is now known as ltinkl [14:23] 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] dandrader: not sure i understand the question :D [14:26] you mean if i like the dash having a good size on a regulra start? [14:26] yes i do === dandrader is now known as dandrader|afk === MacSlow is now known as MacSlow|errand === dandrader|afk is now known as dandrader === dpm is now known as dpm-afk === alan_g is now known as alan_g|EOD === dandrader is now known as dandrader|lunch === MacSlow|errand is now known as MacSlow === dandrader|lunch is now known as dandrader [19:18] 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] cumana`: Hi. Both monitors are considered the same desktop. Consider it one big screen. [19:27] ChrisTownsend, OK, I understand that some people may appreciate this solution, but what about making it configurable? [19:27] consider having 4 terminals, 2 per screen - alt-tabing than is purely useless [19:28] *then [19:29] moreover, considering screens as separate workspaces would also ease moving windows between them - using ctrl-alt and arrows [19:29] 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] cumana`: I wish I had a better answer:-( [19:33] okay, thank you [19:34] cumana`: np! [19:34] therefore the only way for me is to: fork compiz and change that behavior [19:34] :P [19:35] cumana`: Well, if you do make it work and not break the original functionality, we could merge it:) [19:35] are you a Compiz maintainer/developer? [19:36] cumana`: yes [19:36] * ChrisTownsend hides [19:38] :-) [19:40] brave trip from kernelspace into userspace, that's challenge I need! [19:41] cumana`: lol, yeah I used to work on device drivers and now do this. [19:45] ChrisTownsend, has embedded solutions bored you? or did you get annoyed with some bug in compiz? ;) [19:48] 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] 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] greyback_: That is per workspace, not per monitor. [20:16] ChrisTownsend: ah ok [20:17] my definition of view port differs from unity's [20:17] 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] viewport == workspace [20:18] ChrisTownsend: yeah, gets it from X probably too, as a Display is all monitors [20:18] greyback_: Yep [20:19] greyback_: So that option you pointed out will make Alt-Tab see only windows in the current workspace or all workspaces( ick!). [20:20] greyback_, yes, I tried, but it doesn't work the expected way [20:20] oh well, worth a shot [20:22] 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] greyback_: While I have your attention:) I have a question about Unity 8 desktop end session. [20:24] greyback_: When I log out of the desktop session, I always get a crash in MirOpenGLContext::makeCurrent(QPlatformSurface*) () [20:24] ChrisTownsend: known issue, is on my plate [20:24] greyback_: Oh good! [20:24] greyback_: Thanks! [20:24] ChrisTownsend: unless you fancy giving it a go? [20:24] :) [20:25] lol, well, um, uh... [20:26] 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] Like Mir has already gone away yet Qt is still trying to do stuff. [20:27] ChrisTownsend: mostly the wrong order yeah. mir has shut down before qt ad fully cleaned up [20:27] greyback_: Ok, that's what it looks like. The code for this is in qtmir, correct? [20:27] ChrisTownsend: I wouldn't worry, I've a good idea how to fix it. I'll get it soon hopefully [20:28] greyback_: Ah, well then, I won't spend any time on it;-) [20:28] it links in with improvements I'll be making for multimonitor too [20:28] greyback_: Sweet! [20:30] greyback_, sorry for delay - both of these cases would be beneficial, but please, do not let me switch between *all* windows [20:31] where 'all' means 'windows from both monitors' [20:32] 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] maybe I'm a weirdo :V [20:44] I do, but maybe I'm just accustomed to the current behaviour [20:44] as I jump between monitors frequently, I prefer the last-focused-on-my-workspace order [20:45] I do hate if I minimize a window, then alt-tab, I end up un-minimizing the same window - drives me nuts [20:45] but that's another issue :) [21:01] another question: is my issue connected only with compiz, or is workspaces mechanism spread across other entites too? like gnome, unity? [21:03] 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] OK, thank you guys for all answers and see you