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