[05:41] Good morning [07:16] morning! [07:17] good morning [07:19] morning! [07:20] morning folks [07:20] hey larsu, ochosi [07:20] larsu: quick question, where is your gtk3.14 staging PPA? (so i can start to prep the xubuntu vivid themes) [07:22] ochosi: in the desktop team ppa [07:22] pitti: hey, welcome back! I hope you had a safe flight back :) [07:22] pitti: I saw that you were cooking this week-end [07:22] and pushing new systemd :) [07:23] pitti: I wanted to know if there was any reason you didn't include bug #1400682 patch? [07:23] larsu: oh indeed. note to self: don't start asking around *before* having had coffee... [07:23] bug 1400682 in systemd (Ubuntu) "Add xdiagnose fallback when display-manager fails to start" [Undecided,New] https://launchpad.net/bugs/1400682 [07:24] ochosi: haha, no worries ;) [07:55] bonjour didrocks, ça va ! [07:55] didrocks: yes, flight was uneventful, and I could sleep a bit too [07:55] didrocks: the main reason was, I did the merge/update mostly on the plane, and I didn't have that patch downloaded yet :/ [07:55] didrocks: but there is a test regresssion and a timedatectl crash on i386 anyway, so I'll need to upload a new version today anyway [07:55] didrocks: I have that bug open now :) [07:59] pitti: perfect, thanks! [07:59] pitti: nice that you could sleep, how long was it btw? [07:59] I guess something like 9-10 hours? [08:00] didrocks: 11 hours [08:00] 18:55 to 5:30 on the way back, 22:55 to 10:50 on the way there (1 h time zone difference) [08:01] yeah, quite long, at least, no jetlag :) [08:11] larsu: quick question, is file-roller on your list of apps to remove CSD? [08:14] I should not be allowed to have smartphones :P [08:16] mlankhorst: breaking one? [08:16] yeah I cracked the screen on the aquaris [08:17] it's still a build machine at least [08:18] true but I was using it to test.. if I can figure out how to get the screen permanently unlocked and bright it would be fine [08:19] mlankhorst: you can maybe get it repaired? [08:19] like I don't think it's a particular screen compared to android versions [08:20] ochosi: I thought seb already patched that?! [08:21] ochosi: it doesn't have csd on latest vivid, or are you talking about a new version? [08:21] didrocks: is it possible to unlock the screen without using the touchscreen? I already have the phone setup [08:21] adb shell etc works [08:21] larsu: this is vivid with the ubuntu-desktop PPA (gtk3.14) and file-roller: http://i.imgur.com/n36Mjdz.png [08:22] mlankhorst: not that I know of [08:22] larsu: i'll switch mirrors, maybe mine is lagging behind... [08:22] mlankhorst: I would really try to go to a repair shop, the model from what I know is similar to the android one [08:22] so they should have that screen [08:23] ochosi: which desktop? I have a normal title bar on unity [08:23] larsu: xubuntu [08:23] didrocks: it's identical, but yeah I guess I can take a look [08:23] larsu: did you only add a check for unity? [08:24] larsu: my guess is that both mythbuntu and ubuntu-studio (maybe even u-mate) would appreciate "!=gnome" instead of "==unity" [08:24] and lubuntu probably [08:24] ochosi: it checks for GNOME: http://bazaar.launchpad.net/~ubuntu-desktop/file-roller/ubuntu/view/head:/debian/patches/bz_unity_headerbar.patch [08:25] weird [08:25] larsu: we really need a framework to tweak that on runtime, by capability I guess [08:25] like "support-overlay-scrollbar" [08:25] "support-appmenu" [08:25] "disable-foo" [08:25] larsu: not sure you noticed, but it has a normal menu plus a headerbar, so something is fishy there [08:26] (yeah, I know, I introduced this per-session name based in 2009/2010, but I regret now :p) [08:26] larsu: better visible here: http://i.imgur.com/waneudI.png [08:27] didrocks: ya... we talked about having another xsetting, like we do for global menu and buttons in dialog headers [08:27] larsu: yeah, that would make sense [08:27] didrocks: consensus so far has been "oh no, not another xsetting" [08:27] as there is no phone, tablet or whatsoever [08:27] done properly, there is "touch screen", "keyboard", "screen size", "battery" [08:27] ochosi: probably because gtk-shell-shows-menubar is 0 [08:27] and changing the app/framework behavior on that [08:28] larsu: did you try to compare that to media queries? [08:28] didrocks: compare what? [08:28] interesting idea, though... [08:28] like, media queries are really trying to do that and base on capability rather than form factor/session [08:28] right [08:28] larsu: just taking web media queries as an example as part of that discussion [08:28] as an argument :) [08:29] larsu: not the most important thing right now, but this discussion just makes me thinking that :) [08:30] didrocks: makes a lot of sense to me. We'd still need something like xsettings to provide the values, though === ara is now known as Guest73317 [08:30] larsu: yeah, that's clearly one of the way to achieve this [08:30] just talking about the general concept, before we introduce an unity8-desktop for instance :) [08:31] finding a grub script typo -> *not* fun [08:31] the unity8 guys have a plan [08:31] I don't know what that is, though [08:31] we should follow the same one for desktop for sure (not implementation-wise, but for coherence) [08:32] anyway, sorry for side-tracking :) [08:32] waiting for grub2 to pass tests (again :p) [08:33] larsu: right, so should i report a bug about this? [08:34] didrocks: haha, no worries :) [08:34] ochosi: I'm not sure what the issue is? [08:35] you don't have a global menu in xubuntu, do you? [08:35] so having that xsetting set to 0 is correct, and you get a local menu [08:35] larsu: ehm, the issue is that file-roller has CSD..? [08:35] the menu part is fine [08:36] it was just confusing for me that there could be a mix [08:36] I don't understand how that is confusing. If you tell gtk that you want a header bar and a menu inside the window, that's what you get [08:36] what's in your XDG_CURRENT_DESKTOP? [08:40] larsu: it's XFCE [08:43] sry, g2g, bbl [08:43] ochosi: ah, it is a bug in the patch [08:43] I can reproduce [08:46] ochosi: which version do you have installed? The patch I linked to is not yet in vivid [08:46] http://bazaar.launchpad.net/~ubuntu-desktop/file-roller/ubuntu/revision/150 [08:46] Laney: is file-roller file-roller blocked on anything? [08:58] morning [09:01] hey willcooke, feeling better? [09:02] heya [09:02] morning Laney, good week-end? [09:03] morning Laney, willcooke [09:04] didrocks, not really. Paracetamol helps [09:04] urgh :/ [09:05] willcooke: take it easy, soon holidays! [09:05] heh # [09:05] hey didrocks et larsu [09:05] looking forward to it [09:05] not bad thanks, did some xmas shopping ;-) [09:06] you guys? [09:06] larsu: file-roller> not sure offhand, did robert-ancell do that one maybe? [09:06] played some nice board games and finished watching breaking bad :) [09:06] Laney: don't know, thought you might [09:06] still haven't played that game I got in DC :( [09:07] larsu: I'll take a look [09:08] thanks [09:09] the one we have now checks for Unity to disable csd [09:09] the new one checks for !GNOME [09:09] they did that upstream? [09:09] no, robert_ancell did (and you committed it apparently) [09:10] http://bazaar.launchpad.net/~ubuntu-desktop/file-roller/ubuntu/revision/150 [09:10] i see [09:11] "(blocked on gtk 3.14)" [09:11] Laney, about everything is blocked on gtk 3.14 now (for us anyway!) [09:12] pitti: I hope I'm using git-dpm well and patching the grub patch to generate other installed init system FYI [09:20] darkxst: ya, lots for us too, might be that we can deal with the remaining issues post upload [09:20] I need to test ubiquity though [09:31] Laney, hi :), just a small request, could you define the mir minimum-requirement in the gtk+3.0 packaging? [09:32] what is it? [09:37] didrocks: sure -- if it looks ok and dpkg-source is happy, it's good :) [09:38] Laney, idk, at least the trusty version is not sufficient [09:38] I could make it >= what-we-have-now [09:38] you probably just want to disable that for the PPA [09:40] i know and i will, still would be nice to keep track on such things [09:42] also there is a 3.14.6 ;) [09:44] yep [09:57] larsu: I see you got an ok for your icon patch ;-) [09:58] Laney: I dumbed it down considerably with only 2 lines left [09:58] ya [09:59] seems this is acceptable [09:59] speaking of which - virtmanager has large buttons because one of the toolbar icons is 48x48 [09:59] * larsu figured that out after inspecting css for 20 minutes [09:59] what about the borders? [10:01] borders have always been on those, no? [10:01] I can remove them if you prefer [10:02] don't think so [10:02] one sec, lemme boot utopic [10:06] larsu: http://people.canonical.com/~laney/weird-things/virt-manager.png trusty [10:07] http://people.canonical.com/~laney/weird-things/virt-manager-new.png that's with 3.14.5 [10:08] I stand corrected. Thanks. [10:10] Laney: you never told me how great schroot is [10:10] desrt: dude, welcome to the enlightened [10:11] i jhbuild on fedora on my ubuntu linode [10:11] yo dawg and all that [10:11] schroot? [10:11] desrt: good ... err ... morning? [10:11] hi :) [10:11] you're up early [10:12] larsu: it's a system for maintaining images of other distros that you can chroot into [10:12] it has some extremely lovely features [10:12] coool [10:12] like the way i'm using it now, it unpacks a fresh .tar each time [10:12] so i can explode it however i want [10:12] and when i logout, it deletes it [10:12] it also has a lot of really great features like automatically bindmounting /sys /proc /dev and (insanely usefully) /home [10:13] larsu, jhbuild is a major hack, schroot would be better, but it helps finding ubuntu issues [10:13] i've used it from time to time when Laney wants me to fix a bug on some weird arch or another but i only really "learned" it this weekend [10:13] i should done that years ago [10:13] *shoulda [10:13] desrt: you can even mount the overlay as tmpfs to avoid the unpacking :) [10:13] didrocks: linode has no aufs support in their kernels :( [10:14] argh, so switch to btrfs and use nspawn coming with systemd 219 ;) [10:14] meh [10:14] containers are too heavy [10:14] i also really really really like how desrt on the outside is desrt on the inside [10:14] it's totally perfect [10:14] darkxst: this seems to be for a different use case than jhbuild... [10:14] desrt: ahah, nicely said :) [10:14] (which I'm actualy quite fond of these days) [10:15] * desrt did a pile of jhbuild hacking over the weekend [10:15] larsu, yes GNOME upstream has no sbuild/schroot stugg [10:15] i added support for finding out about _all_ of the things that are needed to build the lower bits of gnome [10:15] including the stuff that we couldn't previously add checks for (libxml2-python, docbook-xsl) [10:16] and now i have a new mode that dumps the full list in machine readable form like pkgconfig:egl,c_include:jpeglib.h,... [10:16] desrt, like making system modules satisfy jhbuild? [10:17] and another script that runs that list against a Contents.gz from apt-file and comes up with various solutions [10:17] darkxst: ya... [10:17] desrt, you're up early [10:17] or late ... [10:17] early :) [10:17] Laney: maybe you could help me with some of the issues i hit [10:17] i asked in #debian but it was pretty slow over the weekend [10:18] #debian-devel might be better for that kind of q [10:18] first issue is that i want to find a way to effectively say: apt install a b 'c | d' e f 'g | h' [10:18] where c/d are alternatives for the same functionality and g/h the same for another [10:18] like jpeg vs. jpeg-turbo or something [10:19] currently my script takes all of the possibile combinations of the alternatives, does apt dry-runs on them all and calculates a 'cost' based on the number of reported Inst and Remv lines (with removals costing 1000 times more than adds) [10:20] then it picks the lowest cost [10:20] I'd build a .deb with that in Depends: and let apt figure it out [10:20] unfortunately that involves doing apt dry-runs of ~1000 operations over 192 possible combinations... which takes 5-10 minutes :( [10:20] Laney: ya.... i was hoping for a better way [10:20] more direct [10:21] that's what sbuild does when it resolves build-deps, for example [10:21] also: Depends: lines are a bit "opinionated", right? [10:21] or there's a script called mk-build-deps [10:21] like, the thing on the left is the one that is taken unless the others are already installed, no? [10:21] ya [10:21] well, kind of, if it's not installable then it'll try the other one [10:21] does it do that even if the 'cost' is high? [10:22] like for example say i had libfooa and libfoob mutually conflicting [10:22] they have corresponding libfooa-dev and libfoob-c [10:22] *-dev, sorry [10:22] then package 'c' depends on libfooa-dev | libfoob-dev [10:22] and my system had libfoob installed [10:22] will apt uninstall libfoob in order to get me libfooa-dev just because i didn't have libfoob-dev? [10:24] because in that case i'd sort of hope for the more reasonable "oh... he's already got libfoob... so probably he just wants the -dev of that"... which is what my 'minimum cost' thing was tilting for [10:25] you know.. mk-build-deps is not bad...... and it would additionally give me an artifact that i could install in order to force all of the depends of my jhbuild to stay installed [10:26] I think apt is smart enough to prefer not to remove packages if it can [10:26] but you get into mvo territory at this point [10:26] i already sent him an email :) [10:27] or you could do some experimentation [10:27] i'll see if i can play with mk-build-deps [10:27] ya... [10:27] see what it gets me [10:27] 'equivs' is a tool for building packages which don't do anything other than have metadata [10:27] so you can test using that [10:27] great advice. thanks. [10:27] or even use it to generate your fake package for dep solving [10:27] i had another issue, but it's less likely you know about it (or even that it has a solution at all) [10:28] i want a command that i can call that will answer the question "which package do i have to install in order to get a given uri into the system xml catalog" [10:29] ie: i want to know what will make 'xmlcatalog /etc/xml/catalog http://docbook.sourceforge.net/release/xsl/current/' return a positive result [10:31] (my current thinking towards a best solution here is to hardcode the package name 'docbook-xsl'... i don't plan on the xml depends of jhbuild undergoing a dramatic expansion any time soon... but a generic solution would be nice...) [10:39] sorry, had a guy around checking the energy efficiency of the house... gone now... [10:40] very nice of him [10:40] I think that particular operation is done by packages invoking update-xmlcatalog in their mantainer scripts which are usually generated by dh_installxmlcatalog during the build [10:40] soooo no I don't know of a way you could determine that :) [10:40] ya.. i'm aware of that much, but it's sort of the opposite of what i want [10:40] i'd need somewhere a database of all the people who ever do that [10:41] in general, we need to start getting better information about this sort of stuff into apt... [10:41] * desrt wants to apt install pkgconfig:gl or apt install c_include:jpeglib.h or apt install python2:libxml2 [10:42] or (xml:http://whatever) [10:45] Laney: is there a better way to install-with-deps than using apt-get install -f? [10:46] the proposed solution in my contrived case above is removing the package with the alternative depends [10:46] maybe gdebi, but I'm not sure what resolver it uses [10:46] or make a local repository using dpkg-scanpackages and put that into sources.list [10:47] ISTR some talk about apt getting "apt install .deb" [10:48] Laney: long overdue, that one.... [10:49] DonKult @ #debian-devel might know more - he's an apt guy [10:51] Laney: the idea of adding a local repository is interesting -- i don't even actually need the .deb files in that case [10:51] can just ask apt "what would you do" based on the Packages file [10:51] in any case, the result of the experiment is that apt does 'the wrong thing' [10:55] (ie: it wants to remove libfoob) [11:06] ubiquity seems ok with new gtk [11:11] closing in on the upload [11:29] \o/ Laney [11:31] xnox: remembered to check it this time ;-) [11:31] ps. nice christmas tree [11:31] =)))) [11:33] shared mine with you on g+ [11:37] Laney: haven't been on g+ for a while. [11:37] .... lennart invited me to systemd hack-fest. [11:37] haha [11:37] it seemed like a reasonable option from the android share menu [11:37] pitti: are you going for lennarts/systemd fosdem hackfest? [11:38] xnox: yes, I will [11:39] didrocks: as well and marco d'Itri. [11:41] pitti: i'll ponder about it. [11:59] larsu: do you need to get someone to review https://code.launchpad.net/~larsu/ubuntu-themes/gtk-314 ? [12:09] Laney: yes, but I've just started working on it again [12:09] seb128 tried it last week and didn't notice any issues [12:09] yes I've been trying it too [12:09] not hugely qualified to review though [12:10] that's fine, I'm not hugely qualified to write it ;) [12:10] if we're going to upload gtk then this needs to go in too [12:10] yep [12:11] * larsu is fixing toolbar buttons right now [12:11] ok, please put up a MP when that's done :) [12:12] "done". lol. [12:12] I believe in you! [12:12] haha - there are little issues all over the place [12:12] and changing something in the theme _always_ breaks something else [12:13] we need some way to properly test theming [12:13] it doesn't have to be 100% to get it in vivid [12:13] of course [12:13] let me finish the toolbar/flat button stuff and then I'll MR [12:14] did you notice that the session selector in unity-greeter got a border too? [12:14] :) [12:15] I did now :) [12:15] put it on the pad [12:15] not a priority [12:15] yep [12:15] thanks === pstolowski is now known as pstolowski|lunch [12:22] didrocks: FYI, I sent a fix for the timedatectl regression upstream and fixed test_profile in Debian git; I'm now trying to reproduce the NSpawn.test_boot failure (doesn't happen locally) [12:23] didrocks: so uploading a new version will still take a bit, but I'll see to getting it done by tomorrow [12:23] I'll be off for the afternoon [12:25] pitti: take care [12:25] hey desrt, how are yoU? [12:25] busy :) [12:25] pitti: thanks for keeping me posted, now that I sent the grub thing, I'm about to finish some desktop developer stuff. Then, moving on on more systemd work [12:25] pitti: still want to discuss with you about fsck before pushing more :) [12:25] but let's do that tomorrow [12:26] pitti: you going to the systemd hackfest in brussels? [12:30] desrt: (OTP) yes, I will [12:30] desrt: will you be on fosdem, too? [12:30] yes [12:31] hopefully will get some kdbus stuff nicely tied up there [12:41] didrocks, cheapo ebay laptop battery update.... wont charge above 60% now. [12:42] willcooke: yeah, so the cheap was really "cheap" :/ [12:43] quelle surprise [12:43] well, see the positive side: it didn't explode when you plugged it [12:43] :D [12:43] ;) [12:43] yet [12:43] LOL! [12:44] roh [12:51] didrocks: I responded to bug 1400682 [12:51] bug 1400682 in systemd (Ubuntu) "Add xdiagnose fallback when display-manager fails to start" [Undecided,New] https://launchpad.net/bugs/1400682 [12:53] Laney: i don't see any pictures shared with me on G+... did you use the right account instead of a defunct @canonical.com one? [12:53] don't know, I typed your name in the app ^o) [12:55] pitti: agreed, doing this change and closing the bug report then [12:55] xnox: https://plus.google.com/u/0/109160032876474505377/posts that one [12:56] Laney: right - so I see if it I go to your page, but I didn't get a notification about it =/ [12:57] Laney: yours is lovely and tall and nice toys - just enough. [12:57] Laney: mine is much shorter than that and more fluffy [12:57] it expanded after we got it home [12:57] wanted something skinnier [12:57] i like the fluffiness ^_^ [13:02] pitti: I guess on the bug report, you wanted to tell "graphical.target.d" or really "display-manager.service.d" (and so, using RequiredBy=) [13:21] larsu: ah right. the version of file-roller i have is 3.12.2-0ubuntu1 (so standard vivid) [13:32] Laney, was it intended to drop "--include-image-data" from update-icon-cache? [13:32] pitti: done, tested and uploaded in https://launchpad.net/ubuntu/+source/xdiagnose/3.7.1 [13:33] * didrocks goes for some cycling === pstolowski|lunch is now known as pstolowski [13:37] didrocks: I actually meant display-manager.service.d/, so that we can keep to Wants= [13:37] didrocks: oh wow, thanks! [13:38] pitti: the issue is that we would have graphical.target still active [13:38] I'm unsure we would want that [13:38] didrocks: you didn't ref/close the bug? [13:38] right now, it's overriding well as a Requires [13:38] oh, invalid [13:38] pitti: yeah, it's not exactly the same approach/component, so didn't retarget it [13:39] didrocks: anyway, great to see that this .d/ thing works! [13:39] yeah ;) [13:39] didrocks: now, 218 isn't in vivid yet, but I'll work on that as fast as possible :) [13:39] pitti: we can just override display-manager.service.d if you prefer in the future, I'm just not feeling confortable letting graphical.target as active when the graphical server didn't really start [13:39] pitti: actually, it's working on 217 as well [13:40] 218 just introduce the edit command [13:40] didrocks: ok, that seems fine [13:40] didrocks: oh right [13:40] this override mechanism are how generators are working in /run/system/ actually :) [13:40] I just didn't map into my brain, but yeah, way nicer [13:40] thanks for the suggestion :) [13:42] * pitti hgus didrocks [13:42] ok, I'm off for some hours to do some christmas shopping [13:43] * didrocks hugs pitti back [13:43] enjoy! (and good luck) [13:44] * didrocks really off to some exercise now [14:11] larsu: another question, if i may, is patching CSD in gnome-calculator also on your list? [14:13] hello everyone [14:14] Trevinho: hey, do you remember the focus storing change (fix for bug #1125442)? [14:14] bug 1125442 in Compiz 0.9.11 "Always Visible and On Top Windows Steal Focus on Workspace Switch" [Low,In progress] https://launchpad.net/bugs/1125442 [14:16] Trevinho: there was a regression caused by the change (bug #1393020), do you have any idea how to differentiate viewport moving caused "manually" from those caused by clicking on the launcher (like in the bug description) on the compiz level? [14:16] bug 1393020 in compiz (Ubuntu) "[regression] "Remember Focus" does not play well with unity launcher so shouldn't be default enabled or better yet the rev should be reverted" [High,In progress] https://launchpad.net/bugs/1393020 [14:16] dgadomski: hi [14:17] dgadomski: mh, no I don't remember a way now... but I could investigate [14:18] dgadomski: however, Brandon Schaefer (now offline, it will be back in about 2hrs) said me he prepared a fix for that changwe [14:18] dgadomski: so, if you wait him to join yo could have a chat with him about that [14:19] ochosi: again, works on unity :) [14:19] ochosi: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/vivid/gnome-calculator/vivid/view/head:/debian/patches/git_no_headerbars_in_unity.patch [14:19] ochosi: probably we should update this to !GNOME as well [14:19] yeah: if (!is_desktop ("Unity")) [14:19] Trevinho: great, I will talk to him, thanks! [14:20] larsu: yeah, would be great in order for things to be consistent, at least across desktops [14:20] ricotz: that's only in the gtk2 one, right? and I think it's going to be dropped from there too [14:20] so... yes [14:54] need some help with compiz in 14.04 i activatewd dual loghin compoz and metacity an can't align the 3d windows on the cube they form outside the cube [15:14] Laney, i meant the gtk3 3.14.5 packaging [15:14] where do you think it got dropped? [15:16] Laney, iirc I added it in the early gtk3 packaging for gnome3 ppa, and I thought it is needed still [15:18] ignore me if it isn't needed anymore and i will drop it as well [15:50] I wonder if any core-dev would be happy to ack compiz https://ci-train.ubuntu.com/job/ubuntu-landing-012-2-publish/46/artifact/packaging_changes_compiz_1%3A0.9.12.0+15.04.20141210.2-0ubuntu1.diff ? ...or if I'll ask for better changelog. all of that is related to the line "added support for multi-arch installations" [15:51] mostly the cleanup to remove all debian/tmp/ from *.install could have been mentioned as well [16:54] dgadomski, hello! [16:55] bschaefer: hey [16:55] did you have some questions about the workspace needing reverting? [16:56] I wanted to fix bug #1125442, but Trevinho told me that you were working on some fixes already [16:56] bug 1125442 in Compiz 0.9.11 "Always Visible and On Top Windows Steal Focus on Workspace Switch" [Low,In progress] https://launchpad.net/bugs/1125442 [16:56] dgadomski, well i wasn't actually work on a fix atm [16:57] i fixed a bug your prev merge caused but that was a simple fix. The main other issue would be to not re-focus a cached window when clicking on a launcher icon [16:58] Trevinho, do you remember how the launcher icon actually focus an icon on a differnet workspace? [16:58] we call a workspace switch in unity or compiz? [16:58] bschaefer, oh, sorry, I pasted wrong link, this was the bug I was thinking about: bug #1393020 [16:58] bug 1393020 in compiz (Ubuntu) "[regression] "Remember Focus" does not play well with unity launcher so shouldn't be default enabled or better yet the rev should be reverted" [High,In progress] https://launchpad.net/bugs/1393020 [16:59] dgadomski, right, i assigned my self that bug just because i reverted your merge [16:59] (not really a fix though) [16:59] bschaefer: all unity side should bein PluginAdapter::FocusWindowGroup [16:59] * bschaefer looks [17:00] bschaefer: so, there's no direct request to switch to another vp... it just happens when you ask compiz to focus a window [17:00] Trevinho, i see, so we can patch that bit of code in compiz i suppose? [17:00] that should be in ... screen/window.cpp? [17:00] bschaefer: I suppose [17:01] bschaefer: probably on activate window [17:01] Trevinho, well ideally we need to think of a better way to cache said window [17:06] dgadomski, but ideally, we need to come up with a way to restore focus on that cached window [17:06] if and only if its on that workspace and we are not focusing a new window on that workspace [17:07] bschaefer: I was debugging this and I saw that moveViewport (where the window is cached) is called in both cases and I was not able to determine how to differentiate between "manual" viewport changing versus the launcher-initiated [17:08] right, that was a worry of mine as well... though we might have to figure out a better way to cache the window [17:08] dgadomski, theres a place somewhere in compiz [17:08] that focuses a window [17:08] thats what the launcher uses, and in there it switches the viewport [17:09] so we can detect when the launcher is being used, or rather we can detect when a window is being focus (hopefully?) [17:09] * bschaefer looks at compiz [17:21] Trevinho, dgadomski looks like the wall plugin causes the window to be moved [17:21] you can test that out by disabling the plugin then attempting to click on a launcher icon... strange [17:23] bschaefer: what do you mean by "causes the window to be moved"? [17:25] dgadomski, err not window to be moved but workspace/viewport to be moved [17:26] bschaefer: yeah, and if you change the wall to e.g. cube you are still affected by this issue, so this needs to be fixed below the plugin layer [17:26] dgadomski, right, but we need to ensure the plugins work as well [17:27] dgadomski, the issue being that the unity launcher is using the wall plugin (or rather the wall plugin is auto moving workspaces to the "wanted" focused window) [17:27] * bschaefer might not be making much sense [17:28] bschaefer: I see your point, the unity launcher also works in the same way with cube, so probably cube also moves viewports while focusing a window outside current viewport [17:29] dgadomski, right, so if those plugins are disabled [17:29] all is well [17:29] but we have the wall enabled, meaning it'll attempt to focus a window [17:29] on its viewport [17:29] so we need to add a case in that plugin to be handled [17:29] dgadomski, then i think we can get the fix re-merged :) [17:29] compiz is ... like a N headed monster where N is the number of plugins enabled... [17:31] bschaefer: Trevinho mentioned earlier that there may be a way to recognize the reason behind the moveViewport inside compiz [17:31] bschaefer: lol, more like N = 2^n_plugins [17:31] larsu, haha... true [17:31] +RAND(10) [17:31] Trevinho, ^ [17:32] n^n [17:32] dgadomski: ehm? :P [17:33] i like to imagine the best way this could turn out... We need to have ideally on each workspace a last focused window [17:33] " dgadomski: mh, no I don't remember a way now... but I could investigate" [17:33] when we have landed on said workspace we need a way to check "Did we just change focus to get here?" vs "We just got here, change focus to last focused window" [17:34] those two cases are the tricky part, but what "should" happen [17:34] Trevinho: so if you don't remember a way not it means that there probably was a *WAY* :) [17:34] is as soon as the launcher focuses the window, the last focused window for that workspace should be updated [17:34] which would resolve our issues [17:34] dgadomski: oh, yeah... there is... :) [17:34] Trevinho, haha [17:35] dgadomski, so we need to look at making sure we update the last focused cached window per workspace [17:35] if we can do that, then when the launcher focuses a window on any workspace, that workspace updates its last focused window and we are set :) [17:35] bschaefer: it's very likely that each workspace plugin (like wall or cube) implements that switch [17:35] Trevinho, i greped [17:35] Trevinho, but it doesn't matter, we can get around this under the hood [17:36] Trevinho, all we have to check for is FOCUS OF NEW WINDOW [17:36] when a new window is focused update the last focused window on the workspace its on [17:36] bschaefer: I see.. [17:36] so when we move to that workspace it will always get focus [17:36] that sound reasonable? [17:36] as...other wise im just imagining a mess of code to handle all strange edge cases [17:39] bschaefer: yes, that seems correct [17:39] so instead of updating the last focused window each time we move workspace [17:40] the details could be hammered out [17:42] bschaefer: are you thinking about caching focused window e.g. in CompWindow::activate? [17:42] dgadomski, not 100% sure where but that might be a good place [17:43] dgadomski, we just need a way to cache a window per workspace [17:43] and when a new window is focused to update that cache array === rickspencer3_ is now known as rickspencer3 [18:05] * didrocks waves good evening and good night === alan_g is now known as alan_g|EOD [18:40] bschaefer: caching in CompWindow::activate does not work as expected, I will continue debugging tomorrow morning [18:41] dgadomski, sounds good, i think the screen will have to know about it [18:41] vs the window [18:41] good luck! [18:42] bschaefer: thanks! take care [18:44] you to!