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 | 00:03 |
=== fenris is now known as Guest68936 | ||
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:08 |
mmrazik | (yet) | 07:09 |
didrocks | mmrazik: hum, I can just say "good luck" ;) | 07:09 |
mmrazik | didrocks: ack :) | 07:09 |
mmrazik | didrocks: sorry for spamming your MP | 07:30 |
mmrazik | but I'm getting closer :) | 07:30 |
didrocks | no worry ;) | 07:30 |
=== fenris is now known as Guest62485 | ||
tsdgeos | Trevinho: Mirv: what about https://code.launchpad.net/~aacid/unity/initialize_using_nofilters_background_6.0/+merge/132297 think it makes sense? | 08:47 |
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 | 08:59 |
mmrazik | didrocks: its ~27% fail rate | 09:00 |
didrocks | mmrazik: ok, I think you guys have a plan to work on it? :) | 09:04 |
mmrazik | sure | 09:04 |
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:05 |
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:06 |
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:15 |
mmrazik | is that a packaging issue? | 09:16 |
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:20 |
mmrazik | oh... missed that... only saw the "dh_auto_test: make -j1 check returned exit code 2" | 09:21 |
mmrazik | didrocks: mhm.. I'll try to re-approve. The next bamf MP passed the tests (but failed at dh_makeshlibs) | 09:25 |
didrocks | mmrazik: ok, keep me in touch, not having this bootstrapping makes us using other branches to test | 09:28 |
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:30 |
didrocks | thanks | 09:34 |
mmrazik | didrocks: beside the random make test failure we have one problem in bamf. | 09:45 |
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 | 09:46 |
=== 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_ | ||
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. | 11:47 |
cariveri | Hi larsu can you help me? | 12:07 |
larsu | cariveri, sure, what's up? | 12:09 |
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:11 |
=== mmrazik|lunch is now known as mmrazik | ||
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:12 |
cariveri | larsu: yes unity. unityshell/src ? | 12:13 |
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:14 |
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:16 |
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:17 |
didrocks | maybe | 12:18 |
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:21 |
didrocks | thanks | 12:22 |
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:24 |
=== fenris is now known as Guest89250 | ||
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:31 |
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:32 |
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:33 |
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:37 |
mmrazik | didrocks: its weird but https://code.launchpad.net/~mterry/bamf/c4/+merge/134313 landed with no issues | 12:49 |
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:28 |
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:30 |
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:31 |
didrocks | mmrazik: ok, thanks | 13:39 |
bregma | three cheers | 13:40 |
didrocks | hey bregma! :) | 13:40 |
bregma | hey, how's it going? | 13:41 |
didrocks | good good, and you? :) | 13:41 |
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:43 |
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:44 |
mmrazik | bregma: it has just landed | 13:53 |
mmrazik | or not? | 13:53 |
mmrazik | mhm... | 13:53 |
mmrazik | oh.. the job finished.. the merge didn't yet | 13:54 |
* bregma holds his breath | 13:54 | |
mmrazik | bregma: its there now. really. | 13:56 |
* bregma breathes again | 13:57 | |
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:05 |
bregma | mkay | 14:06 |
=== salem_ is now known as _salem | ||
=== _salem is now known as salem_ | ||
=== mmrazik is now known as mmrazik|otp | ||
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:24 |
didrocks | alesage: thanks :) | 15:25 |
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:30 |
bobweaver | example * | 15:31 |
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:33 |
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:34 |
alesage | didrocks, ok--we'll merge when someone clicks 'approve' in the mp | 15:35 |
didrocks | cyphermox: thanks! | 15:35 |
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:36 |
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:40 |
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:41 |
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:43 |
bobweaver | http://www.youtube.com/watch?v=8Tup9pD0Fps | 15:48 |
=== mmrazik|otp is now known as mmrazik | ||
=== salem_ is now known as _salem | ||
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 | 15:55 |
=== _salem is now known as salem_ | ||
=== Guest75682 is now known as dpb___ | ||
=== salem_ is now known as _salem | ||
cyphermox | didrocks: if you want to try the tests now, not sure how much better it will work, here they just keep hanging | 16:24 |
didrocks | larsu: do you know about it? ^ | 16:25 |
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:26 |
=== _salem is now known as salem_ | ||
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:28 |
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:29 |
didrocks | and compile ;) | 16:30 |
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:31 |
=== salem_ is now known as _salem | ||
=== fenris is now known as Guest45110 | ||
=== _salem is now known as salem_ | ||
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:53 |
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 :) | 16:54 |
=== salem_ is now known as _salem | ||
=== _salem is now known as salem_ | ||
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:06 |
ricotz | Trevinho, hi, i would introduce LIBBAMF_VER and just use "3" at those places | 18:13 |
ricotz | wouldnt* | 18:13 |
=== francisco is now known as Guest1717 | ||
MCR1 | bschaefer: Hi :) Video of Dash overlay-scrollbars looks great - Top Job ! :-D When will it land ? | 18:21 |
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:22 |
bschaefer | MCR1, hopefully next week (hopefully!) | 18:23 |
Trevinho | ricotz: I wanted to factorize that value... any better idea? | 18:25 |
ricotz | Trevinho, i think there is no need for that, or are you planning for GTK+4.0 ;) | 18:28 |
MCR1 | ricotz: Hi :) Do you already have an ETA for plank-docky ? | 18:30 |
ricotz | MCR1, no ;) | 18:31 |
MCR1 | ricotz: Still using the best dock no money can buy here... ;) | 18:31 |
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:32 |
ricotz | sorry g2g | 18:33 |
MCR1 | Yes, but I will voice my opinion anyway :P :-X | 18:33 |
=== salem_ is now known as _salem | ||
=== _salem is now known as salem_ | ||
=== salem_ is now known as _salem | ||
Trevinho | ricotz: no plan for gtk4, just don't want to keep magic numbers around :) | 19:03 |
=== _salem is now known as salem_ | ||
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:09 |
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:11 | |
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:12 |
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:13 |
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:14 |
bschaefer | plus empty usually checks the size | 19:15 |
bschaefer | but it is more readable | 19:15 |
andyrock | bschaefer, MCR1 talking about C++03 ::empty is faster using std::list and std::string | 19:17 |
* 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:18 |
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:19 |
bschaefer | I could imagine... | 19:20 |
=== salem_ is now known as _salem | ||
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:27 |
=== _salem is now known as salem_ | ||
andyrock | bregma, so std::list::size on gcc 4.7 is still O(n) ? | 19:31 |
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:49 |
bschaefer | e and ( | 19:50 |
bschaefer | e ( | 19:50 |
bschaefer | e( | 19:50 |
* bschaefer feels extra picky for some reason | 19:50 | |
MCR1 | bschaefer: ups, will fix that also :) | 19:51 |
bschaefer | MCR1, thanks :) | 19:52 |
MCR1 | I've initialized the bool with false btw, not sure if this is ideal... | 19:52 |
bschaefer | MCR1, what does it normally get set to? | 19:53 |
bschaefer | MCR1, looking at that, it should be fine | 19:54 |
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 | 19:55 |
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:30 |
popey | mterry, bodge s-jenkins IP 10.97.0.6 into your hosts file for a quick/dirty fix? | 20:37 |
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:38 |
mterry | popey, fair enough | 20:39 |
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:55 |
popey | you have vpn setup? | 20:57 |
popey | via batuan? | 20:57 |
mterry | nope | 20:58 |
mterry | I should have guessed with a 10. address | 20:58 |
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 | 20:59 |
mterry | thanks though! | 21:00 |
bschaefer | mterry, awesome, I was about to :) | 21:00 |
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:01 |
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:02 |
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:04 |
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:05 |
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:06 |
fginther | grumble... | 21:07 |
mterry | fginther, it's odd that we use online-accounts for that one branch anyway | 21:07 |
fginther | mterry, let me see if I can kick it | 21:08 |
mterry | fginther, thanks. I have to run an errand right now anyway, but we can catch up later | 21:09 |
=== salem_ is now known as _salem | ||
=== _salem is now known as salem_ | ||
=== salem_ is now known as _salem | ||
=== _salem is now known as salem_ | ||
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:02 |
bschaefer | MCR1, make a bug about it | 22:04 |
* bschaefer isnt 100% sure off the top of my head | 22:05 | |
MCR1 | bug 874146 | 22:05 |
ubot5 | 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:05 |
MCR1 | bschaefer: Do you run a multimonitor config ? | 22:06 |
bschaefer | nope | 22:06 |
MCR1 | :( | 22:06 |
andyrock | MCR1, are you talking about UnityWindow::place() ? | 22:07 |
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:08 |
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:09 |
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:10 |
ubot5 | Ubuntu bug 874146 in Compiz "Multimonitor: New windows open on the wrong monitor, Place Plugin settings silently ignored" [Undecided,In progress] | 22:10 |
MCR1 | here you can see how it *should* work | 22:11 |
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:14 |
andyrock | hmmm let me check the code | 22:16 |
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:17 |
MCR1 | Here my discussion with Sam: https://code.launchpad.net/~mc-return/compiz/compiz.merge-fix874146-place-plugin-broken/+merge/130672 | 22:18 |
andyrock | MCR1, ::place returns a bool, do you know why? | 22:19 |
MCR1 | To be honest: no ;) | 22:20 |
MCR1 | you mean the place from place.cpp ? | 22:21 |
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:23 |
MCR1 | I simply could not believe that the solution for this nasty long-time bug could be so simple... | 22:24 |
andyrock | MCR1, one moment | 22:25 |
MCR1 | andyrock: It is the same Sam suggested... | 22:27 |
andyrock | MCR1, calling it ensures that place window is called too | 22:27 |
MCR1 | moving bool result = window->place(pos); to the top of the function ? | 22:28 |
andyrock | MCR1 can you tell me a fast way to reproduce the bug? | 22:30 |
MCR1 | sure, but you need multimonitor ofc | 22:30 |
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:31 |
andyrock | MCR1, yeah i've a multimonitor | 22:32 |
MCR1 | ;) | 22:32 |
andyrock | brb | 22:37 |
=== salem_ is now known as _salem | ||
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:44 |
MCR1 | So you mean the Place plug-in settings are working correctly in current trunk ? | 22:45 |
MCR1 | Or with the fix applied ? | 22:45 |
andyrock | with quantal vanilla | 22:47 |
andyrock | MCR1, | 22:47 |
andyrock | and with unity-trunk too | 22:49 |
MCR1 | so can you reproduce the bug or you cannot reproduce it ? | 22:50 |
MCR1 | sry - it is already late here ;) | 22:50 |
andyrock | MCR1, I cannot reproduce it :) | 22:53 |
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:54 |
MCR1 | so you can set the terminal window to open where the mousepointer is, yes ? | 22:55 |
MCR1 | andyrock: Thx a lot 4 your help @ late hours... | 22:57 |
andyrock | MCR1, yeah my terminal follolow my mouse | 22:58 |
andyrock | *follows | 22:58 |
MCR1 | great, fix released without any code then :) | 22:59 |
andyrock | MCR1, don't change the status for the moment | 23:02 |
MCR1 | ok | 23:03 |
andyrock | MCR1, maybe it happens only for some monitor configurations | 23:03 |
MCR1 | I could reproduce it 100%, but I am too tired to remove my fix here and retest... | 23:04 |
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:05 |
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:06 |
Klap-in | hmm, sorry on precise | 23:07 |
MCR1 | Klap-in: No, that is probably bug 751605 | 23:07 |
ubot5 | Launchpad bug 751605 in Compiz "Multi-monitor - Windows maximize on the wrong monitor" [Critical,In progress] https://launchpad.net/bugs/751605 | 23:07 |
MCR1 | Klap-in: duflu is already working on it :) | 23:08 |
Klap-in | MCR1: you're right! | 23:09 |
Klap-in | nice | 23:09 |
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:10 |
Klap-in | improvement of the multimonitor behavior would be great, of course ;) | 23:17 |
MCR1 | Klap-in: I agree 123% | 23:17 |
mterry | fginther, hey, I was noticing that the jenkins jobs for unity seem to be based on quantal still. Seems wrong, no? | 23:44 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!