| bschaefer | jaytaoko, hey | 03:19 |
|---|---|---|
| === fenris is now known as Guest55400 | ||
| === Guest55400 is now known as ejat | ||
| === FloatingGoat is now known as GoatBlops | ||
| Kaleo | tsdgeos: morning! | 08:55 |
| tsdgeos | Kaleo: morning | 08:55 |
| Kaleo | tsdgeos: 2 MRs for you :) | 08:56 |
| tsdgeos | Kaleo: yesterdays? you've comments there already | 08:56 |
| Kaleo | tsdgeos: cool | 08:56 |
| Kaleo | tsdgeos: are you ok today? :) | 08:57 |
| tsdgeos | Kaleo: yep | 08:58 |
| Kaleo | tsdgeos: replied to boh | 08:59 |
| Kaleo | tsdgeos: replied to both | 08:59 |
| Kaleo | tsdgeos: any luck with the spread? | 09:00 |
| tsdgeos | not really | 09:02 |
| tsdgeos | i can see it deadlocking in the dbus level | 09:02 |
| tsdgeos | not sure why yet | 09:02 |
| Kaleo | tsdgeos: oki | 09:02 |
| Kaleo | tsdgeos: if we get that done then the last issue is some RTL issues | 09:03 |
| tsdgeos | like? | 09:03 |
| Kaleo | tsdgeos: for the gestures I am a bit blocked since geis is broken in oneiric | 09:03 |
| Kaleo | tsdgeos: but I will 'borrow' oSoMoN's laptop :) | 09:03 |
| Kaleo | tsdgeos: - RTL when launcher's hide mode is set to 0 is broken | 09:03 |
| Kaleo | tsdgeos: I put it in the sketchpad | 09:03 |
| tsdgeos | there is no test for that | 09:04 |
| tsdgeos | hence i did not fix it :D | 09:04 |
| Kaleo | tsdgeos: lol :) | 09:05 |
| Kaleo | tsdgeos: nice thought | 09:05 |
| mhr3 | greyback, wake up before call! :) | 09:05 |
| greyback | mhr3: I've been awake for hours! | 09:05 |
| Kaleo | tsdgeos: we especially care because the hide mode is going to be set by default to 0 in precise | 09:06 |
| tsdgeos | Kaleo: https://code.launchpad.net/~fboucault/unity-2d/fix_dash_width_always_visible_launcher/+merge/91968 <-- new comment | 09:06 |
| Kaleo | tsdgeos: you mean in the same qml file? | 09:07 |
| tsdgeos | Kaleo: yep | 09:07 |
| tsdgeos | changing them will probably even fix RTL for you | 09:07 |
| Kaleo | tsdgeos: yeah, I know | 09:07 |
| Kaleo | tsdgeos: but I wanted to focus on one issue at a time | 09:07 |
| mhr3 | greyback, oh, so you just came back from party? ;) | 09:07 |
| tsdgeos | Kaleo: ok | 09:07 |
| Kaleo | tsdgeos: and you are the expert on RTL now :) | 09:08 |
| tsdgeos | Kaleo: can approve it then if you prefer | 09:08 |
| Kaleo | tsdgeos: yes | 09:08 |
| Kaleo | tsdgeos: one fix at a time :) | 09:08 |
| tsdgeos | Kaleo: well, to me the fix would be "don't use wrong availableGeometry" ;-) | 09:08 |
| tsdgeos | but fair enough | 09:09 |
| Kaleo | tsdgeos: I think like a user | 09:09 |
| Kaleo | tsdgeos: (trying to anyway) | 09:09 |
| greyback | mhr3: cheeky monkey | 09:09 |
| Kaleo | tsdgeos: I'll leave the RTL to you if you don't mind :) | 09:09 |
| tsdgeos | sure | 09:09 |
| Kaleo | tsdgeos: also I think updateShellPosition has a bug regarding RTL | 09:10 |
| Kaleo | tsdgeos: meaning, it also plays a part | 09:10 |
| tsdgeos | Kaleo: why? | 09:10 |
| Kaleo | tsdgeos: because in my tests the position of the shell in RTL was incorrect | 09:10 |
| dyams | JohnLea: ping | 09:10 |
| tsdgeos | Kaleo: what you mean by "incorrect"? | 09:11 |
| Kaleo | tsdgeos: the launcher was not on the far right | 09:11 |
| Kaleo | tsdgeos: but shifted on the left by its size | 09:11 |
| Kaleo | tsdgeos: that's actually what the bug I wrote is | 09:11 |
| tsdgeos | Kaleo: that's the x: binding in Shell.qml | 09:11 |
| Kaleo | tsdgeos: "broken" | 09:11 |
| tsdgeos | for the launcherloader | 09:11 |
| Kaleo | tsdgeos: but you'll see :) | 09:11 |
| Kaleo | tsdgeos: finally, I also made the list of files that need reviewing | 09:12 |
| Kaleo | tsdgeos: I have a 3000 lines diff to review | 09:12 |
| Kaleo | tsdgeos: that is the biggest chunk of work after these fixes | 09:12 |
| Kaleo | tsdgeos: I'll get that done this morning | 09:12 |
| Kaleo | tsdgeos: so that in the afternoon we are pretty stable | 09:12 |
| tsdgeos | Kaleo: great | 09:12 |
| Kaleo | tsdgeos: then it's just the last polish.. | 09:13 |
| Kaleo | tsdgeos: you don't have a multitouch device right? (macbook, etc.) | 09:13 |
| tsdgeos | Kaleo: i do have a dell XPS touchpad, supports 2 fingers i think | 09:14 |
| tsdgeos | no idea how to properly tell | 09:14 |
| Kaleo | tsdgeos: not enough for me | 09:14 |
| Kaleo | tsdgeos: the gestures I'll reimplement are 3 and 4 fingers | 09:14 |
| Kaleo | tsdgeos: I'll get somebody to review | 09:15 |
| tsdgeos | Kaleo: it is a deadlock for sure see http://paste.kde.org/~tsdgeos/205004/ | 09:28 |
| tsdgeos | Kaleo: they're both waiting on eachother dbus interfaces to be created | 09:29 |
| Kaleo | tsdgeos: oh nasties | 09:29 |
| tsdgeos | to be honest don't know an easy way to fix that | 09:30 |
| tsdgeos | other than what i did yesterday | 09:30 |
| tsdgeos | of not instantiating the dashclient in the spread since we don't really need it | 09:30 |
| tsdgeos | and thus the deadlock is gone | 09:30 |
| tsdgeos | Kaleo: ↑ any other idea? | 09:35 |
| * tsdgeos has one, tries... | 09:36 | |
| Kaleo | tsdgeos: I'm trying to think | 09:37 |
| * tsdgeos 's idea fails | 09:38 | |
| tsdgeos | of course one solution is moving stuff to a thread | 09:39 |
| tsdgeos | but that's going to be much more painful than i'd like | 09:39 |
| Kaleo | tsdgeos: so, 2 questions | 09:41 |
| Kaleo | tsdgeos: why do we block when waiting for the service to come up? | 09:41 |
| Kaleo | tsdgeos: why did not we have the same issue before (in trunk)? | 09:41 |
| tsdgeos | Kaleo: we don't, Qt does | 09:41 |
| tsdgeos | Kaleo: because in trunk there is no SpreadMonitor (that is the other part of the lock) | 09:42 |
| === dyams is now known as dyams|lunch | ||
| Kaleo | tsdgeos: I'm getting there (thinking about it) | 09:51 |
| tsdgeos | 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:54 |
| nerochiaro | tsdgeos: lookig | 09:55 |
| Kaleo | tsdgeos: ok, I got it | 10:00 |
| tsdgeos | Kaleo: nice | 10:01 |
| tsdgeos | what's your suggestion? | 10:01 |
| Kaleo | tsdgeos: from my thinking, we register the spread dbus service too early | 10:01 |
| Kaleo | tsdgeos: we should do that just before starting the main loop | 10:01 |
| Kaleo | tsdgeos: once we are done with everything else (especially loading the QML) | 10:02 |
| Kaleo | tsdgeos: would that work? | 10:02 |
| tsdgeos | might work | 10:02 |
| tsdgeos | delaying one of them | 10:03 |
| tsdgeos | to make sure the other is loaded | 10:03 |
| tsdgeos | can try | 10:03 |
| Kaleo | 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 |
| Kaleo | tsdgeos: hence registering our dbus service should be done as the last possible thing | 10:03 |
| Kaleo | tsdgeos: before starting the Ãmain loop | 10:03 |
| Kaleo | tsdgeos: if that makes sense | 10:04 |
| tsdgeos | yeah | 10:04 |
| tsdgeos | makes sense | 10:04 |
| tsdgeos | not sure's going to help | 10:04 |
| tsdgeos | but let's give it a try :) | 10:04 |
| tsdgeos | i mean should help in theory | 10:04 |
| Kaleo | tsdgeos: let's make it practice :) | 10:04 |
| tsdgeos | i'm on it | 10:04 |
| Kaleo | tsdgeos: my looking also uncovered the fact that we are doing IPC with oneself | 10:04 |
| Kaleo | tsdgeos: ie. DashClient is instantiated by the shell and connects to the .. shell | 10:05 |
| tsdgeos | i removed all the places one time | 10:05 |
| tsdgeos | not sure we added some more | 10:05 |
| tsdgeos | Kaleo: sure, but we don't use the dashclient ipc calls anywhere (or at some time we didn't) | 10:05 |
| Kaleo | tsdgeos: yep | 10:05 |
| Kaleo | tsdgeos: that's good :) | 10:05 |
| Kaleo | 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 |
| Kaleo | tsdgeos: but anyway | 10:06 |
| Kaleo | tsdgeos: one thing at a time | 10:06 |
| nerochiaro | tsdgeos: i think they are all obsolete. the webfavs work and the shortcuts work fine, so i think they can just be removed | 10:07 |
| nerochiaro | tsdgeos: the FIXMEs i mean | 10:08 |
| tsdgeos | oki | 10:08 |
| tsdgeos | Kaleo: seems to work, let me try more times | 10:09 |
| Kaleo | tsdgeos: great! | 10:14 |
| tsdgeos | Kaleo: arg, just realized your strutmanager fix is wrong :-/ | 10:18 |
| tsdgeos | 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 |
| tsdgeos | unity-2d-shell: [WARNING] StrutManager::width | 10:18 |
| tsdgeos | well not wrong | 10:18 |
| tsdgeos | but WARNING- | 10:18 |
| tsdgeos | y | 10:18 |
| Kaleo | tsdgeos: yeah, I know | 10:18 |
| Kaleo | tsdgeos: not related to the fix | 10:18 |
| Kaleo | tsdgeos: it's related to StrutManager being poor | 10:18 |
| Kaleo | tsdgeos: it basically handles badly dynamic changes | 10:18 |
| Kaleo | tsdgeos: it lacks a few changed property signals | 10:18 |
| tsdgeos | yep | 10:19 |
| Kaleo | tsdgeos: and it will only work if the properties are set in a certain order | 10:19 |
| tsdgeos | we should add a FIXME :D | 10:20 |
| tsdgeos | 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 |
| Kaleo | tsdgeos: unity-2d-launcher? | 10:23 |
| tsdgeos | Kaleo: spread sorry | 10:23 |
| tsdgeos | if you start shell and spread at the same time, it sometimes still locks | 10:23 |
| Kaleo | tsdgeos: the exact same deadlock as before? do you have traces? | 10:23 |
| tsdgeos | not exact, but similar, let me paste them | 10:24 |
| Kaleo | tsdgeos: and if I could see your fix :) | 10:24 |
| tsdgeos | Kaleo: basically it's what you said | 10:25 |
| tsdgeos | Kaleo: so the new "lock" is here http://paste.kde.org/~tsdgeos/205034/ both QDBusServiceWatcher see eachother and bam! | 10:25 |
| tsdgeos | Kaleo: the diff is http://paste.kde.org/~tsdgeos/205040/ | 10:25 |
| Kaleo | tsdgeos: cheers | 10:26 |
| Kaleo | tsdgeos: ah ah | 10:30 |
| Kaleo | tsdgeos: the issue is very different now | 10:30 |
| Kaleo | tsdgeos: it's quite nice | 10:30 |
| tsdgeos | well | 10:30 |
| tsdgeos | different, but similar | 10:30 |
| tsdgeos | in which we deadlock on dbus :D | 10:30 |
| tsdgeos | sure, you have to be "unlucky" now | 10:31 |
| tsdgeos | in that both services are registerer at the same time | 10:31 |
| Kaleo | tsdgeos: btw instatating DashDBus should be done much later too | 10:31 |
| tsdgeos | Kaleo: the instantiation by itself does nothing | 10:31 |
| Kaleo | tsdgeos: I know | 10:32 |
| tsdgeos | so? | 10:32 |
| Kaleo | tsdgeos: but there is no reason to have the instantiation separated away from the connect | 10:32 |
| Kaleo | tsdgeos: it's more readable to have them together | 10:32 |
| tsdgeos | reason is minial diff :D | 10:32 |
| Kaleo | tsdgeos: the diff is small enough for me :) | 10:32 |
| tsdgeos | but that's a technicallity | 10:33 |
| Kaleo | tsdgeos: I'm still thinking about the solution to that lock btw :) | 10:33 |
| tsdgeos | won't fix the problem | 10:33 |
| Kaleo | tsdgeos: absolutelty | 10:33 |
| Kaleo | there is something fishy | 10:33 |
| Kaleo | tsdgeos: if you are out of ideas, I have a couple of things for you while I think about it | 10:35 |
| Kaleo | tsdgeos: http://pastebin.com/eMaLs5rH | 10:35 |
| Kaleo | tsdgeos: if you could verify these things are done | 10:35 |
| Kaleo | tsdgeos: to be able to test you can use the patch you proposed yesterday | 10:36 |
| Kaleo | tsdgeos: that avoids the deadlock | 10:36 |
| tsdgeos | 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:37 |
| * tsdgeos is getting cold, turn on the heater | 10:38 | |
| Kaleo | tsdgeos: tiago you mean? | 10:38 |
| tsdgeos | Kaleo: yep (thiago actually) | 10:39 |
| Kaleo | tsdgeos: sorry :) | 10:39 |
| Kaleo | tsdgeos: ok | 10:39 |
| Kaleo | tsdgeos: it does indeed sound like a generic issues | 10:39 |
| Kaleo | tsdgeos: other qt programs may have | 10:39 |
| Kaleo | -s | 10:39 |
| Kaleo | tsdgeos: can we do the following: | 10:40 |
| Kaleo | 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:40 |
| Kaleo | tsdgeos: 2) add a WARNING/FIXME explaining the situation with potentially a link to some Qt bug (if any) | 10:41 |
| Kaleo | tsdgeos: unless of course there is a trivial way to thread that QDBusInterface creation business | 10:41 |
| tsdgeos | i don't think there is | 10:43 |
| Kaleo | tsdgeos: ok | 10:44 |
| tsdgeos | Kaleo: sure we can do that, where would you write the WARNING, can't think of "the place" it belongs | 10:44 |
| Kaleo | tsdgeos: hmmm, in shell.cpp next to instantiating DashClient | 10:44 |
| Kaleo | tsdgeos: that way people who wonder why it's not in the plugin will get it | 10:44 |
| tsdgeos | Kaleo: ok | 10:44 |
| tsdgeos | let's go with that for the moment then | 10:45 |
| Kaleo | tsdgeos: I'd like to commit these 2 things: http://pastebin.com/bq4tmuCv | 10:46 |
| Kaleo | tsdgeos: can I? | 10:46 |
| sbte | hi, when I try building unity I get | 10:46 |
| sbte | CMake Error at /usr/share/cmake-2.8/Modules/FindCompiz.cmake:58 (string): | 10:46 |
| sbte | string sub-command REGEX, mode REPLACE needs at least 6 arguments total to | 10:46 |
| sbte | command. | 10:46 |
| sbte | Call Stack (most recent call first): | 10:46 |
| sbte | plugins/unityshell/CMakeLists.txt:1 (find_package) | 10:46 |
| sbte | anyone knows what I'm doing wrong? | 10:46 |
| tsdgeos | Kaleo: yes, approved | 10:47 |
| Kaleo | tsdgeos: cheers | 10:48 |
| === dyams|lunch is now known as dyams | ||
| Kaleo | tsdgeos: https://code.launchpad.net/~fboucault/unity-2d/shell_dead_code/+merge/92007 | 10:56 |
| tsdgeos | Kaleo: that was inherited from tv? | 10:59 |
| Kaleo | tsdgeos: hmmm, I don't know, don't think so | 11:03 |
| tsdgeos | Kaleo: ok, anyway, yeah the call is broken | 11:04 |
| tsdgeos | and it works | 11:04 |
| tsdgeos | thus we don't need it :D | 11:04 |
| Kaleo | tsdgeos: :) | 11:05 |
| Kaleo | tsdgeos: and that method does not exist :) | 11:05 |
| Kaleo | right | 11:05 |
| tsdgeos | yeah that's it :D | 11:05 |
| tsdgeos | Kaleo: https://code.launchpad.net/~aacid/unity-2d/unity-2d-shell_dashclient_to_shell/+merge/92011 | 11:11 |
| Kaleo | tsdgeos: gerat! | 11:11 |
| tsdgeos | Kaleo: the issued you mentioned in the pastebin can no longer reproduced here once i have that patch | 11:13 |
| Kaleo | tsdgeos: works great, approved! | 11:13 |
| Kaleo | tsdgeos: all of them? :) | 11:14 |
| tsdgeos | yeah | 11:14 |
| Kaleo | tsdgeos: great! | 11:14 |
| tsdgeos | though i found a new problem | 11:14 |
| Kaleo | ahah | 11:14 |
| tsdgeos | i can have the dash showing and the launcher hidden when the spread comes into play | 11:14 |
| tsdgeos | don't have the proper combination to reproduce yet | 11:14 |
| tsdgeos | arrgg, can't repro it anymore | 11:17 |
| Kaleo | tsdgeos: erk | 11:17 |
| tsdgeos | ahah | 11:17 |
| tsdgeos | got it | 11:17 |
| tsdgeos | Super+S, Super, Esc | 11:18 |
| tsdgeos | Kaleo: i'm guessing we should make the "Super" in ↑ this sequence do nothing? | 11:20 |
| Kaleo | tsdgeos: inhibit super when spread is shown | 11:20 |
| Kaleo | tsdgeos: indeed | 11:20 |
| tsdgeos | Kaleo: https://code.launchpad.net/~aacid/unity-2d/unity-2d-shell_ignore_super_on_spread/+merge/92013 read my comment | 11:34 |
| Kaleo | tsdgeos: reading | 11:41 |
| === _salem is now known as salem_ | ||
| tsdgeos | Kaleo: also got https://code.launchpad.net/~aacid/unity-2d/unity-2d-shell_rtl_fixed_launcher/+merge/92015 | 11:47 |
| Kaleo | tsdgeos: nice | 11:47 |
| Kaleo | tsdgeos: I guess you saw all the nice items I added to the sketchpad | 11:47 |
| tsdgeos | Kaleo: yep, take them in order? | 11:48 |
| Kaleo | tsdgeos: yep | 11:49 |
| Kaleo | tsdgeos: can we mumble that one? | 12:09 |
| tsdgeos | Kaleo: sure | 12:10 |
| Kaleo | tsdgeos: darn, mike borked | 12:11 |
| Kaleo | I'll reboot | 12:11 |
| tsdgeos | :-/ | 12:11 |
| tsdgeos | oki | 12:11 |
| Kaleo | tsdgeos: good news is that I finished reviewing | 12:11 |
| Kaleo | tsdgeos: all the issues are now listed | 12:12 |
| tsdgeos | great | 12:12 |
| Kaleo | tsdgeos: once this is done, we are .. done | 12:12 |
| Kaleo | tsdgeos: actually, I'm going to go to the office | 12:12 |
| Kaleo | tsdgeos: please move on to other items | 12:12 |
| tsdgeos | Kaleo: ok | 12:12 |
| Kaleo | tsdgeos: we can discuss the strutmanager later | 12:13 |
| tsdgeos | sure | 12:13 |
| Kaleo | tsdgeos: thanks | 12:13 |
| Daekdroom | Hm.. is the new default for the launcher to never hide? | 12:32 |
| tsdgeos | yes | 12:34 |
| === MacSlow is now known as MacSlow|lunch | ||
| sbte | can anyone help me with building unity? | 13:20 |
| seb128 | sbte, hi, http://askubuntu.com/questions/28470/how-do-i-build-unity-from-source/28472#28472 | 13:21 |
| sbte | seb128, I did all that but get CMake Error at /usr/share/cmake-2.8/Modules/FindCompiz.cmake:58 (string): | 13:21 |
| sbte | string sub-command REGEX, mode REPLACE needs at least 6 arguments total to | 13:22 |
| sbte | command. | 13:22 |
| sbte | Call Stack (most recent call first): | 13:22 |
| sbte | plugins/unity-mt-grab-handles/CMakeLists.txt:1 (find_package) | 13:22 |
| sbte | I also enabled the staging ppa | 13:22 |
| seb128 | hum, dunno about that one ;-) | 13:22 |
| didrocks | mhall119: hey, are you around? | 13:50 |
| mhall119 | didrocks: I sure am | 13:50 |
| didrocks | mhall119: so, I have some time to help you on the singlet and quickly integration | 13:50 |
| mhall119 | \o/ | 13:51 |
| didrocks | mhall119: did you get any help already on that? I saw you blog post about it | 13:51 |
| mhall119 | didrocks: not with quickly, kenvandine helped me get singlet packaged and ready for Universe though | 13:51 |
| didrocks | is it in? | 13:51 |
| mhall119 | source package was uploaded by ken | 13:51 |
| didrocks | ok, let me have a look if it has been NEWed | 13:52 |
| mhall119 | doesn't appear that the binary packages have made it in yet though | 13:52 |
| didrocks | ok, looking | 13:54 |
| didrocks | ok, the package name is unity-singlet | 13:55 |
| mhall119 | the source package is | 13:55 |
| mhall119 | the binary is python-unity-singlet | 13:56 |
| didrocks | mhall119: hum, you don't depend on the unity gir file? | 13:59 |
| didrocks | the priority is extra and not optional | 14:00 |
| didrocks | 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 |
| Kaleo | tsdgeos: I must be blind; I cannot figure where the env is set to RTL in launcher/autohide_show_tests_rtl.rb | 14:01 |
| tsdgeos | Kaleo: there is not env var | 14:01 |
| mhall119 | didrocks: what is the unity gir package name? | 14:01 |
| tsdgeos | Kaleo: -reverse switch to the command line | 14:02 |
| didrocks | mhall119: gir1.2-unity-5.0 | 14:02 |
| mhall119 | didrocks: what's the difference between extra and optional? | 14:03 |
| Kaleo | tsdgeos: oh, ok | 14:03 |
| mhall119 | I honestly don't know what the priority field is used for | 14:03 |
| Kaleo | tsdgeos: how do you do it for your tests? | 14:03 |
| tsdgeos | Kaleo: same, with -reverse | 14:03 |
| Kaleo | tsdgeos: amazing :) | 14:03 |
| didrocks | 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 |
| tsdgeos | Kaleo: any Qt app supports -reverse, it's very handy | 14:04 |
| didrocks | also, some nitpicking: there are 2 spaces in the package description after each . | 14:04 |
| didrocks | and debian/copyright: you need for the new format to copy the licence header | 14:04 |
| didrocks | instead of refering to "you can find the licence…" | 14:04 |
| didrocks | apart from that, the package looks fine | 14:05 |
| didrocks | mhall119: I'm rejecting the current package for now | 14:05 |
| === MacSlow|lunch is now known as MacSlow | ||
| mhall119 | didrocks: where do I get the 'license header' you want in the copyright file? | 14:08 |
| tsdgeos | 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:09 |
| mhall119 | didrocks: http://paste.ubuntu.com/833922/ does that look right to you? | 14:10 |
| didrocks | mhall119: unity-lens-music has it if you need | 14:10 |
| * didrocks looks | 14:10 | |
| didrocks | mhall119: looks good to me | 14:11 |
| didrocks | mhall119: oh wait | 14:11 |
| didrocks | remove | 14:11 |
| didrocks | "You should have received…" stenza | 14:11 |
| didrocks | as it's not the case for a binary package | 14:11 |
| mhall119 | ok | 14:12 |
| mhall119 | I just copied from http://dep.debian.net/deps/dep5/#examples | 14:12 |
| didrocks | hum, that should be reviewed, as this stenza is clearly unecessary and wrong :) (and we remove it from most of our packages) | 14:13 |
| didrocks | mhall119: as long as being nitpicky, you didn't remove the 2 spaces between sentences in the description | 14:13 |
| didrocks | (at least you did it twice) | 14:13 |
| mhall119 | I still hold to old-school typing standards | 14:14 |
| === dyams is now known as dyams|eod | ||
| mhall119 | and I use the Oxford comma | 14:14 |
| didrocks | hum not really relevant to a French guy TBH :) | 14:15 |
| didrocks | but if it's syntaxically correct, ok :) | 14:15 |
| mhall119 | it's the way I was taught to type, on an actual type-writer | 14:15 |
| mhall119 | it's ingrained in my psyche now | 14:16 |
| mhall119 | didrocks: ok, all your changes are made in my packaging branch | 14:16 |
| mhall119 | lp:~mhall119/singlet/precise-package | 14:17 |
| didrocks | mhall119: sweet, looking :) | 14:17 |
| Kaleo | tsdgeos: yeah I am well aware of that | 14:20 |
| Kaleo | tsdgeos: it's really 2 separate tasks | 14:20 |
| tsdgeos | Kaleo: so you want it to always be enabled and then to inform of the service state? | 14:21 |
| Kaleo | tsdgeos: but to remove the enabled property you will have to think of a proper way | 14:21 |
| Kaleo | tsdgeos: that's right | 14:21 |
| Kaleo | tsdgeos: unless you see a real use for having it not enabled | 14:21 |
| Kaleo | tsdgeos: in which case I don't mind keeping it | 14:21 |
| tsdgeos | Kaleo: not really, but it's not me that did that class :D | 14:21 |
| Kaleo | tsdgeos: :) | 14:21 |
| Kaleo | tsdgeos: I know | 14:22 |
| Kaleo | tsdgeos: I am slapping that person right now :) | 14:22 |
| tsdgeos | i mean, the amount of thought i've put there is not the same someone else did so might have more insight | 14:22 |
| didrocks | mhall119: waiting for the scheduler to make the source package appears :) | 14:22 |
| Kaleo | tsdgeos: yep, checking with nerochiaro now | 14:24 |
| tsdgeos | Kaleo: can i cleanup the "DONE" tasks from the sketchpad? | 14:25 |
| didrocks | mhall119: ok, I sponsored and accepted in universe. Will accept the binary once built. | 14:26 |
| Kaleo | tsdgeos: yep | 14:26 |
| didrocks | mhall119: no, time for getting a look at the quickly side? | 14:26 |
| didrocks | now* | 14:26 |
| mhall119 | didrocks: yes please | 14:29 |
| Kaleo | tsdgeos: it's getting smaller :) | 14:30 |
| didrocks | mhall119: ok, I think we should decide first if we generate the .lens (and .scope) file or use static files | 14:30 |
| Kaleo | tsdgeos: https://code.launchpad.net/~aacid/unity-2d/unity-2d-shell_rtl_fixed_launcher/+merge/92015 approve | 14:30 |
| Kaleo | d | 14:30 |
| didrocks | mhall119: I have no strong opinion at all, I like the django approach | 14:30 |
| Kaleo | tsdgeos: I'm concerned about https://code.launchpad.net/~aacid/unity-2d/unity-2d-shell_ignore_super_on_spread/+merge/92013 | 14:30 |
| Kaleo | tsdgeos: I am looking for having it done only in QML | 14:31 |
| tsdgeos | Kaleo: everything? | 14:31 |
| didrocks | 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:31 |
| didrocks | mhall119: singlet built and binNEWed btw :) | 14:32 |
| tsdgeos | 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:32 |
| mhall119 | didrocks: thanks! | 14:34 |
| Kaleo | tsdgeos: you think too late for now? | 14:34 |
| mhall119 | I like generating .lens and .service files, since it means the user only edits the lens source | 14:34 |
| didrocks | yw :) | 14:34 |
| Kaleo | tsdgeos: I'll give a bit more thought then | 14:34 |
| didrocks | mhall119: ok, and we really on one source file by default? | 14:34 |
| didrocks | rely* | 14:35 |
| mhall119 | only need one | 14:35 |
| didrocks | ok, let's have a look then :) | 14:35 |
| mhall119 | but we should be able to handle having more than one | 14:35 |
| didrocks | do you have a binary file snippet? (the one you removed from singlet) | 14:35 |
| didrocks | and do you have quickly installed? :) | 14:36 |
| mhall119 | no, I never ended up making a binary for singlet | 14:36 |
| tsdgeos | Kaleo: nerochiaro: so kill the setEnabled in abstractdbusservicemonitor? | 14:36 |
| mhall119 | yes I have quickly | 14:36 |
| Kaleo | tsdgeos: yep | 14:36 |
| didrocks | mhall119: you had an example lens, isn't it? (we should base on that) | 14:36 |
| Kaleo | tsdgeos: nerochiaro just finished thiking about it | 14:36 |
| Kaleo | tsdgeos: and says: 'be careful' ): | 14:37 |
| Kaleo | :) | 14:37 |
| tsdgeos | oki | 14:37 |
| didrocks | and some helper scripts IIRC | 14:37 |
| mhall119 | didrocks: I had a test lens | 14:37 |
| mhall119 | and a couple that I wrote separate from, but using, singlet | 14:37 |
| didrocks | ok, let's start from one | 14:37 |
| didrocks | and try to turn that into a boiler plate | 14:38 |
| mhall119 | the helper scripts are what generate the .lens and .service files, and also what run the lens daemon | 14:38 |
| didrocks | yeah, and we will move them as quickly commands | 14:38 |
| mhall119 | ok, test/singlescope should do then | 14:38 |
| didrocks | lp:singlet ? | 14:39 |
| mhall119 | yes | 14:39 |
| didrocks | 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:39 |
| mhall119 | well first I have a question | 14:40 |
| Kaleo | tsdgeos: https://code.launchpad.net/~aacid/unity-2d/unity-2d-shell_inputshaperectangle_improvements/+merge/92031 approved | 14:40 |
| mhall119 | developers aren't going to want to make a "singlet project" | 14:40 |
| mhall119 | they're going to want to make a "single scope lens" or a "generic lens" or a "scope" | 14:41 |
| mhall119 | all of which base off different Singlet classes | 14:41 |
| didrocks | indeeed | 14:41 |
| didrocks | indeed* | 14:41 |
| didrocks | those will be 3 different Quickly templates | 14:41 |
| mhall119 | so would those all be separate templates, or can we do it all in one template? | 14:41 |
| mhall119 | ok | 14:41 |
| didrocks | then, we can import commands between templates | 14:41 |
| didrocks | so if we make the commands generic enough, no need for duplication | 14:41 |
| mhall119 | then I think if you can make one for the SingleScopeLens (test/singlescope), I can use that to make the other 2 | 14:42 |
| Kaleo | tsdgeos: https://code.launchpad.net/~aacid/unity-2d/unity-2d-shell_inputshapemask_improvements/+merge/92035 approved | 14:42 |
| didrocks | mhall119: makes totally sense | 14:42 |
| didrocks | mhall119: ok, I'll have a look at that and make some tests how to tackle this in an intelligent way | 14:42 |
| mhall119 | didrocks: and will these templates be part of the quickly package, or can we add new templates by installing independent packages? | 14:42 |
| Kaleo | tsdgeos: https://code.launchpad.net/~aacid/unity-2d/unity-2d-shell_windowsintersectmonitor_improvements/+merge/92037 approved | 14:42 |
| didrocks | mhall119: can be independant or part of trunk, as you wish, but it will be a separate binary package anyway | 14:43 |
| didrocks | all what is needed is that files are installed in a particular folder :) | 14:43 |
| mhall119 | ok, might be easier to keep it separate, that way I can update it without bothering you | 14:43 |
| didrocks | sure, let's do that then :) | 14:43 |
| mhall119 | didrocks: the next question | 14:43 |
| mhall119 | davidcalle had to do some special packaging to put things in /opt according to the ARB's guidelines | 14:44 |
| didrocks | yeah, "quickly package" will do that | 14:44 |
| mhall119 | will quickly's packaging files do that automatically? | 14:44 |
| mhall119 | cool | 14:44 |
| didrocks | that's already what I'm doing if you quickly "submitubuntu" | 14:44 |
| didrocks | I added the support to a bunch of files for that | 14:45 |
| didrocks | not sure how to handle a service with this though, but let's see :) | 14:45 |
| mhall119 | and that will also let us put the .lens and .service files into /usr? | 14:45 |
| didrocks | well, the support didn't for automagically packaging, that's one of the thing I have to look at | 14:46 |
| didrocks | (to do it beautifully or more like a hack for now) | 14:46 |
| mhall119 | ok | 14:46 |
| didrocks | we only target the ARB directories for the lenses/scopes, right? | 14:47 |
| mhall119 | for quickly, I would say so | 14:47 |
| didrocks | ok :) | 14:47 |
| mhall119 | anybody who needs theirs into main or universe will probably be able to do that on their own | 14:48 |
| didrocks | yeah, let's see how it goes :) | 14:48 |
| mhall119 | cool, so just ping me if you have questions about how singlet works | 14:48 |
| mhall119 | the functions for generating the files are in utils.py | 14:48 |
| mhall119 | most of which you can ignore and I will remove later | 14:49 |
| didrocks | I'll have a look :) | 14:49 |
| mhall119 | the install and packaging functions will not be needed | 14:49 |
| mhall119 | Singlet also generates a setup.py, I'm not sure if that's something that quickly would be better at though | 14:50 |
| didrocks | indeed | 14:50 |
| didrocks | not sure about the setup.py, depends on what will be needed I would say | 14:50 |
| mhall119 | not much, currently | 14:50 |
| mhall119 | I just generated the bare minimum needed to run python-mkdebian | 14:51 |
| didrocks | maybe I can tweak the opt/ stuff here | 14:51 |
| didrocks | it will be much cleaner than in debian/rules | 14:51 |
| mhall119 | well you know what they say | 14:52 |
| mhall119 | debian/rules are made to be broken | 14:52 |
| didrocks | I try not to follow this principle though :) | 14:52 |
| mhall119 | we all *try*, but it happens anyway | 14:52 |
| mhall119 | thanks for your help on this didrocks | 14:53 |
| mhall119 | ping me if you have any questions about what singlet is doing | 14:53 |
| didrocks | mhall119: no worry! I'll start on that in half an hour hopefully :) | 14:54 |
| mhall119 | which is likely, since it was a one-weekend project | 14:54 |
| tsdgeos | Kaleo: nerochiaro: the abstractdbusmonitor changes https://code.launchpad.net/~aacid/unity-2d/unity-2d-shell_abstractdbusmonitor_improvements/+merge/92043 | 14:56 |
| Kaleo | tsdgeos: great | 14:56 |
| tsdgeos | garg | 15:00 |
| Kaleo | tsdgeos: looks pretty good | 15:00 |
| tsdgeos | against the wrong branch :D | 15:00 |
| Kaleo | tsdgeos: it looks that you did not take the comment into account: | 15:00 |
| Kaleo | tsdgeos: /* We don't do this in the constructor because if the service is already up we emit the serviceStateChanged() signal during the constructor and we lose it since we can't have any slot connected to it already */ | 15:00 |
| Kaleo | tsdgeos: meaning that you need to adapt SpreadMonitor | 15:00 |
| tsdgeos | Kaleo: sure i did, did you read my other comment? | 15:01 |
| Kaleo | tsdgeos: let me relook tehn | 15:01 |
| Kaleo | tsdgeos: are you resubmitting? | 15:01 |
| Kaleo | tsdgeos: link? :) | 15:01 |
| tsdgeos | Kaleo: https://code.launchpad.net/~aacid/unity-2d/unity-2d-shell_abstractdbusmonitor_improvements/+merge/92044 | 15:01 |
| Kaleo | tsdgeos: thanks | 15:01 |
| Kaleo | "Tested with the Spread already up and the QueuedConnection does the trick nicely" | 15:02 |
| Kaleo | hmmm | 15:02 |
| tsdgeos | Kaleo: not that | 15:03 |
| Kaleo | tsdgeos: reading | 15:03 |
| tsdgeos | Kaleo: this // Use a Qt::QueuedConnection to give people a chance to attach to our serviceStateChanged signal that will be emmited from createInterface | 15:03 |
| tsdgeos | well yeah | 15:04 |
| tsdgeos | thery're mostly equivalent :D | 15:04 |
| Kaleo | tsdgeos: thinking | 15:04 |
| Kaleo | tsdgeos: I'm going to be a pain but reading it it looks like serviceState is the wrong name | 15:07 |
| Kaleo | tsdgeos: for a bool | 15:07 |
| tsdgeos | totally agreed | 15:07 |
| tsdgeos | it's you that suggested the name ;-) | 15:07 |
| Kaleo | tsdgeos: 'available' maybe | 15:08 |
| Kaleo | tsdgeos: well, yeah, I did not think just went on from the signal name | 15:08 |
| tsdgeos | Kaleo: serviceAvailable ? | 15:08 |
| Kaleo | tsdgeos: sure | 15:09 |
| tsdgeos | Kaleo: pushed | 15:12 |
| Kaleo | tsdgeos: ok, after quick debate here | 15:13 |
| Kaleo | tsdgeos: the QueuedConnection is deemed as being a hack | 15:13 |
| Kaleo | tsdgeos: fairly unpredictable | 15:13 |
| tsdgeos | it's not unpredictable at all | 15:13 |
| tsdgeos | i'm deeming you as not trusting Qt | 15:13 |
| Kaleo | tsdgeos: better to call serviceAvailable() in the SpreadMonitor's constructor | 15:14 |
| Kaleo | tsdgeos: so, what I mean by unpredictable is that | 15:14 |
| Kaleo | tsdgeos: we have no guarantee the clients (SpreadMonitor) is going to connect to serviceAvailableChanged before it's fired | 15:15 |
| tsdgeos | you weren't before either | 15:15 |
| Kaleo | tsdgeos: correct | 15:15 |
| tsdgeos | you had to connect before calling setEnabled | 15:15 |
| Kaleo | tsdgeos: we were relying on the order of evalution of QML | 15:15 |
| Kaleo | tsdgeos: it was _bad_ | 15:15 |
| Kaleo | tsdgeos: right :) | 15:16 |
| tsdgeos | now you have to connect before returning to the event loop | 15:16 |
| tsdgeos | but ok, i'll call serviceAvailable if you prefer that | 15:16 |
| tsdgeos | but ok, i'll call serviceAvailable if you prefer that | 15:18 |
| tsdgeos | wopps | 15:18 |
| tsdgeos | :D | 15:18 |
| Kaleo | tsdgeos: yes, I would prefer the more obvious way | 15:18 |
| kamstrup | seb128: did you see RainCTs nautilus patch for zeitgeist integration? | 15:19 |
| seb128 | kamstrup, yes, it's on my todolist but low on it, I'm not sure I like adding a non trivial patch which didn't get a least discussed upstream though | 15:19 |
| seb128 | kamstrup, RainCT: could you get an upstream bug and suggest it as a build time option? | 15:20 |
| kamstrup | sounds reasonable... | 15:20 |
| kamstrup | cc mhr3 ^^ | 15:20 |
| tsdgeos | Kaleo: pushed | 15:21 |
| Kaleo | tsdgeos: sweet, I'll review it now then we can mumble the strutmanager | 15:21 |
| seb128 | kamstrup, btw I got the gtk2 patch in, let me know if firefox and tb behave if you test those | 15:21 |
| mhr3 | seb128, i think there was some talk about it, and nautilus was like no way | 15:22 |
| mhr3 | so... :/ | 15:22 |
| kamstrup | seb128: I tested both. FF works now, but TB mysteriously does not. I asked RainCT to look into it | 15:22 |
| seb128 | kamstrup, ok | 15:22 |
| seb128 | mhr3, RainCT, kamstrup: if upstream say "no way" that's fine but I want a bugzilla bug discussion for the record and the patch pointing to it | 15:23 |
| Kaleo | tsdgeos: it looks great | 15:23 |
| seb128 | kamstrup, RainCT, mhr3: I think it's fair to ask 1- to try again to raise the topic 2- to have public record of why we have to carry the patch | 15:23 |
| Kaleo | tsdgeos: a detail: reversing the reading of serviceAvailable and the connection to the changed signal would be more multi thread proof | 15:24 |
| Kaleo | tsdgeos: in SpreadMonitor | 15:24 |
| seb128 | kamstrup, RainCT, mhr3: it will avoid having discussions later on why we don't upstream our work | 15:24 |
| mhr3 | seb128, very well, afaik it was only discussed on irc, so sure we can open a bug in nautilus | 15:24 |
| mhr3 | RainCT, could you? ^^ | 15:24 |
| seb128 | thanks | 15:25 |
| tsdgeos | Kaleo: how? | 15:25 |
| Kaleo | tsdgeos: imagine that the value changes after you read it but before you connected to the changed signal | 15:25 |
| Kaleo | tsdgeos: functional tests look good too | 15:25 |
| Kaleo | tsdgeos: yay | 15:26 |
| tsdgeos | Kaleo: the other way around the same will happen | 15:26 |
| Kaleo | tsdgeos: really? how? | 15:26 |
| tsdgeos | ah | 15:26 |
| Kaleo | tsdgeos: if you are connected to changed signal in the first place, you should be fine no? | 15:26 |
| tsdgeos | you mean the service becomes available after the if and before the connect? | 15:27 |
| Kaleo | tsdgeos: right :) | 15:27 |
| tsdgeos | i don't think that's ever going to happen | 15:28 |
| tsdgeos | but if it makes you happy i can exchange the order | 15:28 |
| tsdgeos | done | 15:29 |
| Kaleo | tsdgeos: I agree, not going to happen | 15:29 |
| Kaleo | tsdgeos: just good practice | 15:29 |
| Kaleo | tsdgeos: approved then | 15:29 |
| tsdgeos | Kaleo: with this new construct if the service becomes available after the ocnnect and before the if, you end up calling onServiceAvailableChanged(true) twice, you end up with two connect(dbusInterface(), SIGNAL(IsShownChanged(bool)), SIGNAL(shownChanged(bool))); and then everything is weird :D | 15:30 |
| Kaleo | tsdgeos: that's not because of the construct per se :) | 15:31 |
| Kaleo | tsdgeos: we should either not call onServiceAvailableChanged if it was not actually changed | 15:32 |
| Kaleo | tsdgeos: actually, that's the best option | 15:33 |
| tsdgeos | sorry? | 15:33 |
| Kaleo | tsdgeos: 16:32 < Kaleo> tsdgeos: we should either not call onServiceAvailableChanged if it was not actually changed | 15:33 |
| Kaleo | tsdgeos: sorry | 15:33 |
| Kaleo | tsdgeos: wrong copy paste | 15:33 |
| Kaleo | tsdgeos: I mean, the simplest fix for that | 15:34 |
| tsdgeos | confused | 15:34 |
| tsdgeos | what is the simplest fix? | 15:34 |
| Kaleo | tsdgeos: is to not call onServiceAvailableChanged if it has not actually changed since last time we checked | 15:34 |
| tsdgeos | that's why we only call it if it is true now | 15:35 |
| tsdgeos | coding that class for thread awareness is not something i think makes any sense | 15:35 |
| tsdgeos | if we're not planning to do so | 15:35 |
| tsdgeos | you're going to need to start adding mutexes | 15:36 |
| Kaleo | tsdgeos: I do not want to make it thread safe | 15:39 |
| Kaleo | tsdgeos: one sec | 15:39 |
| tsdgeos | then i don't understand what we are discussing about | 15:40 |
| Kaleo | tsdgeos: just good practice | 15:40 |
| tsdgeos | that good practice doesn't make sense | 15:41 |
| tsdgeos | the other code is as good as this new one | 15:41 |
| tsdgeos | in the scenario we care about | 15:41 |
| tsdgeos | which is the non threaded one | 15:41 |
| Kaleo | tsdgeos: it's just about reading the value before connecting to the changed signal | 15:41 |
| Kaleo | tsdgeos: that I believe is a valid good practice | 15:41 |
| Kaleo | nerochiaro: opinion? | 15:41 |
| Kaleo | tsdgeos: sorry, I meant the opposite | 15:42 |
| Kaleo | tsdgeos: connecting to the changed signal before reading the value | 15:42 |
| tsdgeos | Kaleo: i sincerely don't see "improvement" does it give us | 15:43 |
| Kaleo | tsdgeos: nothing concretely | 15:43 |
| Kaleo | tsdgeos: not in the short term | 15:43 |
| Kaleo | tsdgeos: like many other good practices | 15:43 |
| Kaleo | tsdgeos: they are often made not to necessarily give you short term improvements | 15:43 |
| Kaleo | tsdgeos: but longer term ones | 15:43 |
| tsdgeos | sure, i don't see the longer term benefit either | 15:44 |
| tsdgeos | but let's move on to more important stuff | 15:44 |
| Kaleo | tsdgeos: sure | 15:44 |
| tsdgeos | discussing this is a nice bar discussion for the next beer ;-) | 15:44 |
| Kaleo | tsdgeos: I think in 10 minutes I'll be out of that meeting | 15:46 |
| Kaleo | tsdgeos: and we can discuss the StrutManager | 15:46 |
| Kaleo | tsdgeos: and then I think we are pretty much done.. | 15:47 |
| Kaleo | :) | 15:47 |
| tsdgeos | Kaleo: ok, https://code.launchpad.net/~aacid/unity-2d/unity-2d-shell_abstractdbusmonitor_improvements/+merge/92044 still not approved, not happy? | 15:47 |
| Kaleo | tsdgeos: just not pressed the button yet :) | 15:47 |
| Kaleo | tsdgeos: done | 15:47 |
| AlanBell | is there any documentation on bamf somewhere? | 15:53 |
| AlanBell | http://developer.ubuntu.com/api/ubuntu-11.10/c/bamf/ is useless, and googling just finds stuff about people with bad bottoms and dysfunctional maternal relationships | 15:54 |
| AlanBell | I want to use python to find all the windows of a particular type and their window titles (like all the gnome-terminal windows) and then populate the launcher quicklist with links to the windows | 15:55 |
| mhall119 | AlanBell: there's a bug in LP to fix bamf documentation | 15:58 |
| mhall119 | it should be auto-generated like the unity API docs, but it's not doing it right | 15:59 |
| AlanBell | not sure if that is even the right kind of documentation | 15:59 |
| AlanBell | it should be doing something on dbus apparently | 15:59 |
| mhall119 | AlanBell: https://bugs.launchpad.net/bamf/+bug/924471 | 16:00 |
| ubot5 | Launchpad bug 924471 in bamf (Ubuntu) "Developer doc is empty in devhelp" [Undecided,Confirmed] | 16:00 |
| mhall119 | Trevinho: ^^ are you going to be working on that? | 16:00 |
| AlanBell | I can't find anything anywhere on the internet about it | 16:00 |
| AlanBell | I can probably figure it out from dbus introspection if I can find out the well known name and the object it exports apparently. 'com.canonical.bamf' doesn't appear to be it. | 16:04 |
| Trevinho | mhall119: I'm very busy right now... I've to do stuff before ff... | 16:05 |
| Kaleo | tsdgeos: a last thing we should check once we are done is suspicious console outputs | 16:06 |
| mhall119 | Trevinho: not rushing you, just wanted to let AlanBell know the status of it | 16:06 |
| gord | AlanBell, org.ayatana.bamf | 16:06 |
| AlanBell | thanks gord, I would not have guessed that one! | 16:07 |
| Trevinho | Andy80: also... gdbus monitor --session --dest=org.ayatana.bamf to understand what's going on... | 16:07 |
| tsdgeos | Kaleo: yep | 16:08 |
| gord | AlanBell, a bit of help, install d-feet from the repos, connect to the session bus, it has a search box then to help finding things easier. can just put "bamf" or whatever in there | 16:08 |
| AlanBell | ah, I see | 16:08 |
| tsdgeos | Kaleo: dooh, can't call BaseBehaviour Behaviour since QML already has a Behaviour :D | 16:09 |
| Kaleo | tsdgeos: right :) | 16:10 |
| Kaleo | tsdgeos: even without the u? | 16:10 |
| Kaleo | tsdgeos: just kidding | 16:10 |
| tsdgeos | Kaleo: actually it's both without the u | 16:10 |
| Kaleo | tsdgeos: so, what I wrote in the sketchpad was my first thought | 16:10 |
| Kaleo | tsdgeos: there may be better ideas | 16:10 |
| tsdgeos | Kaleo: so BaseBehavior? or VisibiltyBehavoir? or AbstractBehavior? | 16:10 |
| Kaleo | tsdgeos: would Base.qml be consistent? | 16:11 |
| AlanBell | gord: nice, that is probably enough documentation to get me going :) | 16:11 |
| tsdgeos | Kaleo: it'd be consistent, to be honest i like the Behavior at the end, makes it easier to understand | 16:12 |
| tsdgeos | Base {} or IntellHide {} | 16:12 |
| tsdgeos | and not as easy to read as | 16:12 |
| tsdgeos | BaseBehavior{} and IntelliHideBehavior{} | 16:13 |
| Kaleo | tsdgeos: right | 16:13 |
| Kaleo | tsdgeos: that's fine by me | 16:13 |
| Kaleo | tsdgeos: is it still ok to put them in a directory | 16:13 |
| Kaleo | ? | 16:13 |
| tsdgeos | Kaleo: helps with logical grouping | 16:14 |
| Andy80 | Trevinho: hi! Sorry I was not following the conversation, how can I help? | 16:14 |
| Kaleo | tsdgeos: ok | 16:14 |
| AlanBell | Andy80: I think it was aimed at me | 16:14 |
| tsdgeos | Kaleo: on the other hand i'm not really sure the autohide and intellhide will be useful outside the launcher as to put them in common, but it doesn't hurt either | 16:15 |
| Andy80 | AlanBell: ah ok, sorry :) | 16:15 |
| Kaleo | tsdgeos: right I was going for the it does not hurt | 16:17 |
| Andy80 | Kaleo: when you have some spare minutes, I'm still in queue for a reply about unity2d/qt5 :D I wrote a summary of the situation here https://lists.launchpad.net/unity-dev/msg00404.html reporting all the errors and all the tests I did, and there are also some updates I tried after asking help to #qt guys, but I'm still locked with it... | 16:17 |
| Kaleo | Andy80: right | 16:18 |
| Kaleo | Andy80: I don't think I'll be able to get to it before Feature Freeze | 16:18 |
| Kaleo | Andy80: end of next week | 16:18 |
| Kaleo | Andy80: sorry | 16:18 |
| Andy80 | Kaleo: no problem, I fully understand this is a low-priority task ;) I'll wait and I'll try to dedicate to other stuff in the mean time. | 16:19 |
| Kaleo | Andy80: thank you | 16:19 |
| tsdgeos | Kaleo: https://code.launchpad.net/~aacid/unity-2d/unity-2d-shell_behaviours_shuffling/+merge/92065 | 16:20 |
| Kaleo | tsdgeos: fantastic | 16:23 |
| Kaleo | tsdgeos: about https://code.launchpad.net/~aacid/unity-2d/unity-2d-shell_ignore_super_on_spread/+merge/92013 ; after carefully checking the code, you are right, it seems like too much of a big endeavour to try to move toggleDash to QML right now | 16:25 |
| Kaleo | tsdgeos: so let's just fix the MR for the latest -shell, expose the spreadMonitor to the QML context so that we only have one instance | 16:25 |
| Kaleo | tsdgeos: and merge it | 16:25 |
| Kaleo | tsdgeos: ok? | 16:25 |
| tsdgeos | sure, give me a minute to do it | 16:26 |
| Kaleo | tsdgeos: the behaviour stuff looks good | 16:28 |
| Kaleo | tsdgeos: just a question in passing | 16:28 |
| Kaleo | tsdgeos: you ever used qdoc in qml? | 16:28 |
| tsdgeos | not really | 16:29 |
| Kaleo | tsdgeos: we'll have to start doing that at some point | 16:30 |
| Kaleo | tsdgeos: oh oh oh oh | 16:36 |
| Kaleo | tsdgeos: I just realised: | 16:36 |
| Kaleo | tsdgeos: in ShellDeclarativeView::setDashActive(bool value) | 16:36 |
| Kaleo | if (isSpreadActive()) { | 16:36 |
| Kaleo | tsdgeos: line 204 | 16:36 |
| tsdgeos | wow | 16:37 |
| Kaleo | :) | 16:37 |
| tsdgeos | ShellDeclarativeView::isSpreadActive() <-- have a look at that | 16:37 |
| tsdgeos | it's like the SpreadMonitor all in one :D | 16:37 |
| tsdgeos | and probably not working... | 16:38 |
| tsdgeos | ah not | 16:38 |
| tsdgeos | the problem is that we have a bzillion ways of activating the dash :D | 16:39 |
| Kaleo | tsdgeos: right | 16:43 |
| Kaleo | tsdgeos: we need to fix that stuff | 16:44 |
| tsdgeos | Kaleo: want to mumble now about the strutmanager so i can start working on that tomorrow morning? | 16:46 |
| tsdgeos | problem is that toggleDash name is actually wrong | 16:48 |
| tsdgeos | and should be called toggleDashbutShowingHomeWhenYouShowIt | 16:48 |
| tsdgeos | :D | 16:48 |
| Kaleo | :) | 16:49 |
| Kaleo | tsdgeos: yes, let's do that | 16:49 |
| Kaleo | tsdgeos: my mic is still broken | 16:51 |
| Kaleo | :( | 16:51 |
| tsdgeos | oh :-( | 16:51 |
| Kaleo | tsdgeos: let me think | 16:51 |
| Kaleo | tsdgeos: I'll connect from my phone | 16:51 |
| Kaleo | tsdgeos: one sec | 16:51 |
| om26er | knock knock someone in the report would like to implement bug 874252 in 2D any one care to reply ? | 17:15 |
| ubot5 | Launchpad bug 874252 in tomboy (Ubuntu) "With indicators I can't set any note to display always in list" [Undecided,New] https://launchpad.net/bugs/874252 | 17:15 |
| om26er | oops wrong bug | 17:15 |
| om26er | bug 874254 | 17:15 |
| ubot5 | Launchpad bug 874254 in unity-2d "top bar, integrated menu - when a application is first launched, the integrated menu should be displayed for 2 seconds before fading out of view" [Undecided,New] https://launchpad.net/bugs/874254 | 17:15 |
| greyback|lunch | om26er: am aware of it, but won't get it it until after FF | 17:34 |
| === greyback|lunch is now known as greyback | ||
| greyback | that was a long lunch | 17:35 |
| om26er | greyback, alright, thx :) | 17:35 |
| AlanBell | anyone know how to raise a window that has been identified through bamf? | 17:49 |
| AlanBell | I have the XID that bamf reports, but wnck.window_get(xid) does not seem to contain anything | 17:50 |
| === m_conley_away is now known as m_conley | ||
| AlanBell | never mind, I figured it out, you have to do screen_get_default first | 18:10 |
| AlanBell | in other news, I have working window quicklists \o/ | 18:10 |
| === s9iper1 is now known as bil21al | ||
| mhall119 | \o/ | 18:22 |
| mhall119 | AlanBell: on what launcher? | 18:23 |
| AlanBell | mhall119: http://paste.ubuntu.com/834248/ | 18:23 |
| AlanBell | hacky, but it works (does not remove quicklists, or listen to window add/remove signals) | 18:24 |
| AlanBell | just adds them for every window every second, it is a prototype | 18:24 |
| mhall119 | I'm wondering if such a quicklist on the workspace switcher would be useful... | 18:24 |
| AlanBell | it would have too much stuff in it I should think | 18:25 |
| mhall119 | then again, I currently have 23 windows open, which is low for me, so maybe a quicklist of windows wouldn't work at all | 18:25 |
| AlanBell | but this is great, being able to raise one terminal window above a browser without all of them raising | 18:25 |
| AlanBell | one think I can't work out is how to have multiple quicklists of the same name, so if I have several terminal windows with title "alan@alanlaptop:~" I want to see all of them, not just one | 18:26 |
| mhall119 | AlanBell: scale + filter plugins perhaps? | 18:28 |
| mhall119 | though filter isn't enabled by default | 18:29 |
| AlanBell | well I kind of want to stick to as standard a configuration as possible | 18:30 |
| AlanBell | if I wanted it to just be useable I would turn off the unity alt-tab switcher and use a normal one | 18:31 |
| sbte | andyrock, may I ask when texture_from_cairo_graphics and when texture_ptr_from_cairo_graphics should be used? | 18:38 |
| sbte | because there is at least one more place where this should be fixed | 18:38 |
| andyrock | texture_from_cairo_graphics? never :) | 18:39 |
| andyrock | ntw thumper can give you more info :P | 18:39 |
| andyrock | *bt | 18:39 |
| andyrock | *btw | 18:39 |
| sbte | andyrock, it's used a lot it seems | 18:49 |
| sbte | but it seems that in those cases it's not written to a nux::ObjectPtr<nux::BaseTexture> | 18:49 |
| andyrock | yeah, yeah but it doesn't leak memory all the time | 18:49 |
| andyrock | btw Trevinho is going to fix it | 18:49 |
| sbte | andyrock, so no need for me to push it? | 18:49 |
| andyrock | sbte, you should talk with Trevinho :) | 18:50 |
| andyrock | if you want you can do it | 18:50 |
| andyrock | thank you btw | 18:50 |
| sbte | andyrock, no problem | 18:52 |
| sbte | Trevinho, do you want to push a fix or should I do it? | 18:52 |
| sbte | andyrock, can you maybe help me with compiling unity? | 18:53 |
| sbte | I can't get it to work | 18:53 |
| andyrock | sbte, of course | 18:53 |
| andyrock | where do you get blocked? | 18:54 |
| sbte | andyrock, here | 18:55 |
| sbte | CMake Error at /usr/share/cmake-2.8/Modules/FindCompiz.cmake:58 (string): | 18:55 |
| sbte | string sub-command REGEX, mode REPLACE needs at least 6 arguments total to | 18:55 |
| sbte | command. | 18:55 |
| sbte | Call Stack (most recent call first): | 18:55 |
| sbte | plugins/unityshell/CMakeLists.txt:1 (find_package) | 18:55 |
| sbte | I have the staging ppa enabled and all | 18:55 |
| andyrock | first of all | 18:55 |
| andyrock | sudo apt-get build-dep unity | 18:55 |
| sbte | andyrock, yep, did that | 18:56 |
| andyrock | are you in the build directory? | 18:56 |
| sbte | yes | 18:56 |
| andyrock | try to rm it and rebuild it again | 18:57 |
| sbte | I just made a build directory inside my bzr clone | 18:57 |
| andyrock | or | 18:57 |
| sbte | andyrock, did that a few times already | 18:57 |
| andyrock | can you paste the commands that you use for building unity? | 18:58 |
| sbte | export SOURCE=/home/sven/Desktop/vm/unity | 18:59 |
| sbte | export PREFIX=/home/sven/staging | 18:59 |
| sbte | export PKG_CONFIG_PATH="$PREFIX/lib/pkgconfig:$PKG_CONFIG_PATH" | 18:59 |
| sbte | export LD_LIBRARY_PATH="$PREFIX/lib:$LD_LIBRARY_PATH" | 18:59 |
| sbte | export LD_RUN_PATH="$PREFIX/lib:$LD_RUN_PATH" | 18:59 |
| sbte | export XDG_DATA_DIRS="$PREFIX/share:$XDG_DATA_DIRS" | 18:59 |
| sbte | and then inside unity/build | 18:59 |
| sbte | cmake .. -DCMAKE_BUILD_TYPE=Debug -DCOMPIZ_PLUGIN_INSTALL_TYPE=local -DGSETTINGS_LOCALINSTALL=ON -DCMAKE_INSTALL_PREFIX="$PREFIX" | 18:59 |
| andyrock | mmm... | 19:02 |
| andyrock | do you have the /home/sven/Desktop/vm/unity directory? | 19:04 |
| andyrock | btw normally i just did | 19:04 |
| andyrock | bzr branch lp:unity | 19:04 |
| andyrock | cd unity | 19:04 |
| andyrock | mkdir build; cd build | 19:04 |
| andyrock | cmake .. -DCOMPIZ_PLUGIN_INSTALL_TYPE=local -DCMAKE_INSTALL_PREFIX=/usr | 19:05 |
| andyrock | sudo make install -j4 | 19:05 |
| andyrock | but it can break your system | 19:05 |
| andyrock | :) | 19:05 |
| sbte | andyrock, that's what I did the first time, but then I started following guides | 19:05 |
| sbte | because it didn't work | 19:05 |
| sbte | :P | 19:05 |
| andyrock | do it again | 19:06 |
| andyrock | please :) | 19:06 |
| sbte | andyrock, now it works :S | 19:12 |
| andyrock | it will remove your system compiz installation | 19:13 |
| andyrock | btw it should work :) | 19:13 |
| sbte | andyrock, so the problem is just that it can't find compiz in the right place? | 19:15 |
| sbte | so if I compile compiz too, it will work? | 19:16 |
| andyrock | sbte, don't compile compiz! :) | 19:16 |
| andyrock | you don't need to build it | 19:16 |
| thumper | sbte: hi | 19:30 |
| thumper | sbte: I have a branch to push that fixes some of these | 19:30 |
| thumper | worked on it last night | 19:30 |
| thumper | (instead of sleeping) | 19:30 |
| sbte | thumper, so I'm a bit too late :P | 19:31 |
| thumper | sbte: just a tad | 19:32 |
| thumper | the difference between the two methods | 19:32 |
| sbte | thumper, well, I'll try to find some new leaks | 19:32 |
| thumper | is that texture_from_cairo_graphics returns a BasePointer* | 19:32 |
| sbte | yes, I found that | 19:32 |
| thumper | and texture_ptr_from_cairo_graphics returns a nux::ObjectPtr<BasePointer> | 19:33 |
| thumper | :) | 19:33 |
| thumper | the problem resolves around whether the nux::Object at the bottom of the hierarchy is initially owned or not | 19:33 |
| thumper | for all views, they aren't owned | 19:33 |
| thumper | so putting them in a smart pointer is normally fine | 19:33 |
| thumper | but textures are owned | 19:33 |
| thumper | so assigning or constructing a smart poniter with one makes the refcount off by one | 19:33 |
| thumper | damn confusing | 19:34 |
| sbte | ok | 19:34 |
| RainCT | seb128: the Thunderbird thing is because of the binary being called thunderbird-bin and the .desktop file just having 'thunderbird' | 19:54 |
| RainCT | seb128: the next zeitgeist-datahub release will fix it | 19:55 |
| seb128 | RainCT, great, thanks | 19:55 |
| andyrock | thumper, so you need to unreference it two times? | 20:01 |
| andyrock | right? | 20:01 |
| AlanBell | http://paste.ubuntu.com/834375/ mhall119 updated prototype that runs on unity 5.2 | 20:02 |
| === s9iper1 is now known as bil21al | ||
| === andyrock is now known as andyrock|dinner | ||
| ejat | hi | 20:33 |
| * ejat just do and update in precise .. now my launcher does not apper if u turn ON in behaviour | 20:33 | |
| Freddi | Hi tedg, can you give me advice about the appmenu / Dbusmenu? | 20:50 |
| Freddi | I want to add the appmenu to an application that is not written in one of the supported toolkits. Thus the menu is not automatically extracted from the toolkit. | 20:50 |
| tedg | Freddi, Advice? | 20:50 |
| Freddi | I want to write a python script as a bridge between that application and Dbus. I assume I have to add the menu structure as a Dbusmenu. | 20:51 |
| tedg | Freddi, Ah, okay. Does the toolkit use glib? | 20:51 |
| tedg | Freddi, Yup, basically. | 20:51 |
| Freddi | It's actually a Wine application and I want to write a python script as a bridge. I have access to the menu structure | 20:51 |
| tedg | Freddi, Right now you register the menu and XID with the service, but we're moving to having a couple XAtoms on the window. But that shouldn't be too bad either way. | 20:51 |
| Freddi | but I would need an example how to attach it as a Dbusmenu to the appmenu | 20:52 |
| Freddi | ok | 20:52 |
| tedg | Freddi, probably the best is lp:appmenu-gtk That's basically all it does. | 20:52 |
| Freddi | ok thanks! | 20:53 |
| Freddi | I have found an example for creating a Dbusmenu which is then attached as quicklist (very easy). https://wiki.ubuntu.com/Unity/LauncherAPI#Python_Example | 20:54 |
| Freddi | There is no similar example for the appmenu, I hope I can figure that out | 20:54 |
| tedg | Freddi, Not really, as we don't expect people to really do their own menu export code. :-) | 20:56 |
| tedg | It's a special case. | 20:56 |
| Freddi | sounds logical. If the toolkit is supported, then that's the proper way ;-) | 20:58 |
| tedg | Freddi, I need to head out, but feel free to drop me a mail if you run into issues. | 20:58 |
| === salem_ is now known as _salem | ||
| thumper | andyrock|dinner: kinda | 21:59 |
| === andyrock|dinner is now known as andyrock | ||
| mfisch | mhall119: I'm seeing some odd behavior from the unity-sample-lens (unity 4.0). If I kill the python back-end without clearing the search it won't work. | 22:17 |
| mfisch | mhall119: I have to bring the dash up again, go to the lens, type something, hit X, and then restart my script. Seems very odd | 22:18 |
| mhall119 | mfisch: did you mean to ping me? | 22:20 |
| mfisch | mhall119: sorry, I thought you wrote that sample lens, I see now that you did not | 22:21 |
| === m_conley is now known as m_conley_away | ||
| === s9iper1 is now known as bil21al | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!