| === rsalveti_ is now known as rsalveti | ||
| didrocks | Trevinho: hey, around? | 07:39 |
|---|---|---|
| didrocks | popey: hey! once you are around, some more free karma: | 08:06 |
| didrocks | https://code.launchpad.net/~didrocks/dbus-test-runner/bootstrap/+merge/142258 | 08:06 |
| didrocks | https://code.launchpad.net/~didrocks/libdbusmenu/bootstrap/+merge/142256 | 08:06 |
| popey | morning didrocks | 08:16 |
| didrocks | hey popey! how is the weather in uk? | 08:17 |
| popey | Grey. As always. ☺ | 08:18 |
| didrocks | I share the same sky today! :) | 08:20 |
| didrocks | what have you done to Lyon? You have broken my weather! :-) | 08:20 |
| didrocks | thanks popey ;) | 08:41 |
| * didrocks adds 2 to the list of bootstrapped projects now | 08:41 | |
| popey | np | 08:41 |
| didrocks | seb128: popey: do you use standard icon size for unity? | 08:43 |
| didrocks | or reduced one? | 08:43 |
| popey | depends which way the wind is blowing | 08:43 |
| popey | and which machine | 08:43 |
| didrocks | :) | 08:43 |
| seb128 | didrocks, standard | 08:44 |
| popey | reduced on laptop, not on desktop | 08:44 |
| didrocks | seb128: when you press super, with the daily build ppa, you don't see any empty space between the launcher and the dash? | 08:44 |
| seb128 | didrocks, btw ppa from yesterday works fine on my laptop, no issue so far ... should I try tweaking the launcher settings? | 08:44 |
| * popey tries | 08:44 | |
| didrocks | popey: you do use the daily build ppa, right? | 08:44 |
| popey | on my desktop, yeah | 08:45 |
| * popey boots it | 08:45 | |
| didrocks | seb128: well, I can reproduce it right away ;) | 08:45 |
| didrocks | I see that: http://people.canonical.com/~didrocks/tmp/space_in_unity.png | 08:45 |
| seb128 | didrocks, I don't see it with the default icon size but I confirm when playing with the slider to change the setting | 08:46 |
| seb128 | it does it for some values | 08:46 |
| didrocks | ok, let me open a bug :) | 08:46 |
| didrocks | I see as well a bigger size at initialization for half a second | 08:46 |
| seb128 | k | 08:47 |
| didrocks | seb128: mterry mentionned to me to have a super key which seems wonkey for him, I can't reproduce though | 08:49 |
| didrocks | like some super press doesn't seem to be acked by the system | 08:49 |
| didrocks | popey: if you can try to see if you reproduce this one ^ | 08:49 |
| didrocks | seb128: also, if you want to confirm https://bugs.launchpad.net/unity/+bug/1097184 | 08:50 |
| ubot5 | Launchpad bug 1097184 in unity (Ubuntu) "Unity daily-build (07.01.13) empty space between launcher and dash in non default launcher size" [Undecided,New] | 08:50 |
| popey | didrocks: i can't reproduce a gap between launcher and dash, with any size dash | 08:51 |
| popey | s/dash/launcher/ ☺ | 08:51 |
| sil2100 | Oh, I have the same issue | 08:52 |
| popey | i did manage to catch it once as it shrunk while the dash was open | 08:52 |
| sil2100 | With the Super key | 08:52 |
| didrocks | sil2100: ah, please file a bug, not sure if you have the time to investigate, nice to know you are not alone :) | 08:52 |
| sil2100 | Not sure what happened, but since some update in staging sometimes I have to wank Super key more than once to get it working now | 08:52 |
| popey | hmm, not got latest unity from the ppa.. that'll be why | 08:52 |
| didrocks | popey: interesting… maybe try to set it to 32 and restart unity | 08:52 |
| didrocks | popey: ahhhh :) | 08:52 |
| didrocks | popey: yeah, that's it! :) | 08:53 |
| didrocks | sil2100: please signal that as soon as you catch it | 08:53 |
| popey | i dist-upgraded, still showing archive version... | 08:53 |
| popey | hmmm | 08:53 |
| didrocks | sil2100: it's easier then to find where the regression comes from :) | 08:53 |
| didrocks | popey: do you really have the daily-build ppa? | 08:53 |
| seb128 | didrocks, I had some issues opening the dash with super as well | 08:54 |
| * popey stabs ppa-purge and add-apt-repository | 08:54 | |
| popey | ppa-purge adds a # in .list files, add-apt-repository doesn't notice this | 08:54 |
| popey | so blindly says "okay, added repo" but actually doesn't uncomment the list file | 08:54 |
| seb128 | didrocks, it seems like if you act fat-finger and stay a bit too long on the key the tap doesn't work | 08:54 |
| seb128 | didrocks, not sure if that's new I tend to use the mouse rather than the keyboard to go to the dash | 08:55 |
| didrocks | seb128: ah, indeed, with fat-finger | 08:55 |
| didrocks | but the press was 250ms IIRC | 08:55 |
| didrocks | maybe the delay should be a little bit longer, not sure if it changed though, didn't see that in the merges | 08:55 |
| didrocks | sil2100: want to give it a shot? IIRC, it's a simple #define, you can try increment it | 08:56 |
| seb128 | didrocks, well in "normal" tapping it seems to work fine in any case | 08:56 |
| didrocks | yeah, but slow tapping isn't triggered | 08:56 |
| didrocks | and I think in some case of testing, it should | 08:56 |
| didrocks | popey: interesting :) | 08:56 |
| popey | annoying! | 08:57 |
| didrocks | interestingly annoying? :) | 08:57 |
| popey | very | 08:57 |
| popey | didrocks: ok, i have a gap now ☺ | 08:58 |
| popey | "thanks" | 08:58 |
| didrocks | popey: you can put a sticker on it, that's handy! :) | 08:58 |
| didrocks | ok, a small one :p | 08:58 |
| popey | and yes, it's losing super keypresses | 08:58 |
| didrocks | ok, so 2 noticed issues to be fixed before releasing to distro | 08:59 |
| didrocks | popey: seb128: do you mind if one of you open the bug for it? | 08:59 |
| popey | sure, will do | 09:01 |
| sil2100 | didrocks: for fixing the Super key-press issue you mean? | 09:01 |
| didrocks | yep :) | 09:02 |
| sil2100 | didrocks: will try, I'll dig and see if they actually changed something that could have caused it to (if the delay changed, or maybe the method how the delay is treated) | 09:02 |
| didrocks | sil2100: thanks! :) | 09:03 |
| popey | sil2100: bug 1097189 | 09:06 |
| ubot5 | bug 1097189 in Unity "Super key not registered if held too long" [Undecided,New] https://launchpad.net/bugs/1097189 | 09:06 |
| davidcalle | didrocks, hey. mhr3 told me you would prefer a branch per scope (and I know why), but do you know how to deal with automated translations in this case? | 09:07 |
| didrocks | davidcalle: I think we'll go on translation in the ubuntu package, or do you mean you want to activate the possibility to translate in the upstream project? | 09:08 |
| davidcalle | didrocks, oh right, forgot about this possibility. Fine for me then. | 09:08 |
| didrocks | because if you want to do that, it will be one launchpad project per scope, and it's not fun for you I guess :/ | 09:09 |
| didrocks | davidcalle: yeah, so don't enable the translation in the ubuntu-scopes launchpad projects | 09:09 |
| didrocks | davidcalle: I think it's the easiest, I gave it another thought this week-end, that's why it changed since Friday ;) | 09:09 |
| didrocks | and when I thought about it again, I guess you were during your lunch break, not online! :-) | 09:09 |
| davidcalle | didrocks, no problem. ;-) | 09:10 |
| didrocks | hey mmrazik, can you give it a look? https://code.launchpad.net/~didrocks/libdbusmenu/bootstrap/+merge/142256 it succeeded in one arch, not the other one | 09:17 |
| didrocks | and the two pre-merging archs succeded | 09:17 |
| didrocks | succeedeed* | 09:17 |
| mmrazik | didrocks: looking at it but "xvfb-run: error: Xvfb failed to start" doesn't look very familiar | 09:18 |
| didrocks | mmrazik: seems a configuration issue not making it runnable as it ran on i386 before the commit phase and succeeded in http://jenkins.qa.ubuntu.com/job/dbusmenu-ci/./build=pbuilder,distribution=raring,flavor=i386/20/console | 09:21 |
| mmrazik | didrocks: don't understand | 09:22 |
| didrocks | mmrazik: well, this one PASSED, isn't it? it's the same arch | 09:22 |
| mmrazik | sure | 09:22 |
| mmrazik | but I just don't see why xvfb-run suddenly stopped working | 09:22 |
| mmrazik | not aware of any specific configuration for xvfb-run | 09:23 |
| didrocks | mmrazik: if the machine you run on/the configuration is different, maybe there is a different X server started? | 09:23 |
| didrocks | maybe just try otherwise rekicking it… | 09:23 |
| mmrazik | didrocks: yes please, try to re-approve | 09:23 |
| mmrazik | didrocks: the builder machine is shared so maybe some other test/build influenced the build | 09:24 |
| mmrazik | but in case of xvfb-run I would expect it doesn't really care | 09:24 |
| mmrazik | there is no X running on those builder machines | 09:24 |
| didrocks | weird… | 09:25 |
| didrocks | hey andyrock, how are you? | 09:25 |
| andyrock | didrocks, good what's up? | 09:26 |
| didrocks | andyrock: there is a regression in unity trunk, maybe you will know what happened: bug #1097184 | 09:26 |
| ubot5 | bug 1097184 in unity (Ubuntu) "Unity daily-build (07.01.13) empty space between launcher and dash in non default launcher size" [Low,Confirmed] https://launchpad.net/bugs/1097184 | 09:26 |
| didrocks | andyrock: do you think you can/have time to work on it? As told on the bug report, the first hint is that on startup, the launcher has the regular size for 0.5s | 09:27 |
| andyrock | didrocks, "the launcher has the regular size for 0.5s" it should not be the problem | 09:28 |
| didrocks | ok, so another bug? :) | 09:28 |
| andyrock | yup let me check DashController.cpp :) | 09:28 |
| didrocks | thanks! :) | 09:29 |
| duflu | didrocks, sil2100, popey: lp:unity 2970 made the timeout configurable and changed the default from 250 to 130ms. Change it back to 250 if you like :) | 09:33 |
| didrocks | yeah, I think this will be saner value, most of tapping are between 250 and 300ms (it's 300ms on android) | 09:33 |
| sil2100 | I think 250ms was fine ;p | 09:33 |
| sil2100 | duflu: thanks for the info! | 09:34 |
| * sil2100 prepares a merge request | 09:34 | |
| duflu | didrocks: In independent tests by myself and Brandon we both concluded anything above 130 was "too long". But I don't mind... | 09:34 |
| duflu | didrocks: It's because Compiz reliable tap detection is turned off. If the Super timeout is 250 then it's too easy for Super+other_keys to trigger the dash | 09:34 |
| didrocks | duflu: any reason than compiz reliable tap detection to be turned off btw? | 09:35 |
| didrocks | sil2100: gimme gimme :) | 09:35 |
| duflu | didrocks: To fix: https://bugs.launchpad.net/bugs/950160 | 09:35 |
| ubot5 | Launchpad bug 950160 in OEM Priority Project precise "Unity blocks other programs from binding globally to Super+* (* = any key)" [Critical,In progress] | 09:35 |
| didrocks | and we don't have anymore issue with alt + something? | 09:36 |
| duflu | didrocks: It's not turned off for Alt. So not a problem :) | 09:36 |
| didrocks | ah ok :) | 09:36 |
| andyrock | didrocks, https://code.launchpad.net/~3v1n0/unity/launcher-options-single-emission | 09:45 |
| andyrock | didrocks, i think it's causing the regression | 09:45 |
| andyrock | fixing it | 09:46 |
| didrocks | andyrock: ah, nice that you spotted the cause, yeah, it seems to be linked | 09:46 |
| didrocks | andyrock: do you think that this position is testable? | 09:46 |
| andyrock | maybe with autopilot | 09:47 |
| didrocks | sil2100: so, now that I've been able to run against latest unity the indicator-unity tests, here are the results: | 09:51 |
| Mirv | added a note to the bug report about the side effect reported by smagoun that brandon is currently looking at | 09:51 |
| didrocks | sil2100: http://10.97.0.1:8080/job/ps-indicators-autopilot-release-testing/40/label=autopilot-ati/testReport/ | 09:51 |
| didrocks | sil2100: http://10.97.0.1:8080/job/ps-indicators-autopilot-release-testing/40/label=autopilot-nvidia/testReport/ | 09:51 |
| didrocks | so 7/8 to fix still (-4 you really did fix, isn't it?) | 09:51 |
| sil2100 | huh, still failures? | 09:53 |
| sil2100 | Let me see that :/ | 09:53 |
| sil2100 | test_gedit_undo again?! | 09:54 |
| didrocks | seems :/ | 09:54 |
| sil2100 | This means war | 09:54 |
| didrocks | on both | 09:54 |
| didrocks | at least, the failing ones are common to both | 09:54 |
| sil2100 | Ok, but now gedit_undo fails differently | 09:57 |
| sil2100 | And a new failure | 09:57 |
| didrocks | ah, at least, what you have done had an impact :) | 09:58 |
| didrocks | sil2100: not sure how your load is, but maybe just finish the tap thing so that it's merged, then, I'll approve it and you can go on the failures? | 09:59 |
| sil2100 | didrocks: the tap thing is submitted for review, so I will look into those failures | 10:03 |
| sil2100 | (actually am now) | 10:03 |
| didrocks | sil2100: jumping on your MP! :-) | 10:03 |
| didrocks | sil2100: thanks ;) | 10:03 |
| sil2100 | https://code.launchpad.net/~sil2100/unity/unity_dash_tap_duration/+merge/142273 | 10:03 |
| didrocks | if only that was giving ingress points :) | 10:03 |
| didrocks | sil2100: oh, yo udidn't link it to the bug report | 10:04 |
| didrocks | let me do it | 10:04 |
| sil2100 | The undo and the one new failure I can try fixing, but the next/prev ones are really mystical - I thought that introducing a wait for the started application will help, but in the end it didn't | 10:04 |
| sil2100 | But I'll try looking a bit deeper | 10:04 |
| sil2100 | oh, sorry about that ;) | 10:04 |
| didrocks | the 4 test_dash_hud is the one you fix and need another review, right? | 10:05 |
| didrocks | maybe after the gedit_undo, you can try unity.tests.test_hud.HudBehaviorTests.test_closes_then_focuses_window_on_mouse_down before the next/prev black magic :) | 10:05 |
| andyrock | didrocks, that was the problem. it's fixed now | 10:37 |
| andyrock | need to write an ap test | 10:37 |
| didrocks | andyrock: you rock! :-) | 10:37 |
| andyrock | ;) | 10:38 |
| didrocks | mmrazik: is this one stalled? https://code.launchpad.net/~didrocks/libdbusmenu/bootstrap/+merge/142256 | 11:06 |
| mmrazik | didrocks: I just received an e-mail about that | 11:06 |
| didrocks | ah? good timing then :) | 11:06 |
| === mmrazik is now known as mmrazik|afk | ||
| === _salem is now known as salem_ | ||
| === mmrazik|afk is now known as mmrazik | ||
| didrocks | mmrazik: we disable the autopilot job as jibel is trying to make the intel box working with raring | 11:37 |
| mmrazik | didrocks: ok | 11:37 |
| didrocks | and then, once we have the daily build running, this will enable us to kill the staging ppa and this job :) | 11:38 |
| mmrazik | didrocks: mhm. the dbusmenu job still failing :-/ | 11:38 |
| didrocks | mmrazik: urgh, I can't reproduce it here, with a pbuilder, everything is working | 11:38 |
| mmrazik | randomly, as now it failed on differen builder host (the same where it passed previously) and different arch | 11:39 |
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| === gatox is now known as gatox_brb | ||
| didrocks | sil2100: any progress btw? :) | 12:45 |
| === gatox_brb is now known as gatox | ||
| === MacSlow is now known as MacSlow|lunch | ||
| === mmrazik is now known as mmrazik|afk | ||
| petko10 | hey guys , I have a question about developing for the Ubuntu phone OS - the native language is QML/Qt5/C++ right ? | 13:20 |
| larsu | petko10, yes: http://developer.ubuntu.com/get-started/gomobile/ | 13:22 |
| petko10 | ok ,nice (I asked , because , though i read most of the info on the gomobile, I didn't see any C++ code , but it's not hard to figure that qt=c++ as I think of it) | 13:27 |
| sil2100 | didrocks: yes, but now a short break for preparing lunch | 13:38 |
| === mmrazik|afk is now known as mmrazik | ||
| === MacSlow|lunch is now known as MacSlow | ||
| === dandrader is now known as dandrader|lunch | ||
| === mmrazik is now known as mmrazik|otp | ||
| === dandrader|lunch is now known as dandrader | ||
| didrocks | mterry: hey! I think you saw that your regression you found was a real one :) | 16:27 |
| mterry | didrocks, yeah, looks like it got fixed already | 16:27 |
| didrocks | mterry: yeah, I pinged and harassed people | 16:28 |
| didrocks | mterry: how full is our plate? do you have time for indicators and unity tests issues? | 16:28 |
| mterry | didrocks, mmm, I've got stuff. I can take some of it off your plate... | 16:29 |
| didrocks | mterry: yeah, there are basically 2 kinds of thing, and they are quite urgent to have daily unity release | 16:29 |
| mterry | didrocks, OK | 16:29 |
| didrocks | mterry: first one is about bootstrapping dbusmenu and libappindicator | 16:30 |
| didrocks | dbusmenu still has a test stability issue when merging | 16:30 |
| didrocks | see https://code.launchpad.net/~didrocks/libdbusmenu/bootstrap/+merge/142256 for instance | 16:30 |
| didrocks | so if you can give it a look, why it's failing on some archs… | 16:30 |
| didrocks | the second is libappindicator, which needs bootstrapping and test passing during build, see it with cyphermox about where he stops | 16:32 |
| didrocks | lp:~mathieu-tl/+junk/libappindicator for some debug infos | 16:32 |
| didrocks | the second issue is what sil2100 is working on | 16:33 |
| cyphermox | well, that's basically where I'm at | 16:33 |
| cyphermox | didrocks: seems to me like dbusmenu is failing because the script run-xfvb.sh is probably very broken in some way | 16:33 |
| sil2100 | o/ | 16:33 |
| cyphermox | mterry: libappindicator: i'm trying to figure out what might be different between the gtk2 tests and gtk3 tests that would explain why the gtk3 tests reproducibly fail while the gtk2 tests pass | 16:34 |
| didrocks | mterry: if you have knowledge about that, that would be great ^ | 16:34 |
| didrocks | mterry: second things is about indicator autopilot tests | 16:35 |
| didrocks | mterry: we need to fix them all to be able to start releasing daily unity | 16:36 |
| === dandrader is now known as dandrader|afk | ||
| didrocks | the list is at jenkins-qa/job/ps-indicators-autopilot-release-testing/ | 16:36 |
| didrocks | you can see the 3 archs | 16:36 |
| mterry | didrocks, https://jenkins.qa.ubuntu.com/view/PS/job/ps-indicators-autopilot-release-testing/ | 16:37 |
| mterry | oh | 16:37 |
| mterry | OK, cool | 16:37 |
| didrocks | we have 10/7/10 failures | 16:37 |
| mterry | Was about to ask if that was right url | 16:37 |
| didrocks | yeah, this is the public mirroring :) | 16:37 |
| didrocks | so sil2100 has a regression fix for 4 of them | 16:37 |
| didrocks | so normally this would be 6/3/6 remaining | 16:37 |
| didrocks | can you please coordinate with sil2100 and bregma (who will put brandon on line) to get that to 0? | 16:38 |
| didrocks | this can be either tests not stable | 16:38 |
| mterry | OK | 16:38 |
| didrocks | or real issues | 16:38 |
| didrocks | mterry: sil2100 can help you to run autopilot | 16:38 |
| sil2100 | I see that some issues are still AP typical issues | 16:40 |
| mterry | sil2100, is there a wiki for getting myself able to run the indicator autopilot tests? | 16:45 |
| === dandrader|afk is now known as dandrader | ||
| sil2100 | mterry: a wiki? hm, not really, sadly... | 16:51 |
| * mterry goes on lunch+errands, but will come back. sil2100, if you could leave some notes on running autopilot, unless it's literally as simple as running autopilot inside the indicator source somewhere | 16:54 | |
| sil2100 | mterry: I'll send you an e-mail if that's fine with you? | 17:02 |
| didrocks | sil2100: mterry is in the US, so if you can do that before going EOD, it would be awesome :) | 17:03 |
| bschaefer | sil2100, mterry hey, I hear you guys are work on fixing the AP tests? | 17:17 |
| sil2100 | Yes, some failures regarding the indicators mostly | 17:18 |
| bschaefer | sil2100, well I was going to join in, and wanted to make sure I didn't step on anyones toes :) | 17:18 |
| sil2100 | bschaefer: some of the failing tests, for instance, are due to AP not waiting for the application to get focus | 17:20 |
| sil2100 | (at least that's how it looks like it) | 17:20 |
| bschaefer | sil2100, o dang...thomi had a nice ap-view branch that made a list of all the failing AP tests along with the video | 17:20 |
| bschaefer | though the video isn't that hard to get from jenkins | 17:21 |
| bschaefer | sil2100, this is the list your working through right? http://paste.ubuntu.com/1510013/ | 17:21 |
| sil2100 | Yes, I'm using it all the time ;) | 17:21 |
| sil2100 | apview.html banzai! | 17:21 |
| bschaefer | :) | 17:21 |
| bschaefer | yup! | 17:21 |
| sil2100 | bschaefer: yes, more or less - there are even some more, since the latest indicator ap results have more test failed | 17:22 |
| bschaefer | alright, ill keep checking jeninks for more. | 17:23 |
| bschaefer | sil2100, I think i've noticed a bug in unity though....when you do a 'unity' and something is striping focus off the windows in the first say 60 seconds | 17:23 |
| bschaefer | though i wasn't sure if it was something I was doing :) | 17:24 |
| bschaefer | which could explain the AP tests losing focus of an application (since its a fresh reboot) | 17:24 |
| sil2100 | oh! | 17:24 |
| sil2100 | That would, hm, really answer the question of why gedit_undo failed last time | 17:25 |
| sil2100 | hm | 17:25 |
| bschaefer | yeah... i was going to dig into it after I got over a bunch of other work I was doing | 17:25 |
| bschaefer | im thinking it could be the switcher, but it would be nice to have someone else confirm it :) | 17:26 |
| sil2100 | Never noticed it though - you say it happens after start of unity? | 17:26 |
| bschaefer | yeah | 17:26 |
| sil2100 | I'll try on a guest session now | 17:26 |
| bschaefer | as I have been restarting unity a bunch now | 17:26 |
| bschaefer | sil2100, well a compiz --replace | 17:26 |
| * bschaefer goes to add debuging statment to nux event loop | 17:28 | |
| sil2100 | Holy shat, you're right | 17:35 |
| bschaefer | well dam...I should have filed a bug about it | 17:36 |
| bschaefer | well either way, Ill work on fixing that | 17:36 |
| sil2100 | After like 20-25 seconds suddenly all apps loose focus | 17:36 |
| bschaefer | yeah, its strange, ill see what window is doing this in the nux event loop...ill see shortly! | 17:36 |
| sil2100 | bschaefer: should I fill a bug? | 17:38 |
| bschaefer | sil2100, sure, and assign it to me :) | 17:38 |
| * bschaefer hopes this is the cause of the problems in the AP tests | 17:39 | |
| sil2100 | This would make sense, since I tried fixing the issues by adding an assertion of window focus, but it didn't help - and it also answers the question why I was unable to reproduce it here | 17:42 |
| sil2100 | I only once reproduced one of the problems, and I think it might have been right after unity --replace | 17:42 |
| bschaefer | sil2100, yeah, interesting, it looks like the switcher steals focus for some reason.... | 17:42 |
| sil2100 | I didn't notice it | 17:42 |
| sil2100 | \o/ | 17:42 |
| bschaefer | though let me double check | 17:43 |
| sil2100 | bschaefer: anyway, great catch! | 17:43 |
| bschaefer | a bunch of events when through when it happened | 17:43 |
| bschaefer | thanks! You have no idea how annoying that bug was when trying to reset/compile/test/repeat haha | 17:43 |
| bschaefer | sil2100, definitely the switcher.... | 17:44 |
| bschaefer | it sends a bunch of PropertyNotify events when it happens ... interesting ... time to go fix it | 17:45 |
| sil2100 | bschaefer: https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1097368 | 17:48 |
| ubot5 | Launchpad bug 1097368 in unity (Ubuntu) "Windows losing focus after the start/restart of Unity" [Undecided,New] | 17:48 |
| bschaefer | sil2100, thanks for filing that! | 17:48 |
| bschaefer | sil2100, sorry I hadnt yet, that could have saved you some time ... | 17:49 |
| sil2100 | bschaefer: no problem, good that you spotted it even now ;) | 17:52 |
| bschaefer | yeah, hopefully the fix will be simple! | 17:54 |
| === me4oslav is now known as me4oslav-muffins | ||
| bschaefer | sil2100, interesting, the problem appears to be in SwitcherController::ContructWindow, view_window_->EnableInputWindow(true, "Switcher", false, false); | 18:09 |
| bschaefer | if you remove that line, everything works, as that chunk of code should be in ShowView (which it is) | 18:09 |
| bschaefer | the switcher window it self was being focus (but since its just an nux::XInputWindow really there is no title) | 18:10 |
| sil2100 | bschaefer: does it need to steal focus? | 18:12 |
| sil2100 | I mean, hm | 18:12 |
| bschaefer | sil2100, nope, it was happening when it was being created | 18:12 |
| bschaefer | as there is a bit of a delay when things get created unless you force it | 18:12 |
| bschaefer | like with the dash | 18:12 |
| sil2100 | bschaefer: excellent, well, we don't want it doing that then ;p! | 18:13 |
| bschaefer | sil2100, it needs to take the focus when the switcher is started, but there is code in ShowView to do that, which it does :) | 18:13 |
| bschaefer | sil2100, sooo now to test this ... hmm | 18:13 |
| bschaefer | I don't want to have an AP test that is 30+ seconds long...for each arc | 18:13 |
| sil2100 | Not sure if that's easy autopilot-testable... | 18:13 |
| bschaefer | yeha... | 18:14 |
| sil2100 | Right, and besides it would require a clean unity start | 18:14 |
| bschaefer | plus having to do a compiz --replace | 18:14 |
| bschaefer | yup | 18:14 |
| bschaefer | a unit test no... | 18:14 |
| sil2100 | So maybe an unit test? I know they're not really meant for such things | 18:14 |
| bschaefer | i mean... | 18:14 |
| bschaefer | hmm...well we could fake creating a the switcher | 18:14 |
| bschaefer | which then we could possibly check the panel title | 18:15 |
| bschaefer | as it will be empty if it steals focus | 18:15 |
| sil2100 | hoo, ok, that sounds nice | 18:15 |
| bschaefer | well im not sure if I have access to the panel in a unit test | 18:15 |
| bschaefer | but I think I can find something to check, I can dig into | 18:16 |
| sil2100 | Since normally I would say 'let's not test it', but then we'll forget about this issue and again after a while, if it gets reintroduced, we'll be thinking 'what the heck is going on' unnecessarily | 18:16 |
| bschaefer | sil2100, yeah I agree, this is one of those regressions that is hard to detect | 18:17 |
| bschaefer | as looking at the rev, it was introduced by me :), at like 2500 | 18:17 |
| bschaefer | sil2100, what are you running? 13.04 or 12.10? | 18:18 |
| * bschaefer hopes this wasn't back ported to 12.04 | 18:18 | |
| sil2100 | I'm running 12.10, but from staging | 18:20 |
| sil2100 | I'll check on precise if it's there ;) | 18:20 |
| bschaefer | cool, thanks! | 18:20 |
| bschaefer | o interesting, it is on a 75ms timer, which is why the unit test atm don't catch it either | 18:22 |
| bschaefer | actually no its 20 seconds... | 18:24 |
| bschaefer | dam variables looking the same | 18:24 |
| sil2100 | heh ;) | 18:30 |
| sil2100 | See you tomorrow! | 18:30 |
| bregma | bschaefer, what was the issue with the switcher messing up the AP tests? | 18:34 |
| bschaefer | bregma, i haven't confirmed it, but I should run those AP tests | 18:35 |
| bschaefer | bregma, it is leaning towards that | 18:35 |
| bregma | I'm just looking at what needs to be done to get proper unit tests set up for the switcher | 18:35 |
| bregma | so I'm particularly interested | 18:36 |
| bschaefer | oo yeah, hmm well I was looking at the unit test, and creating the switcher doesn't appear to make it lose focus :( | 18:37 |
| bschaefer | soo that either means there is a deeper problem...or you need to run the unity stack to get it to lose focus | 18:37 |
| bregma | the unit tests don't take into account of the fact that a significant portion of the logic of the switcher is in the Unity compiz plugin: there's a signal fired off when the Switcher is initialized later after its creation, and it's connected to something in the nuityshell somewhere | 18:44 |
| bschaefer | bregma, hmm well that could explain that, it would just be nice to fail in a simple unit test :) | 18:45 |
| bschaefer | there are bits in the unityshell.cpp that should be moved into the switchercontroller | 18:46 |
| bschaefer | .cpp | 18:46 |
| bregma | bschaefer, absolutely -- I'm working on a task list for that | 18:46 |
| bregma | part of our new focus on total QA | 18:46 |
| bschaefer | bregma, awesome, im guessing that is why we need those books haha | 18:47 |
| bregma | Switcher seems like a good place to start because it (should be) pretty much self contained | 18:47 |
| bschaefer | yes it should! | 18:47 |
| * bschaefer wonders why autopilot is being mean | 18:48 | |
| bregma | hmm, nothing activated by that Switcher signal should be stealing focus | 18:51 |
| bschaefer | well I need to dig into why EnableInput for the view steals focus when running unity vs a unit test | 18:51 |
| bschaefer | as the problem is in SwitcherController::ContructWindow() | 18:52 |
| bregma | how can you tell? | 18:52 |
| bschaefer | if you do a compiz --replace and wait 20 secods | 18:53 |
| bschaefer | seconds you lose window focus | 18:53 |
| bschaefer | and by adding print statements I found it was in construct window, and I commented out enableinputs and then did a compiz --replace | 18:53 |
| bschaefer | and then the window focus was no longer being lost | 18:53 |
| bregma | ConstructWIndow() calls EnableInputWindow() (from Nux) ... would that do it? | 18:53 |
| bschaefer | yeah, that is what the problem was | 18:54 |
| bschaefer | but ... doing a unit test that just creates a switcher, and gets to that function doesn't cause unity to lose window focus... | 18:54 |
| bschaefer | though...do the unit tests run on a different X Server? | 18:55 |
| bschaefer | besides the :) | 18:55 |
| bschaefer | :0 | 18:55 |
| bregma | technically, the unit tests should not need a server and should not uncover this problem | 18:56 |
| bregma | that's another story | 18:56 |
| bschaefer | very true, I don't think a unit test is proper for this... | 18:57 |
| bschaefer | nor is an AP test | 18:57 |
| bregma | either way, nux::BaseWindow::EnableInputWindow() is being called with take_focus set to false, so I would expect it to not grab the focus | 18:58 |
| bschaefer | yeah I noticed that as well...I need to spend some more time in figuring out *why* that is enable input is causing it to lose window focus | 18:58 |
| bregma | ...unless the Nux ABO has changed again and there's a misalignment, but I think that's unlikely | 18:58 |
| bregma | *ABI | 18:59 |
| bschaefer | yeah, ill do some digging into Nux to figure out why... | 18:59 |
| bschaefer | also you can see something is sending the UBUS message to the panel, saying we lost focus | 19:00 |
| === salem_ is now known as _salem | ||
| bschaefer | but it doesn't know the name of the window | 19:00 |
| === me4oslav-muffins is now known as me4olsav | ||
| bschaefer | bregma, looking at BaseWindow...it shows the window if the first bool is true | 19:01 |
| bschaefer | which simply showing the window could be the problem | 19:01 |
| bregma | gorram badly named variables, we need to bring in the daeth penlaty for those | 19:02 |
| bschaefer | yes... very | 19:02 |
| bregma | no, daeth is too good for 'em | 19:02 |
| bschaefer | the take_focus is just for the XInputWindow | 19:03 |
| bregma | a boolean variable name 'b' | 19:03 |
| bschaefer | haha | 19:03 |
| bregma | it answers the question, 'is it b?' | 19:03 |
| bschaefer | yes it is a b! | 19:03 |
| bschaefer | now everyone knows, though since its an explicit typing system it should be easy to tell! | 19:04 |
| bregma | well, it seems to be that creating an XInputWindow without take_focus set shouldn;t steal the focus, but now I have to brush up on XInputWindow | 19:05 |
| bschaefer | yeah, the XInputWindow uses the the take_focus to send an PropertyNotify that it is taking focus | 19:06 |
| bschaefer | so it sends an XEvent | 19:06 |
| bschaefer | which is the event I was receiving when the switcher was stealing focus | 19:06 |
| bregma | so how has this ever worked properly? | 19:07 |
| * bschaefer wonders the same thing | 19:08 | |
| bregma | second question: why is the Switcher created as a persistent object and not created when needed? | 19:08 |
| bschaefer | its the SwitcherController that is just created once | 19:08 |
| bschaefer | the model gets created each time you hit alt+tab | 19:08 |
| bschaefer | and why there is a timer...im guessing so there is a better start up time....(its done with the dash and the lenses as well) | 19:09 |
| bregma | that's my guess, but having the Switcher (and dash et al) created when needed also saves time, and makes simpler more reliable code | 19:10 |
| bregma | one of the things on my list is to see comparative timings of persistent vs. as-needed design for the Switcher | 19:11 |
| bschaefer | yes...hmm ill see if the EnableTakeFocus is called when the switcher steals focus... | 19:11 |
| bschaefer | that would be nice, we still need to get some timing done to work on improving the dash speed | 19:11 |
| * bschaefer wonders who that was passed onto | 19:11 | |
| === me4olsav is now known as me4oslav | ||
| === godbyk-feynman is now known as godbyk | ||
| === _salem is now known as salem_ | ||
| Stewi3_89 | Hi can someone help me restoring unity desktop? I've tryied some Google tips but still not working | 23:34 |
| bschaefer | Stewi3_89, could you explain the problem a bit more? | 23:37 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
