[06:32] smspillaz around? === mmrazik is now known as mmrazik|otp [08:20] mmrazik|otp: FYI, branch subscribers in most of projects are a mess, I'm fixing them === mmrazik|otp is now known as mmrazik [08:46] Trevinho: can you approve it now https://code.launchpad.net/~aacid/nux/const_get_position/+merge/131856 so i don't get another conflict in the ABI line? [08:54] Mirv: I commented on https://code.launchpad.net/~timo-jyrinki/ubuntu/quantal/gnome-settings-daemon/ubuntu.fix1058004/+merge/127430 [09:02] didrocks: thanks, it indeed needs to be in raring first [09:02] yep ;) [09:02] Mirv: I think it still worth a SRU if you want to :) [09:03] sure [09:05] thanks :) === mmrazik is now known as mmrazik|otp === mmrazik|otp is now known as mmrazik [10:46] hello folks [10:46] I'm doing my first steps with autopilot, and can't seem to convince it to discover my tests [10:47] did anyone use autopilot already and could give me a hand with this? [10:58] pitti: i've used it, how are you running it? [10:59] tsdgeos: I'm following the tutorial, and created a ~/gedit_test.py (http://paste.ubuntu.com/1379193/) === mmrazik is now known as mmrazik|lunch [10:59] "autopilot list ." crashes, "autopilot list gedit_test" and "autopilot list gedit_test.py" both find no tests [10:59] ok [10:59] so what i did [10:59] which i'm not an expert at all [10:59] is this [10:59] tsdgeos: I also tried putting it into a package (gedit_tests/, with __init__.py and tests.py), doesn't help [10:59] ah [11:00] that's what i did [11:00] worked for me [11:00] hm [11:00] I'm using ppa:autopilot/ppa with quantal [11:00] well, on raring, but the quantal packages from the PPA [11:00] tsdgeos: perhaps I'm missing some magic in my .py file itself? [11:03] i don't see anything bad, but as said i'm not an expert [11:03] pitti: so if you put it in a package [11:03] ok, thanks for having a look [11:03] and then do autopilot list gedit_tests from the dir containing gedit_tests what happens? [11:04] $ mkdir gedit_tests [11:04] $ cp ~/gedit_test.py gedit_tests/test.py [11:04] $ touch gedit_tests/__init__.py [11:04] $ autopilot list . -> ValueError: Empty module name [11:04] ooh [11:04] from parent dir? [11:04] $ autopilot list gedit_tests [11:04] that works [11:04] odd, it just hanged with that some minutes ago [11:05] it's my magic touch :D [11:05] now running it fails with RuntimeError: Unable to find Autopilot interface. [11:05] but one step further :) [11:06] ah, it only fails with that if I close my gedit window [11:07] the self.keyboard.press_and_release('Ctrl+q') doesn't seem to work [11:07] but anyway, I'll poke at this [11:07] tsdgeos: thanks! [11:12] oh, it's apparently because there is no autopilot-gtk module; the autopilot-gtk package is empty (and also only available for i386) [11:20] filed as https://bugs.launchpad.net/autopilot/+bug/1082326 [11:20] Ubuntu bug 1082326 in Autopilot "GTK autopilot module missing" [Undecided,New] [11:29] tsdgeos: ah, FTR, got it (see bug followup) [11:30] interesting [11:30] i was using autopilot-qt [11:30] that has stuff inside === _salem is now known as salem_ === mmrazik|lunch is now known as mmrazik [12:46] tsdgeos: do you know how to access the widget tree in an autopilot-gtk test? [12:47] there is zero documentation about it, and dir(self) and dir(self.application) don't have something obvious either [12:47] pitti: nope, have you tried "autopilot vis" that gives you an app that shows you the properties of the thing [12:47] yes, I did try it [12:47] then no sorry, all autopilot i used was with qt [12:47] but that doesn't give me any identifiers for the labels (such as the one in the GtkBuilder file) [12:48] tsdgeos: how do you do it in Qt? [12:48] dash = ... # Get the dash object from somewhere [12:48] ^ in the doc [12:48] it's the "in the somewhere" that needs some expansion [12:48] err, "from somewhere" [12:49] i do [12:49] pitti: if only gtk exported the gtkbuilder id's and let you query them..... [12:49] results = self.app.select_single("Results") [12:49] where Results is the class i'm looking for [12:49] * xnox did file a bug report about it, and it was dismissed as not needed. [12:49] tsdgeos: ah, thanks; that's not even in in dir() (or perhaps doesn't exist for gtk) [12:49] xnox: too bad :( === dandrader is now known as dandrader|afk [12:50] pitti: the reason was "you don't need it in C", and I was like "but you do want in OO languages & for interspection", I was dismissed as a lunatic. === gatox is now known as gatox_lunch [12:51] ah, I was printing the wrong dir(), ignore me [12:51] pitti: it's in the internal gtkbuilder structure.... which I can code a ld_preload library to expose. [12:51] xnox: do you happen to have the bug link at hand? [12:51] pitti: hm... let me try to find it. [12:54] pitti: I have irc chat logs only & no bug #. [12:54] ah, so it's perhaps worth another attempt; thanks === dandrader|afk is now known as dandrader [14:11] tsdgeos: done === seb128_ is now known as seb128 [14:24] Trevinho: hi, did you get a chance to read my questions around the lp:~mvo/unity/sc-launcher-integration-fixes branch? I need some help to understand the change better :) [14:28] mvo: no sorry... looking now [14:28] thanks === dandrader is now known as dandrader|lunch === gatox_lunch is now known as gatox [15:05] mvo: gave a look.. Basically I mean that once you've installed the app, then you can make apt to send to unity the desktop id of the new file... So this means "/tmp/software-center-agent:desktop-id.desktop" for instance... At this point you don't need to do all the manual search you're doing to get from it the real path... Just get the id substring and use the utility function [15:08] Trevinho: ok, so that would mean that there needs to be a new dbus call for unity, right? to replace a existing launcher icon (the temp one that is just valid during the install) with the new one? [15:08] mvo: imho that would be better, so that you can keep all the low level stuff there [15:09] whie unity will be just informed with the actual result [15:10] mvo: or just pass that during the "On-Finished" signal... [15:10] Trevinho: ok, I will think about it [15:11] mvo: but if you don't want to do that, it's fine to use the current way, but use the utility function for doing the real parsing [15:16] Trevinho: ok, thanks. I would prefer to leave it as is for now, but I will use the utility function === dandrader|lunch is now known as dandrader === didrocks1 is now known as didrocks === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader [18:09] hey there. does anyone know the current email adress of jason smith or any other way to context ihm? [18:09] *contact him [20:54] larsu: from a modal dialog I can access the menubar of its parent... is this a bug? [20:56] conscioususer, right now all windows in an application have the same menu bar. That's more an api limitation than a bug :) [21:07] conscioususer, hey wait, you probably mean something other than me. You want the menu to disappear in that case? Or have everything disabled? === salem_ is now known as _salem [21:43] Hello there I am not sure what I did in the last 4 hours but I can not seem to get cmake to configure right. after rm /build/* I keep on getting a linked lib error for unityshell for the compiz plugin I will pastebin error [21:43] well it is not that big [21:43] CMake Error at plugins/unityshell/CMakeLists.txt:13 (add_dependencies): [21:43] add_dependencies Adding dependency to non-existent target: unity-shell [21:44] but target is there ? [21:45] cmake command I am running [21:45] cmake ../ -DCOMPIZ_PLUGIN_INSTALL_TYPE=local -DCMAKE_INSTALL_PREFIX=/home/joseph/Desktop/ubuntu-tv-3d/trunk/build -DGSETTINGS_LOCALINSTALL=O [21:47] I will hack away at plugins/unityshell/CMakeLists.txt for now [21:57] Work around : hardcode in unity version and move the linking of unityshell to the end and it is building now [21:58] libunity-6.0-5 * === bschaefer is now known as bschaefer|lunch === bschaefer|lunch is now known as bschaefer [22:26] larsu: disabled would be expected, as this is the case for DEs without global menus [22:26] oops, he left