[03:19] jaytaoko, hey === fenris is now known as Guest55400 === Guest55400 is now known as ejat === FloatingGoat is now known as GoatBlops [08:55] tsdgeos: morning! [08:55] Kaleo: morning [08:56] tsdgeos: 2 MRs for you :) [08:56] Kaleo: yesterdays? you've comments there already [08:56] tsdgeos: cool [08:57] tsdgeos: are you ok today? :) [08:58] Kaleo: yep [08:59] tsdgeos: replied to boh [08:59] tsdgeos: replied to both [09:00] tsdgeos: any luck with the spread? [09:02] not really [09:02] i can see it deadlocking in the dbus level [09:02] not sure why yet [09:02] tsdgeos: oki [09:03] tsdgeos: if we get that done then the last issue is some RTL issues [09:03] like? [09:03] tsdgeos: for the gestures I am a bit blocked since geis is broken in oneiric [09:03] tsdgeos: but I will 'borrow' oSoMoN's laptop :) [09:03] tsdgeos: - RTL when launcher's hide mode is set to 0 is broken [09:03] tsdgeos: I put it in the sketchpad [09:04] there is no test for that [09:04] hence i did not fix it :D [09:05] tsdgeos: lol :) [09:05] tsdgeos: nice thought [09:05] greyback, wake up before call! :) [09:05] mhr3: I've been awake for hours! [09:06] tsdgeos: we especially care because the hide mode is going to be set by default to 0 in precise [09:06] Kaleo: https://code.launchpad.net/~fboucault/unity-2d/fix_dash_width_always_visible_launcher/+merge/91968 <-- new comment [09:07] tsdgeos: you mean in the same qml file? [09:07] Kaleo: yep [09:07] changing them will probably even fix RTL for you [09:07] tsdgeos: yeah, I know [09:07] tsdgeos: but I wanted to focus on one issue at a time [09:07] greyback, oh, so you just came back from party? ;) [09:07] Kaleo: ok [09:08] tsdgeos: and you are the expert on RTL now :) [09:08] Kaleo: can approve it then if you prefer [09:08] tsdgeos: yes [09:08] tsdgeos: one fix at a time :) [09:08] Kaleo: well, to me the fix would be "don't use wrong availableGeometry" ;-) [09:09] but fair enough [09:09] tsdgeos: I think like a user [09:09] tsdgeos: (trying to anyway) [09:09] mhr3: cheeky monkey [09:09] tsdgeos: I'll leave the RTL to you if you don't mind :) [09:09] sure [09:10] tsdgeos: also I think updateShellPosition has a bug regarding RTL [09:10] tsdgeos: meaning, it also plays a part [09:10] Kaleo: why? [09:10] tsdgeos: because in my tests the position of the shell in RTL was incorrect [09:10] JohnLea: ping [09:11] Kaleo: what you mean by "incorrect"? [09:11] tsdgeos: the launcher was not on the far right [09:11] tsdgeos: but shifted on the left by its size [09:11] tsdgeos: that's actually what the bug I wrote is [09:11] Kaleo: that's the x: binding in Shell.qml [09:11] tsdgeos: "broken" [09:11] for the launcherloader [09:11] tsdgeos: but you'll see :) [09:12] tsdgeos: finally, I also made the list of files that need reviewing [09:12] tsdgeos: I have a 3000 lines diff to review [09:12] tsdgeos: that is the biggest chunk of work after these fixes [09:12] tsdgeos: I'll get that done this morning [09:12] tsdgeos: so that in the afternoon we are pretty stable [09:12] Kaleo: great [09:13] tsdgeos: then it's just the last polish.. [09:13] tsdgeos: you don't have a multitouch device right? (macbook, etc.) [09:14] Kaleo: i do have a dell XPS touchpad, supports 2 fingers i think [09:14] no idea how to properly tell [09:14] tsdgeos: not enough for me [09:14] tsdgeos: the gestures I'll reimplement are 3 and 4 fingers [09:15] tsdgeos: I'll get somebody to review [09:28] Kaleo: it is a deadlock for sure see http://paste.kde.org/~tsdgeos/205004/ [09:29] Kaleo: they're both waiting on eachother dbus interfaces to be created [09:29] tsdgeos: oh nasties [09:30] to be honest don't know an easy way to fix that [09:30] other than what i did yesterday [09:30] of not instantiating the dashclient in the spread since we don't really need it [09:30] and thus the deadlock is gone [09:35] Kaleo: ↑ any other idea? [09:36] * tsdgeos has one, tries... [09:37] tsdgeos: I'm trying to think [09:38] * tsdgeos 's idea fails [09:39] of course one solution is moving stuff to a thread [09:39] but that's going to be much more painful than i'd like [09:41] tsdgeos: so, 2 questions [09:41] tsdgeos: why do we block when waiting for the service to come up? [09:41] tsdgeos: why did not we have the same issue before (in trunk)? [09:41] Kaleo: we don't, Qt does [09:42] Kaleo: because in trunk there is no SpreadMonitor (that is the other part of the lock) === dyams is now known as dyams|lunch [09:51] tsdgeos: I'm getting there (thinking about it) [09:54] nerochiaro: you added in r790 two FIXMEs to Launcher.qml and LauncherList.qml do you remember what you meant with them? http://bazaar.launchpad.net/~unity-2d-team/unity-2d/unity-2d-shell/revision/790 [09:55] tsdgeos: lookig [10:00] tsdgeos: ok, I got it [10:01] Kaleo: nice [10:01] what's your suggestion? [10:01] tsdgeos: from my thinking, we register the spread dbus service too early [10:01] tsdgeos: we should do that just before starting the main loop [10:02] tsdgeos: once we are done with everything else (especially loading the QML) [10:02] tsdgeos: would that work? [10:02] might work [10:03] delaying one of them [10:03] to make sure the other is loaded [10:03] can try [10:03] tsdgeos: it's more like, we don't want to register our dbus service if we are not really ready to answer requests [10:03] tsdgeos: hence registering our dbus service should be done as the last possible thing [10:03] tsdgeos: before starting the Ãmain loop [10:04] tsdgeos: if that makes sense [10:04] yeah [10:04] makes sense [10:04] not sure's going to help [10:04] but let's give it a try :) [10:04] i mean should help in theory [10:04] tsdgeos: let's make it practice :) [10:04] i'm on it [10:04] tsdgeos: my looking also uncovered the fact that we are doing IPC with oneself [10:05] tsdgeos: ie. DashClient is instantiated by the shell and connects to the .. shell [10:05] i removed all the places one time [10:05] not sure we added some more [10:05] Kaleo: sure, but we don't use the dashclient ipc calls anywhere (or at some time we didn't) [10:05] tsdgeos: yep [10:05] tsdgeos: that's good :) [10:06] tsdgeos: I guess to be even better we should only connect to the process if it's absolutely required, ie. if one method is called or one property referenced [10:06] tsdgeos: but anyway [10:06] tsdgeos: one thing at a time [10:07] tsdgeos: i think they are all obsolete. the webfavs work and the shortcuts work fine, so i think they can just be removed [10:08] tsdgeos: the FIXMEs i mean [10:08] oki [10:09] Kaleo: seems to work, let me try more times [10:14] tsdgeos: great! [10:18] Kaleo: arg, just realized your strutmanager fix is wrong :-/ [10:18] unity-2d-shell: [WARNING] QDeclarativeExpression: Expression "(function $width() { return declarativeView.screen.availableGeometry.width + (strutManager.enabled ? strutManager.width : 0) })" depends on non-NOTIFYable properties: [10:18] unity-2d-shell: [WARNING] StrutManager::width [10:18] well not wrong [10:18] but WARNING- [10:18] y [10:18] tsdgeos: yeah, I know [10:18] tsdgeos: not related to the fix [10:18] tsdgeos: it's related to StrutManager being poor [10:18] tsdgeos: it basically handles badly dynamic changes [10:18] tsdgeos: it lacks a few changed property signals [10:19] yep [10:19] tsdgeos: and it will only work if the properties are set in a certain order [10:20] we should add a FIXME :D [10:23] Kaleo: about the dbus "deadlock" i have a fix, it works UNLESS you start both unity-2d-shell and unity-2d-launcher at the same time, then the problem still happens sometimes :-/ [10:23] tsdgeos: unity-2d-launcher? [10:23] Kaleo: spread sorry [10:23] if you start shell and spread at the same time, it sometimes still locks [10:23] tsdgeos: the exact same deadlock as before? do you have traces? [10:24] not exact, but similar, let me paste them [10:24] tsdgeos: and if I could see your fix :) [10:25] Kaleo: basically it's what you said [10:25] Kaleo: so the new "lock" is here http://paste.kde.org/~tsdgeos/205034/ both QDBusServiceWatcher see eachother and bam! [10:25] Kaleo: the diff is http://paste.kde.org/~tsdgeos/205040/ [10:26] tsdgeos: cheers [10:30] tsdgeos: ah ah [10:30] tsdgeos: the issue is very different now [10:30] tsdgeos: it's quite nice [10:30] well [10:30] different, but similar [10:30] in which we deadlock on dbus :D [10:31] sure, you have to be "unlucky" now [10:31] in that both services are registerer at the same time [10:31] tsdgeos: btw instatating DashDBus should be done much later too [10:31] Kaleo: the instantiation by itself does nothing [10:32] tsdgeos: I know [10:32] so? [10:32] tsdgeos: but there is no reason to have the instantiation separated away from the connect [10:32] tsdgeos: it's more readable to have them together [10:32] reason is minial diff :D [10:32] tsdgeos: the diff is small enough for me :) [10:33] but that's a technicallity [10:33] tsdgeos: I'm still thinking about the solution to that lock btw :) [10:33] won't fix the problem [10:33] tsdgeos: absolutelty [10:33] there is something fishy [10:35] tsdgeos: if you are out of ideas, I have a couple of things for you while I think about it [10:35] tsdgeos: http://pastebin.com/eMaLs5rH [10:35] tsdgeos: if you could verify these things are done [10:36] tsdgeos: to be able to test you can use the patch you proposed yesterday [10:36] tsdgeos: that avoids the deadlock [10:37] Kaleo: yeah, just spoke with the QtDBus maintainer and his answer is: "there are two solutions possible then: 1) threads 2) fix QtDBus so it makes asynchronous calls for getting the introspection" :/ [10:38] * tsdgeos is getting cold, turn on the heater [10:38] tsdgeos: tiago you mean? [10:39] Kaleo: yep (thiago actually) [10:39] tsdgeos: sorry :) [10:39] tsdgeos: ok [10:39] tsdgeos: it does indeed sound like a generic issues [10:39] tsdgeos: other qt programs may have [10:39] -s [10:40] tsdgeos: can we do the following: [10:40] tsdgeos: 1) combine the patch from yesterday where we don't have DashClient in the QML plugin with the patch from today (delaying the registration is sane) [10:41] tsdgeos: 2) add a WARNING/FIXME explaining the situation with potentially a link to some Qt bug (if any) [10:41] tsdgeos: unless of course there is a trivial way to thread that QDBusInterface creation business [10:43] i don't think there is [10:44] tsdgeos: ok [10:44] Kaleo: sure we can do that, where would you write the WARNING, can't think of "the place" it belongs [10:44] tsdgeos: hmmm, in shell.cpp next to instantiating DashClient [10:44] tsdgeos: that way people who wonder why it's not in the plugin will get it [10:44] Kaleo: ok [10:45] let's go with that for the moment then [10:46] tsdgeos: I'd like to commit these 2 things: http://pastebin.com/bq4tmuCv [10:46] tsdgeos: can I? [10:46] hi, when I try building unity I get [10:46] CMake Error at /usr/share/cmake-2.8/Modules/FindCompiz.cmake:58 (string): [10:46] string sub-command REGEX, mode REPLACE needs at least 6 arguments total to [10:46] command. [10:46] Call Stack (most recent call first): [10:46] plugins/unityshell/CMakeLists.txt:1 (find_package) [10:46] anyone knows what I'm doing wrong? [10:47] Kaleo: yes, approved [10:48] tsdgeos: cheers === dyams|lunch is now known as dyams [10:56] tsdgeos: https://code.launchpad.net/~fboucault/unity-2d/shell_dead_code/+merge/92007 [10:59] Kaleo: that was inherited from tv? [11:03] tsdgeos: hmmm, I don't know, don't think so [11:04] Kaleo: ok, anyway, yeah the call is broken [11:04] and it works [11:04] thus we don't need it :D [11:05] tsdgeos: :) [11:05] tsdgeos: and that method does not exist :) [11:05] right [11:05] yeah that's it :D [11:11] Kaleo: https://code.launchpad.net/~aacid/unity-2d/unity-2d-shell_dashclient_to_shell/+merge/92011 [11:11] tsdgeos: gerat! [11:13] Kaleo: the issued you mentioned in the pastebin can no longer reproduced here once i have that patch [11:13] tsdgeos: works great, approved! [11:14] tsdgeos: all of them? :) [11:14] yeah [11:14] tsdgeos: great! [11:14] though i found a new problem [11:14] ahah [11:14] i can have the dash showing and the launcher hidden when the spread comes into play [11:14] don't have the proper combination to reproduce yet [11:17] arrgg, can't repro it anymore [11:17] tsdgeos: erk [11:17] ahah [11:17] got it [11:18] Super+S, Super, Esc [11:20] Kaleo: i'm guessing we should make the "Super" in ↑ this sequence do nothing? [11:20] tsdgeos: inhibit super when spread is shown [11:20] tsdgeos: indeed [11:34] Kaleo: https://code.launchpad.net/~aacid/unity-2d/unity-2d-shell_ignore_super_on_spread/+merge/92013 read my comment [11:41] tsdgeos: reading === _salem is now known as salem_ [11:47] Kaleo: also got https://code.launchpad.net/~aacid/unity-2d/unity-2d-shell_rtl_fixed_launcher/+merge/92015 [11:47] tsdgeos: nice [11:47] tsdgeos: I guess you saw all the nice items I added to the sketchpad [11:48] Kaleo: yep, take them in order? [11:49] tsdgeos: yep [12:09] tsdgeos: can we mumble that one? [12:10] Kaleo: sure [12:11] tsdgeos: darn, mike borked [12:11] I'll reboot [12:11] :-/ [12:11] oki [12:11] tsdgeos: good news is that I finished reviewing [12:12] tsdgeos: all the issues are now listed [12:12] great [12:12] tsdgeos: once this is done, we are .. done [12:12] tsdgeos: actually, I'm going to go to the office [12:12] tsdgeos: please move on to other items [12:12] Kaleo: ok [12:13] tsdgeos: we can discuss the strutmanager later [12:13] sure [12:13] tsdgeos: thanks [12:32] Hm.. is the new default for the launcher to never hide? [12:34] yes === MacSlow is now known as MacSlow|lunch [13:20] can anyone help me with building unity? [13:21] sbte, hi, http://askubuntu.com/questions/28470/how-do-i-build-unity-from-source/28472#28472 [13:21] seb128, I did all that but get CMake Error at /usr/share/cmake-2.8/Modules/FindCompiz.cmake:58 (string): [13:22] string sub-command REGEX, mode REPLACE needs at least 6 arguments total to [13:22] command. [13:22] Call Stack (most recent call first): [13:22] plugins/unity-mt-grab-handles/CMakeLists.txt:1 (find_package) [13:22] I also enabled the staging ppa [13:22] hum, dunno about that one ;-) [13:50] mhall119: hey, are you around? [13:50] didrocks: I sure am [13:50] mhall119: so, I have some time to help you on the singlet and quickly integration [13:51] \o/ [13:51] mhall119: did you get any help already on that? I saw you blog post about it [13:51] didrocks: not with quickly, kenvandine helped me get singlet packaged and ready for Universe though [13:51] is it in? [13:51] source package was uploaded by ken [13:52] ok, let me have a look if it has been NEWed [13:52] doesn't appear that the binary packages have made it in yet though [13:54] ok, looking [13:55] ok, the package name is unity-singlet [13:55] the source package is [13:56] the binary is python-unity-singlet [13:59] mhall119: hum, you don't depend on the unity gir file? [14:00] the priority is extra and not optional [14:01] the compat mode is 6, this one is quite depreacated and not advised (should be either 5 or 7, I would suggest 7 as you build-dep on debhelper 7) [14:01] tsdgeos: I must be blind; I cannot figure where the env is set to RTL in launcher/autohide_show_tests_rtl.rb [14:01] Kaleo: there is not env var [14:01] didrocks: what is the unity gir package name? [14:02] Kaleo: -reverse switch to the command line [14:02] mhall119: gir1.2-unity-5.0 [14:03] didrocks: what's the difference between extra and optional? [14:03] tsdgeos: oh, ok [14:03] I honestly don't know what the priority field is used for [14:03] tsdgeos: how do you do it for your tests? [14:03] Kaleo: same, with -reverse [14:03] tsdgeos: amazing :) [14:04] mhall119: it's bumping the build priority (not very important on launchpad but let's try to have packaging following the debian policy) [14:04] Kaleo: any Qt app supports -reverse, it's very handy [14:04] also, some nitpicking: there are 2 spaces in the package description after each . [14:04] and debian/copyright: you need for the new format to copy the licence header [14:04] instead of refering to "you can find the licence…" [14:05] apart from that, the package looks fine [14:05] mhall119: I'm rejecting the current package for now === MacSlow|lunch is now known as MacSlow [14:08] didrocks: where do I get the 'license header' you want in the copyright file? [14:09] Kaleo: about "AbstractDBusServiceMonitor should not have an 'enabled' property; instead a 'serviceState' property should be defined", enabled in that class does nto represent the serviceState, you aware of that? [14:10] didrocks: http://paste.ubuntu.com/833922/ does that look right to you? [14:10] mhall119: unity-lens-music has it if you need [14:10] * didrocks looks [14:11] mhall119: looks good to me [14:11] mhall119: oh wait [14:11] remove [14:11] "You should have received…" stenza [14:11] as it's not the case for a binary package [14:12] ok [14:12] I just copied from http://dep.debian.net/deps/dep5/#examples [14:13] hum, that should be reviewed, as this stenza is clearly unecessary and wrong :) (and we remove it from most of our packages) [14:13] mhall119: as long as being nitpicky, you didn't remove the 2 spaces between sentences in the description [14:13] (at least you did it twice) [14:14] I still hold to old-school typing standards === dyams is now known as dyams|eod [14:14] and I use the Oxford comma [14:15] hum not really relevant to a French guy TBH :) [14:15] but if it's syntaxically correct, ok :) [14:15] it's the way I was taught to type, on an actual type-writer [14:16] it's ingrained in my psyche now [14:16] didrocks: ok, all your changes are made in my packaging branch [14:17] lp:~mhall119/singlet/precise-package [14:17] mhall119: sweet, looking :) [14:20] tsdgeos: yeah I am well aware of that [14:20] tsdgeos: it's really 2 separate tasks [14:21] Kaleo: so you want it to always be enabled and then to inform of the service state? [14:21] tsdgeos: but to remove the enabled property you will have to think of a proper way [14:21] tsdgeos: that's right [14:21] tsdgeos: unless you see a real use for having it not enabled [14:21] tsdgeos: in which case I don't mind keeping it [14:21] Kaleo: not really, but it's not me that did that class :D [14:21] tsdgeos: :) [14:22] tsdgeos: I know [14:22] tsdgeos: I am slapping that person right now :) [14:22] i mean, the amount of thought i've put there is not the same someone else did so might have more insight [14:22] mhall119: waiting for the scheduler to make the source package appears :) [14:24] tsdgeos: yep, checking with nerochiaro now [14:25] Kaleo: can i cleanup the "DONE" tasks from the sketchpad? [14:26] mhall119: ok, I sponsored and accepted in universe. Will accept the binary once built. [14:26] tsdgeos: yep [14:26] mhall119: no, time for getting a look at the quickly side? [14:26] now* [14:29] didrocks: yes please [14:30] tsdgeos: it's getting smaller :) [14:30] mhall119: ok, I think we should decide first if we generate the .lens (and .scope) file or use static files [14:30] tsdgeos: https://code.launchpad.net/~aacid/unity-2d/unity-2d-shell_rtl_fixed_launcher/+merge/92015 approve [14:30] d [14:30] mhall119: I have no strong opinion at all, I like the django approach [14:30] tsdgeos: I'm concerned about https://code.launchpad.net/~aacid/unity-2d/unity-2d-shell_ignore_super_on_spread/+merge/92013 [14:31] tsdgeos: I am looking for having it done only in QML [14:31] Kaleo: everything? [14:31] mhall119: what's your pick? (knowing that we won't have "quickly run" as there is a need to the service to be installed on the system to be testable, unfortunatly) [14:32] mhall119: singlet built and binNEWed btw :) [14:32] Kaleo: doing it in QML seems a too big of a chance to do it "at this stage" for not "real gain" i think [14:34] didrocks: thanks! [14:34] tsdgeos: you think too late for now? [14:34] I like generating .lens and .service files, since it means the user only edits the lens source [14:34] yw :) [14:34] tsdgeos: I'll give a bit more thought then [14:34] mhall119: ok, and we really on one source file by default? [14:35] rely* [14:35] only need one [14:35] ok, let's have a look then :) [14:35] but we should be able to handle having more than one [14:35] do you have a binary file snippet? (the one you removed from singlet) [14:36] and do you have quickly installed? :) [14:36] no, I never ended up making a binary for singlet [14:36] Kaleo: nerochiaro: so kill the setEnabled in abstractdbusservicemonitor? [14:36] yes I have quickly [14:36] tsdgeos: yep [14:36] mhall119: you had an example lens, isn't it? (we should base on that) [14:36] tsdgeos: nerochiaro just finished thiking about it [14:37] tsdgeos: and says: 'be careful' ): [14:37] :) [14:37] oki [14:37] and some helper scripts IIRC [14:37] didrocks: I had a test lens [14:37] and a couple that I wrote separate from, but using, singlet [14:37] ok, let's start from one [14:38] and try to turn that into a boiler plate [14:38] the helper scripts are what generate the .lens and .service files, and also what run the lens daemon [14:38] yeah, and we will move them as quickly commands [14:38] ok, test/singlescope should do then [14:39] lp:singlet ? [14:39] yes [14:39] how do you want to tackle it? Do you want to do it and me giving guidance, or do you want that I handle it? :) [14:40] well first I have a question [14:40] tsdgeos: https://code.launchpad.net/~aacid/unity-2d/unity-2d-shell_inputshaperectangle_improvements/+merge/92031 approved [14:40] developers aren't going to want to make a "singlet project" [14:41] they're going to want to make a "single scope lens" or a "generic lens" or a "scope" [14:41] all of which base off different Singlet classes [14:41] indeeed [14:41]