| blakep | Is anyone here? | 03:15 |
|---|---|---|
| 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 | 04:47 |
| 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. | 08:18 |
| === vrruiz_ is now known as rvr | ||
| tsdgeos | mzanetti: https://code.launchpad.net/~aacid/unity8/margins_contribute_to_display_margin/+merge/258854 | 10:14 |
| 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:15 |
| mzanetti | tsdgeos, thanks | 10:16 |
| mzanetti | tsdgeos, is this branch missing a prereq? | 10:17 |
| tsdgeos | ah | 10:17 |
| tsdgeos | it is | 10:17 |
| tsdgeos | mzanetti: now, https://code.launchpad.net/~aacid/unity8/margins_contribute_to_display_margin/+merge/258855 | 10:19 |
| mzanetti | tsdgeos, can you create a trello card for the margin tests please | 10:23 |
| mzanetti | approved the branch. fixes my nichtlustig scope | 10:23 |
| MacSlow | mzanetti, btw... updated my shellRotation branch with elopio's suggestion regarding QV4_ENABLE_JIT_CACHE | 10:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| tsdgeos | maybe i didn't understand what you said | 10:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:49 |
| 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:50 |
| tsdgeos | ok | 10:51 |
| MacSlow | tsdgeos, in the end it's mzanetti's call, if it'll move in or not. | 10:54 |
| mzanetti | well, tsdgeos is right in what he's saying... | 10:56 |
| 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 | 10:59 |
| 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:00 |
| mzanetti | yeah, the question is *why* | 11:01 |
| MacSlow | mzanetti, do you imply me hunting for the reason? :) | 11:02 |
| 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:03 |
| pstolowski | tsdgeos, not the edit button, but send; yes, a new preview is returned | 11:04 |
| tsdgeos | right sorry | 11:04 |
| 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:05 |
| pstolowski | tsdgeos, right. also that ensures what we actually show is what server has (e.g. the updated review) | 11:06 |
| cimi | tsdgeos, cool | 11:11 |
| === 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 | ||
| kgunn | tsdgeos: i see you've got the inline audio card...what's the current thinking on that in terms of design etc | 13:04 |
| 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:05 |
| tsdgeos | we don't have playback controls on the dash | 13:06 |
| tsdgeos | do we? | 13:06 |
| === ltinkl is now known as ltinkl_ | ||
| === ltinkl_ is now known as ltinkl__ | ||
| === ltinkl__ is now known as ltinkl | ||
| 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:23 |
| tsdgeos | dandrader: not sure i understand the question :D | 14:25 |
| tsdgeos | you mean if i like the dash having a good size on a regulra start? | 14:26 |
| tsdgeos | yes i do | 14:26 |
| === 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 | ||
| 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:18 |
| ChrisTownsend | cumana`: Hi. Both monitors are considered the same desktop. Consider it one big screen. | 19:24 |
| 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:27 |
| cumana` | *then | 19:28 |
| 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:29 |
| ChrisTownsend | cumana`: I wish I had a better answer:-( | 19:30 |
| cumana` | okay, thank you | 19:33 |
| 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:34 |
| 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:35 |
| ChrisTownsend | cumana`: yes | 19:36 |
| * ChrisTownsend hides | 19:36 | |
| cumana` | :-) | 19:38 |
| cumana` | brave trip from kernelspace into userspace, that's challenge I need! | 19:40 |
| ChrisTownsend | cumana`: lol, yeah I used to work on device drivers and now do this. | 19:41 |
| cumana` | ChrisTownsend, has embedded solutions bored you? or did you get annoyed with some bug in compiz? ;) | 19:45 |
| 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:) | 19:48 |
| 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:15 |
| ChrisTownsend | greyback_: That is per workspace, not per monitor. | 20:16 |
| greyback_ | ChrisTownsend: ah ok | 20:16 |
| 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:17 |
| 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:18 |
| ChrisTownsend | greyback_: So that option you pointed out will make Alt-Tab see only windows in the current workspace or all workspaces( ick!). | 20:19 |
| cumana` | greyback_, yes, I tried, but it doesn't work the expected way | 20:20 |
| greyback_ | oh well, worth a shot | 20:20 |
| 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:22 |
| ChrisTownsend | greyback_: While I have your attention:) I have a question about Unity 8 desktop end session. | 20:23 |
| 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:24 |
| ChrisTownsend | lol, well, um, uh... | 20:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| cumana` | greyback_, sorry for delay - both of these cases would be beneficial, but please, do not let me switch between *all* windows | 20:30 |
| cumana` | where 'all' means 'windows from both monitors' | 20:31 |
| 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:32 |
| cumana` | maybe I'm a weirdo :V | 20:33 |
| 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:44 |
| 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 :) | 20:45 |
| cumana` | another question: is my issue connected only with compiz, or is workspaces mechanism spread across other entites too? like gnome, unity? | 21:01 |
| 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:03 |
| cumana` | OK, thank you guys for all answers and see you | 21:04 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!