[00:03] Hi everyone. (Sorry for big chunk of text:) I've got a problem with (I believe) unity. Some windows I minimized (terminals in particular) are behaving strangely. If I have another window active and press alt-tab to a terminal, it does not become active. (However alt-tabbing to the terminal window group, waiting for the group to expand and then choosing one works). [00:03] I've tried unity --replace, unity --reset, compiz --replace, it does not help. [00:03] A lot of windows from before the first time I did unity --replace are now completely invisible. I have come up with a method to get some of them back (see screenshots), but this does not work for programs nt having an "internal" window list. [00:03] I've posted more info + screenshots here: http://inky.ws/g/2cr [00:03] Somewhat related: http://askubuntu.com/questions/177139/gnome-terminal-not-showing-up-in-unity-why === fenris is now known as Guest68936 [07:08] mmrazik: hey, seems autolanding has some issues: https://code.launchpad.net/~didrocks/dee/dailybootstrap/+merge/134299 [07:08] didrocks: I'm working on it [07:08] didrocks: in particular on this specific MP [07:08] thanks :) [07:08] didrocks: the issue is that the IPs change and there are some issues in connecting to local archive [07:08] but there is one more problem now which I don't understand... [07:09] (yet) [07:09] mmrazik: hum, I can just say "good luck" ;) [07:09] didrocks: ack :) [07:30] didrocks: sorry for spamming your MP [07:30] but I'm getting closer :) [07:30] no worry ;) === fenris is now known as Guest62485 [08:47] Trevinho: Mirv: what about https://code.launchpad.net/~aacid/unity/initialize_using_nofilters_background_6.0/+merge/132297 think it makes sense? [08:59] didrocks: FYI https://jenkins.qa.ubuntu.com/job/ps-unity-autopilot-trunk/348/testReport/ [08:59] that is the last "successful" autopilot run [08:59] then we hit a cobbler bug :-/ [08:59] which Max fixed yesterday night but now we are running into something new [09:00] didrocks: its ~27% fail rate [09:04] mmrazik: ok, I think you guys have a plan to work on it? :) [09:04] sure [09:05] tsdgeos: I'd think that since Unity can be considered part of infrastructure, and the fix isn't clearly fixing a high impact bug, it doesn't fall under SRUable commits [09:05] mmrazik: thanks for the link :) [09:06] Mirv: ok, the poor sods that get randomly a false assigned to that var would probably disagree but that's going to be 1 in a million [09:06] Mirv: could you please comment so in the merge request? [09:06] tsdgeos: did so [09:06] ah :D [09:06] tx :-) [09:06] :) [09:15] didrocks: could you please have a look: [09:15] https://jenkins.qa.ubuntu.com/job/bamf-mbs-autolanding/21/build=pbuilder,distribution=quantal,flavor=amd64/console [09:16] is that a packaging issue? [09:20] mmrazik: make[5]: *** [test-headless] Error 1 [09:20] mmrazik: seems more make test-headless returned 1… [09:20] (despite having OK everywhere) [09:21] oh... missed that... only saw the "dh_auto_test: make -j1 check returned exit code 2" [09:25] didrocks: mhm.. I'll try to re-approve. The next bamf MP passed the tests (but failed at dh_makeshlibs) [09:28] mmrazik: ok, keep me in touch, not having this bootstrapping makes us using other branches to test [09:30] didrocks: are there more branches like that? [09:30] mmrazik: dee, bamf, libunity for now [09:30] didrocks: ack.. just found the libunity one... [09:34] thanks [09:45] didrocks: beside the random make test failure we have one problem in bamf. [09:46] https://code.launchpad.net/~mterry/bamf/c4/+merge/134313 is fixing some gensymbols issue [09:46] didrocks: but it lists the debootstrap branch as prerequisite [09:46] mmrazik: in a hangout, I can inverse them if needed [09:46] didrocks: and the debootstrap branch fails with the gensymbol (if the make test randomly passes) [09:46] didrocks: ok === fenris is now known as Guest72765 === Guest72765 is now known as ejat === mmrazik is now known as mmrazik|lunch === _salem is now known as salem_ [11:47] hello there. Id like to introduce a new LauncherIcon type, but cant find the code which parses the desktopfile's fields. please help me on this. [12:07] Hi larsu can you help me? [12:09] cariveri, sure, what's up? [12:11] larsu Id like to introduce a new LauncherIcon type, but cant find the code which parses the desktopfile's fields. please help me on this. === mmrazik|lunch is now known as mmrazik [12:12] cariveri, what project are you talking about? Unity? [12:12] mmrazik: hey, why do you have gensymbol issues? [12:12] mmrazik: did fghinter runs -c4 now? [12:13] larsu: yes unity. unityshell/src ? [12:14] cariveri, I don't know, I'm not a unity developer :) a quick grep for g_desktop_app_info_new points to launcher/ApplicationLauncherIcon.cpp and UnityCore/DesktopUtilities.cpp [12:14] but I'm sure that other people in this channel can be of more help [12:16] didrocks: I don't know [12:16] mmrazik: if not, we don't need mterry's branch in mine [12:16] didrocks: btw. I was thinking of pushing the bamf dailybootstrap thing via autolanding with no tests [12:17] mmrazik: that can do it, but we need to know at some point why the tests are failing, maybe check with Trevinho [12:17] I think the bamf stuff is broken and needs to be fixed. Have seen the same random failures in libunity [12:17] we need to fix libunity too [12:17] or actually... the branch that enables the tests didn't land yet [12:17] bamf was probably just lucky during the enablement [12:18] maybe [12:21] larsu: I expected a loop where the files are parsed and evaluate, for that the Icons on the launcher can be created. There is are types like TYPE_APPLICATION defined in AbstractLauncherIcon, but cant find the place where it is set from the files. Maybe you'r a smarter grep-er then I am. [12:21] didrocks: I believe all the bootstrap branches now landed [12:21] mmrazik: ok, there will probably be a lot more once mterry is around [12:22] thanks [12:24] cariveri, there's no TYPE_APPLICATION anywhere in AbstractLauncherItem. Unity probably uses GDesktopAppInfo instead of parsing the desktop files manually: http://developer.gnome.org/gio/stable/gio-Desktop-file-based-GAppInfo.html [12:24] what are you trying to achieve? === fenris is now known as Guest89250 [12:31] didrocks: right now I'm aware of the bamf issue and the unity can not land (due to various errors the nux4 stuff didn't get it into the local archive) [12:31] the rest should be landing fine [12:31] or rather I didn't see it failing yet ;) [12:31] larsu: AbstrcatLauncherIcon.h not item :) [12:32] larsu: and I know how to parse thos efiles my self, but the question is how unity does it and where so I can integrate porperly my new feature. [12:33] didrocks: FYI autopilot/unity is currently stuck on UTAH. Trying to figure out if there is somebody in europe who can help me. Otherwise I need to wait for Max [12:33] cariveri, sorry, that was a typo. The only TYPE_APPLICATION in there is BAMF_TYPE_APPLICATION... [12:33] cariveri, I can't tell you for sure how unity parses those files, but like I said, it looks like it's using GDesktopAppInfo [12:37] hmm I took the unity src from by apt-get source. and there is a lot of TYPES defined. TYPE_EXPO, TYPE_TRASH and so on. [12:37] larsu: but thanks for trying to help me. [12:49] didrocks: its weird but https://code.launchpad.net/~mterry/bamf/c4/+merge/134313 landed with no issues [13:28] mmrazik: right, I think you need to snapshot the worspace where the tests failed and ask something in the unity team to look at it [13:28] ack. Will have a look on it. [13:30] didrocks: FYI -- I need to wait for max on the autopilot/unity thing :-/ Just a small demonstration that there is much more instability than just unity/autopilot... [13:31] but the good news is that I think I fixed autolanding for unity [13:31] I'll be going through the rejected MPs in a while and will be re-approving [13:39] mmrazik: ok, thanks [13:40] three cheers [13:40] hey bregma! :) [13:41] hey, how's it going? [13:41] good good, and you? :) [13:43] not too bad [13:43] I'm hoping the current nux-4/unity fandango has been resolved [13:43] but all the outstanding failed MPs will have to go through first [13:43] bregma: brandon's branch is compiling right now (~80%) [13:44] bregma: I'll go through the other ones once this is through [13:44] it's pretty much the key, that brancjh [13:53] bregma: it has just landed [13:53] or not? [13:53] mhm... [13:54] oh.. the job finished.. the merge didn't yet [13:54] * bregma holds his breath [13:56] bregma: its there now. really. [13:57] * bregma breathes again [14:05] bregma: the remaining failures seems to be genuine problems (like conflicts). If there is still something the I probably missed. Feel free to re-approve or ping me. [14:06] mkay === salem_ is now known as _salem === _salem is now known as salem_ === mmrazik is now known as mmrazik|otp [15:24] alesage: hey, good morning! [15:24] alesage: any news on landing the indicator inline packaging branchs? [15:24] didrocks, why hello [15:24] didrocks, I'll review during coffee, a few min pls :) [15:25] alesage: thanks :) [15:30] I want to make libnux render a better back cover how to do this ? [15:30] for RenderCoverFlow [15:30] Like when uri is active [15:30] I will take screenshot of wxample [15:31] example * [15:33] http://imagebin.org/235990 [15:33] 2d Concept work ^^ [15:33] didrocks, I'll test the new build style for i-sound, i-session, i-messages and will report; should take an hour [15:33] alesage: thanks a lot :) [15:34] that is what I want to do with NUX though like the "orange" that is on selected item. Or should I just change something to do with the card ? [15:34] alesage: don't merge i-session right now, see my needs fixing first :) [15:34] I think cyphermox will fix it once he's around [15:34] I'm around and ifixing it [15:35] didrocks, ok--we'll merge when someone clicks 'approve' in the mp [15:35] cyphermox: thanks! [15:36] alesage: the 2 others are green, feel free to needs review -> approve once you made the changes to the job [15:36] Sorry file is called CoverflowResultView.cpp [15:36] ok didrocks willdo [15:36] thanks ;) [15:40] CoverflowResultView.cpp << can not tell by shadowing what card is chosen so I thought that having background would be good thing. why is this code so dam hard !!!!!!!! [15:41] change the camara view and you can tell but still I do not want to make 20 ft interface only 10 [15:41] ;) [15:43] so like this layout_->AddView(coverflow_, 1, nux::MINOR_POSITION_CENTER, nux::MINOR_SIZE_FULL); ow to add color ? to backing of that ? [15:43] s|ow|how| [15:48] http://www.youtube.com/watch?v=8Tup9pD0Fps === mmrazik|otp is now known as mmrazik === salem_ is now known as _salem [15:55] I would like to say that I do not think that people are ignoring me. It is just that I want to make awesome sauce that is all :) I will get it === _salem is now known as salem_ === Guest75682 is now known as dpb___ === salem_ is now known as _salem [16:24] didrocks: if you want to try the tests now, not sure how much better it will work, here they just keep hanging [16:25] larsu: do you know about it? ^ [16:26] http://paste.ubuntu.com/1360585/ [16:26] didrocks, which tests are these? [16:26] indicator-session [16:26] larsu: ah, missing schema :) [16:26] what didrocks said :) [16:26] larsu: normal when you build it [16:26] but in that case, it should crash, not hang around doing nothing [16:26] you should do something similar to what I've done for the lens === _salem is now known as salem_ [16:28] larsu: http://bazaar.launchpad.net/~unity-team/libunity/trunk/view/head:/data/Makefile.am [16:28] it compiles the schema on build [16:29] larsu: and then using http://bazaar.launchpad.net/~unity-team/libunity/trunk/view/head:/test/vala/test-vala.vala#L35 to set it to the path [16:29] (XDG_DATA_HOME) [16:30] and compile ;) [16:31] didrocks, right. I'm going to pass this on to charles_ :) [16:31] charles_: seems you are the victim in that story :) === salem_ is now known as _salem === fenris is now known as Guest45110 === _salem is now known as salem_ [16:53] hey mterry, do you think you will have time for working on the bootstrapping of the unity stack? (other than the 3 I've made. I'm sorry, didn't have the time today to do the others, finishing the automated upload process) [16:54] didrocks, sure I'll work on them today [16:54] mterry: this sounds like spam for me tomorrow morning! Thanks a lot :) [16:54] yup :) === salem_ is now known as _salem === _salem is now known as salem_ [18:06] didrocks: when you're back: https://code.launchpad.net/~3v1n0/bamf/remove-gtk2/+merge/134537 (or mterry...) [18:06] Trevinho, neat [18:06] will be nice to lose that build [18:13] Trevinho, hi, i would introduce LIBBAMF_VER and just use "3" at those places [18:13] wouldnt* === francisco is now known as Guest1717 [18:21] bschaefer: Hi :) Video of Dash overlay-scrollbars looks great - Top Job ! :-D When will it land ? [18:22] MCR1, :), thanks. It should land in trunk in the coming weeks [18:22] bschaefer: So far away from merge ? [18:22] MCR1, no, I just want to polish it up and it is hard to say [18:22] ah, ok [18:23] MCR1, hopefully next week (hopefully!) [18:25] ricotz: I wanted to factorize that value... any better idea? [18:28] Trevinho, i think there is no need for that, or are you planning for GTK+4.0 ;) [18:30] ricotz: Hi :) Do you already have an ETA for plank-docky ? [18:31] MCR1, no ;) [18:31] ricotz: Still using the best dock no money can buy here... ;) [18:32] MCR1, quiet, do you where you are ;P [18:32] but unfortunately with a new bug introduced with latest fglrx ATI driver :( [18:33] sorry g2g [18:33] Yes, but I will voice my opinion anyway :P :-X === salem_ is now known as _salem === _salem is now known as salem_ === salem_ is now known as _salem [19:03] ricotz: no plan for gtk4, just don't want to keep magic numbers around :) === _salem is now known as salem_ [19:09] Trevinho, andyrock, bschaefer: Could you please take a look @ https://code.launchpad.net/~mc-return/unity/unity.merge-minor-possible-speed-improvement/+merge/133435 and https://code.launchpad.net/~mc-return/unity/unity.merge-fix-member-variables-not-initialized-in-their-constructors/+merge/133520 ? [19:11] MCR1, Ill look into it [19:11] MCR1, https://code.launchpad.net/~mc-return/unity/unity.merge-fix-member-variables-not-initialized-in-their-constructors/+merge/133520 [19:11] the init list should look like: [19:11] ctor() [19:11] : var(false) [19:11] not ctor() : [19:11] * bschaefer thinks it looks cleaner [19:12] MCR1, also no space between variable and ( [19:12] ok, I am always confused with different styles used for Compiz/Unity [19:12] :) [19:12] MCR1, yeeah compiz uses a crazy style [19:12] C++11, mixed spaces and tabs [19:12] well compiz doesn't use C++11 yet [19:13] and yes...they mix spaces and tabs :( [19:13] but no problem, I'll change it [19:13] to Unity style :) [19:13] thanks :) [19:14] ~20 min (girlfriend calls ;)) [19:14] MCR1, also keep in mind that .size() in c++11 is O(1) [19:14] so it's not so slow :) [19:14] but I prefer to use ::empty [19:14] so thank you [19:15] plus empty usually checks the size [19:15] but it is more readable [19:17] bschaefer, MCR1 talking about C++03 ::empty is faster using std::list and std::string [19:18] * bschaefer would think size is a stored variable [19:18] which empty should just return size; [19:18] if it == 0 ... its false [19:18] o well [19:18] bschaefer, gcc implementation did not store the size [19:19] oo i see [19:19] that makes sense [19:19] but now it does [19:19] it's a minor change but a big ABI break [19:20] I could imagine... === salem_ is now known as _salem [19:27] andyrock, that change was backed out of GCC 4.7 because it caused the ABI-incompatibility bug [19:27] 4.7.2 does not confirm, but at least it's not broken === _salem is now known as salem_ [19:31] bregma, so std::list::size on gcc 4.7 is still O(n) ? [19:49] bschaefer: Should be fixed now :) [19:49] MCR1, awesome [19:49] * bschaefer looks again [19:49] andyrock, bschaefer: Thanks for the reviews :) [19:49] ;) [19:49] MCR1, you missed andyrocks comment :( [19:49] + : icon_size (0) [19:49] no space between [19:50] e and ( [19:50] e ( [19:50] e( [19:50] * bschaefer feels extra picky for some reason [19:51] bschaefer: ups, will fix that also :) [19:52] MCR1, thanks :) [19:52] I've initialized the bool with false btw, not sure if this is ideal... [19:53] MCR1, what does it normally get set to? [19:54] MCR1, looking at that, it should be fine [19:55] bschaefer: Some initialize bools with true... [19:55] MCR1, hmm, let me look some more at the code [19:55] it might need to be true [20:30] fginther, I wanted to look at the jenkins failures in https://code.launchpad.net/~mterry/unity-scope-gdrive/dailybootstrap/+merge/134521 but the links are for a local jenkins install [20:37] mterry, bodge s-jenkins IP 10.97.0.6 into your hosts file for a quick/dirty fix? [20:38] mterry, or manually s/s-jenkins/10.97.0.6/ in those urls [20:38] http://10.97.0.6:8080/job/unity-scope-gdrive-ci/build=pbuilder,distribution=raring,flavor=amd64/5/console works for me [20:39] popey, fair enough [20:55] mterry, did popey's suggestion work for you? I'll ping the owner of this job to have it published to the external server [20:55] fginther, uh, let me see [20:55] fginther, nope. I get "could not connect to 10.97.0.6:8080" [20:57] you have vpn setup? [20:57] via batuan? [20:58] nope [20:58] I should have guessed with a 10. address [20:59] mterry, do you have a link of what you are trying to access? [20:59] * bschaefer has VPN [20:59] bschaefer, fginther is grabbing me a log I think [21:00] thanks though! [21:00] mterry, awesome, I was about to :) [21:01] mterry, (here it is anyway: http://paste.ubuntu.com/1361226/) [21:01] mterry, http://paste.ubuntu.com/1361227/ [21:01] wow, consecutive numbers [21:02] nice [21:02] fginther, bschaefer: Thanks! [21:02] fginther, this build error is dumb. Couldn't resolve bazaar.launchpad.net [21:02] fginther, is that build job broken? [21:04] must be the internets that's broken [21:04] mterry, there have been some infrastructure/networking changes regarding the build host. However, these should have cleared up before #5 ran [21:05] fginther, a separate gdrive branch just passed jenkins, so maybe it's fine now [21:05] fginther, though I notice that I'm not a member of ~online-accounts [21:06] mterry, you're membership should not matter, the branch is accessed via a special account [21:06] fginther, yeah, but it prevents me from toggling branch status [21:07] grumble... [21:07] fginther, it's odd that we use online-accounts for that one branch anyway [21:08] mterry, let me see if I can kick it [21:09] fginther, thanks. I have to run an errand right now anyway, but we can catch up later === salem_ is now known as _salem === _salem is now known as salem_ === salem_ is now known as _salem === _salem is now known as salem_ [22:02] bschaefer, andyrock, Trevinho: We have quite a bit of multimonitor bugs, which need to be fixed - One of them is that the Place Plugin's settings being ignored, because Unity is loaded after Place and got it's own window-place function. How can we best ensure in this function that the Place plug-in's Place function is called also ? [22:04] MCR1, make a bug about it [22:05] * bschaefer isnt 100% sure off the top of my head [22:05] bug 874146 [22:05] Launchpad bug 874146 in Compiz "Multimonitor: New windows open on the wrong monitor, Place Plugin settings silently ignored" [Undecided,In progress] https://launchpad.net/bugs/874146 [22:06] bschaefer: Do you run a multimonitor config ? [22:06] nope [22:06] :( [22:07] MCR1, are you talking about UnityWindow::place() ? [22:08] bschaefer: The problem is we have 2 place functions, which do not work together correctly - yes [22:08] andyrock: yes [22:08] exactly [22:08] and PlaceWindow is not called right? [22:08] PlaceWindow::place [22:08] and the combination with the place plug-in [22:08] or something like that [22:09] yes, the whole place plug-in gets ignored [22:09] so windows do not open correctly on the right monitor as specified [22:09] MCR1, did you talk with duflu? [22:10] but if you load the place plugin after unityshell it works correctly [22:10] no, but I talked with smspillaz [22:10] https://bugs.launchpad.net/compiz-core/+bug/874146/comments/30 [22:10] Ubuntu bug 874146 in Compiz "Multimonitor: New windows open on the wrong monitor, Place Plugin settings silently ignored" [Undecided,In progress] [22:11] here you can see how it *should* work [22:14] MCR1, I'm not too much in the problem but have you tried to call window->place(...) in UnityWindow::place [22:14] Sam told me we need to look at UnityWindow::place to see if you can prevent unity from overriding the place plugin [22:14] So can I just call CompWindow::place () inside of unityshell.cpp, yes ? [22:16] hmmm let me check the code [22:17] andyrock: It would be great if you can help here, because it is a really nasty bug - I've fixed it here (but with the wrong solution - by just ensuring that place gets started after uniutyshell...) [22:18] Here my discussion with Sam: https://code.launchpad.net/~mc-return/compiz/compiz.merge-fix874146-place-plugin-broken/+merge/130672 [22:19] MCR1, ::place returns a bool, do you know why? [22:20] To be honest: no ;) [22:21] you mean the place from place.cpp ? [22:23] no all the place functions :) [22:23] yeah, just noticed... [22:23] btw you just need to call window->place inside UnityWindow::place [22:24] I simply could not believe that the solution for this nasty long-time bug could be so simple... [22:25] MCR1, one moment [22:27] andyrock: It is the same Sam suggested... [22:27] MCR1, calling it ensures that place window is called too [22:28] moving bool result = window->place(pos); to the top of the function ? [22:30] MCR1 can you tell me a fast way to reproduce the bug? [22:30] sure, but you need multimonitor ofc [22:31] best see the description here: https://code.launchpad.net/~mc-return/compiz/compiz.merge-fix874146-place-plugin-broken/+merge/130672 [22:31] see [Test Case] [22:31] andyrock: Thx 4 your help here :) [22:32] MCR1, yeah i've a multimonitor [22:32] ;) [22:37] brb === salem_ is now known as _salem [22:44] MCR1, i can reproduce the bug in the MP description [22:44] it works just fine with the terminal [22:44] the windows open in the correct monitor [22:44] at the correct position [22:45] So you mean the Place plug-in settings are working correctly in current trunk ? [22:45] Or with the fix applied ? [22:47] with quantal vanilla [22:47] MCR1, [22:49] and with unity-trunk too [22:50] so can you reproduce the bug or you cannot reproduce it ? [22:50] sry - it is already late here ;) [22:53] MCR1, I cannot reproduce it :) [22:54] it's late for me too (23:54) [22:54] strange, but good news... I wonder when this changed - but perfect if it is fixed already... [22:55] so you can set the terminal window to open where the mousepointer is, yes ? [22:57] andyrock: Thx a lot 4 your help @ late hours... [22:58] MCR1, yeah my terminal follolow my mouse [22:58] *follows [22:59] great, fix released without any code then :) [23:02] MCR1, don't change the status for the moment [23:03] ok [23:03] MCR1, maybe it happens only for some monitor configurations [23:04] I could reproduce it 100%, but I am too tired to remove my fix here and retest... [23:05] MCR1, your monitor resolution? [23:05] 1920x1200 and 1280x1024 [23:05] and 1920 x1080 [23:05] which does not work as triple config with fglrx @ the moment... [23:06] so 3 monitors? [23:06] but worked as 3-screen with gallium [23:06] yes [23:06] well, 2 monitors and a TV :) [23:06] i have here also a maximizing problem with two different screens, don't know if it is also this place issue.. [23:06] but with fglrx just the 2 monitors are active [23:07] hmm, sorry on precise [23:07] Klap-in: No, that is probably bug 751605 [23:07] Launchpad bug 751605 in Compiz "Multi-monitor - Windows maximize on the wrong monitor" [Critical,In progress] https://launchpad.net/bugs/751605 [23:08] Klap-in: duflu is already working on it :) [23:09] MCR1: you're right! [23:09] nice [23:10] Hope it will backported to Precise once it's fixed, but guess it will be - but do not hold your breath while waiting for it ;) [23:17] improvement of the multimonitor behavior would be great, of course ;) [23:17] Klap-in: I agree 123% [23:44] fginther, hey, I was noticing that the jenkins jobs for unity seem to be based on quantal still. Seems wrong, no?