=== aruiz_ is now known as aruiz [01:11] Saviq: I know I'm asking you to find a dinosaur, but.... do you remember where we put that code for the simple QML Twitter client we did during MeeGo Summit on SF? [01:48] thomi, ping [01:48] bschaefer: yo [01:48] hey I have some Japanese test for you :) [01:48] cool! [01:49] I have 3 so far, let me double check them! [01:49] also you will need ibus-anthy [01:50] bschaefer: OK [01:51] thomi, just sent an email [01:51] Cheers, I'll add them [01:51] cool, Ill have some korean ones later also [01:51] and ill be making them for hud too [02:07] bschaefer: what does pressing Ctrl+J do? [02:13] commit text [02:13] thomi, the space switches the text [02:14] bschaefer: hmm, isn't that the same as pressing the number for the txt you want? [02:14] like "abc1"? [02:14] thomi, its an interesting way to type I would say... Korean is actually really cool. [02:14] thomi, that is a different engine [02:14] that is for pinyin only [02:14] oh ok, it's engine-specific? bummer [02:15] yup :( [02:15] that sucks [02:15] that is why its hard to make sure ALL work correctly [02:15] but we are coving the 3 big ones [02:15] also Korean doesn't have much translated for it yet... [02:18] OK. I'm going to change the tests to use python-testscenarios so we don't have to write identical tests :) [02:19] thomi, nice, the hangul engine is easier to use, just type and space is to commit [02:20] ok [02:20] we'll probably end up with a test for each engine then [02:20] Yeah, these 3 are a very good start [02:21] hmm there is also the ibus-m17n which has a lot of engines in it... [02:22] like different CJK engines [02:48] thomi, sent you 3 korean examples now as well [02:49] thank you very much! :) [02:49] awesome [02:49] these tests are going to look like... like... umm... [02:49] good [02:49] o and the korean engine is [02:50] ibus-hangul [02:50] yeah, it was fun to learn how to actually type in those languages! [03:01] bschaefer: got a second? [03:01] yup [03:02] can you please make sure you have python-testscenarios installed, grab the latest version of my branch, and make sure the ibus tests still run correctly and pass for you? [03:02] yup [03:02] and if you want a pleasant surprise, check out the new version of test_ibus.py file :) [03:02] alright :) [03:02] python rocks the casbah ;) [03:04] getting a few errors [03:04] AttributeError: 'IBusTestsPinyin' object has no attribute 'activate_input_engine' [03:04] oh nuts [03:04] I'm an idiot, hang on [03:05] bschaefer: ok, pull new version ;) [03:05] I renamed a method and forgot to update it. What a tool! [03:05] thomi, haha, and sweet! [03:06] pretty cool huh? [03:06] pulling and about to run it! [03:06] I'll do a separate test for the other two input engines you've sent me [03:07] sweet! [03:07] runs 100% [03:07] awesome [03:07] thanks [03:07] and cool, these test are looking awesome [03:07] we had to many regression when it came to ibus last cycle! [03:09] thomi, nice scenarios list! [03:09] in test_ibus.py [03:09] yeah [03:09] adding the korean and japanese ones now [03:09] thomi, I also wish there was an easy way to tell if it was active. I wonder if there is a config.get_value for that hmm [03:10] bschaefer: if you find one, please let me know - I've been looking too [03:10] will do! [03:19] bschaefer: new revision of my branch: adds hangul tests. [03:19] sweet, checking it out now [03:22] thomi, so it didn't seem to switch to ibus-hangul on my test [03:22] oooh, that's interesting [03:22] everything is in pinyin [03:22] does the order matter? [03:22] bschaefer: it should remove all the other engines [03:22] the tests only enable one engine at once [03:23] hmm only pinyin is on my active engine list [03:23] ...they also restore the engines that were installed after the test ran, so your system will be back to normal after the test completes... well, it *should* [03:23] under the korean test [03:23] haha unless you ctrl+c out of it! [03:23] ...that's true [03:23] ...I think [03:24] I'll add some logging and work it out [03:24] well I just did, and only piniyin is under active hmm [03:24] Ill tinker around a little with it! [03:25] thomi, yeah I just put hangal as the only active engine then ran the test and it switch it to pinyin only [03:25] which the korean test gets ran first [03:25] wtf? [03:25] ok, what happens if you do this: [03:26] python -m testtools.run autopilot.tests.test_ibus.IBusTestsHangul [03:26] that should run the hangul tests only [03:26] pinyin [03:26] OK. I'll look into it. [03:33] thomi, hmm weird, I just switch the call from pinyin to hangul (for the pinyin test) and it worked [03:33] OK, I wonder if ibus-daemon needs to be restarted after changing the settings [03:34] that might be it, what if instead of just loading one engine to the active list just have a list of engines you are using to have it preload them all at one [03:34] once* [03:34] what kappens if you do "killall ibus-daemon" and re-run the tests that you changed (the ones that should fail) [03:35] just got a seg fault when I killed the ibus daemon [03:35] in what? [03:35] TextEntry [03:36] OK, that's not good - we should probably fix that :) [03:36] I think it cause the code im putting into nux reach an assertion where the bus was no longer connected to the bus [03:36] yeah [03:36] nux should ideally fail gracefully if ibus dies [03:37] hmm yeah, Ill have to bring that up with Jay [03:37] it shouldn't assert but rather just return false when trying to process the event [03:37] dammit now its not connecting to ibus haha, one sec [03:38] hmmm, [03:39] ok its working again [03:40] I can reproduce the issue in the python interpreter [03:40] ibus reports the "pinyin" IME is active, but it's still using the hangul one [03:40] like it needs to be refreshed or something [03:40] yeah [03:41] as I change it to use only hangul for both pinyin and hangul [03:41] then hangul worked and now switching back to pinyin it wont load it! [03:41] but the test work for korean :) (When it is in hangul) [03:41] hmm, I really want to avoid loading all the engines at once [03:42] I can kill the ibus-daemon from python, but that'll break nux for you at the mometn [03:42] thomi, do you account for the space at the end of the korean input? [03:42] I think so, yeah [03:42] ok, let me run it again to see if it passes the check [03:42] there's a space at the end of each input string [03:43] hmm it is typing in the correct info but im getting 3 failures [03:43] Difference: u'\ubb38\uc11c' != u'\ubb38\uc11c ' [03:43] I think your check is not taking the space into consideration [03:44] like when you hit space it commits the preedit along with putting a space there [03:45] ahh, ok [03:45] I'll update the tests [03:45] just for the hangul tests, right? [03:46] yup! [03:48] thomi, Ill see what I can do about the crash in nux [03:49] ok, new revsiion available with the fixes [03:51] sweet all passed :) [03:51] bschaefer: OK, the same thing happens with ibus-setup [03:51] thomi, so ibus setup resets the ibus-daemon? [03:51] no I'm saying it doesn't [03:51] the same propblem exists [03:51] at least, for me it does [03:52] hmm [03:52] right now ibus-setup shows Korean as the only active input engine, yet when I type I still get the pinyin engine [03:53] if you restart the daemon does it fix it? [03:53] killing the ibus-daemon does fix the issue :) [03:53] yup [03:53] ok, well im going to have to fix it so nux doesn't crash on that! [03:54] it nice we caught that so early :) [03:54] its* [03:54] that sucks - surely that's an ibus bug. Do we know any ibus developers? [03:54] no its in the new code im doing for TextEntry [03:54] im pretty sure at lease, let me crash it really quick again [03:54] no I mean the fact that the engine doesn't update [03:54] o [03:55] hmm, I think im the closest to an ibus dev we have :( [03:55] we ought to fix that as well - killing the daemon just to update the active engine is a bit heavy handed [03:55] yeah [03:55] I think that is why they only have a preload-engines signal [03:55] have you looked into the ibus src code? think it's possible to get a fix in before precise? [03:56] I have dug through it, but Im not sure if I have been in that chunk of code at lease [03:57] also when you first install a new engine you have to restart the daemon to get it in the list of engines [03:57] yeah, I noticed that [03:59] hmm [04:04] thomi it might be better to submit a bug for ibus, and for now we could restart the daemon [04:04] but im not sure if they will do anything about :( [04:05] bschaefer: are they on LP? [04:05] no google code [04:05] http://code.google.com/p/ibus/ [04:05] OK, I'll submit one now [04:06] thank you! Im about to start working on this crash in nux, hopefully I can fix it soon! [04:22] thomi, haha it was actually pretty funny why it was crashing [04:23] yeah? [04:23] thomi, so there is a disconnected signal cb and for some reason it was calling Connect instead of Disconnect [04:23] so when it disconnected it was trying connect right away [04:23] whoops ;) [04:23] haha, yeah [04:24] sweet and it reconnects, alright all fixed for now :) [04:32] bschaefer: http://code.google.com/p/ibus/issues/detail?id=1418&thanks=1418&ts=1329885137 [04:33] thomi, sweet thanks! [04:34] I hope its a fixable problem [04:34] bschaefer: yeah, I may even take a look at the code myself [04:34] how hard can it be? :P [04:34] thomi, the ibus code isn't the easiest code to read haha [04:35] Ill try to take a look my self [04:41] bschaefer: if you get a chance, there's a new revision in my branch that has tests for the japanese scenario as well [04:43] thomi, I think it's anthy [04:44] unless the engine list says anthi [04:44] oh [04:44] * thomi fixes [04:45] regular expression ftw! [04:46] ok, pull now [04:46] the space for the japanese engine doesn't commit a space [04:47] Difference: u'\u30e6\u30fc\u30b6\u30fc ' != u'\u30e6\u30fc\u30b6\u30fc' [04:47] I know its annoying haha [04:47] the space switchs it to a different form [04:47] haha [04:47] ok [04:47] other then that is works like a charm ;) [04:47] and the ibus engines not switching [04:48] cool. [04:48] ok, there's a new revision without the spaces now [04:49] thomi, ok, this is an interesting merge conflict [04:49] <<<<<<< TREE [04:49] class IBusTestsAnthy(IBusTests): [04:49] """Tests for the Anthy(Japanese) input engine.""" [04:49] ======= [04:49] class IBusTestsAnthi(IBusTests): [04:49] """Tests for the Anthy(Japanese) input engine.""" [04:49] >>>>>>> MERGE-SOURCE [04:49] since i changed it myself, but cant it see its the same!! [04:50] heh, maybe do a revert before a pull [04:50] thomi, no I fixed it, just thought it was funny [04:50] delete then bzr resolve [04:50] odd [04:50] fair enough [04:50] it because I changed the source my self, then pulled your changes [04:50] from Anthi to Anthy but idk thats odd maybe a random space difference [04:52] wait I think you missed an Anthi [04:52] is why there was a conflict [04:52] or I did [04:54] thomi, http://bazaar.launchpad.net/~thomir/unity/ibus-testing/view/head:/tests/autopilot/autopilot/tests/test_ibus.py#L98 [04:54] Looks like you missed one Anthi [04:54] oh ok [04:54] ahh yep [04:54] * thomi fixes [04:55] which is why there was a merge conflict haha [04:55] ok, new revision [04:55] but everything works! [04:56] it is getting 100% of the jap mataches [04:57] cool [04:57] looking into the ibus src code [04:57] seems like there might be a way to restart the bus remotely [04:58] well in ibusbus.h there is a ibus_bus_exit which takes in an argument to restart it [04:59] bschaefer: yup, that's what I saw [04:59] I'm looking for the dbus interface spec [04:59] can you just call bus.exit(true) [04:59] cool [05:00] sorry, I saw that earlier but thought you had used to restart it when you said you could in python! [05:02] np [05:04] well, I can confirm that the bug still exists in the latest sources from google code [05:05] thats good, hopefully restarting the ibus-daemon will work for us for now [05:10] bschaefer: new revision that restarts ibus after setting the daemon [05:12] alright, so just run it from the beginning? [05:15] may as well, or maybe just the ibus tests [05:15] I'm out for the day though - talk to you tomorrow [05:15] thomi, alright [05:15] ill send you an email about anything i notice [05:16] thank you! [10:25] bug #938538 [10:25] Launchpad bug 938538 in unity (Ubuntu) "HUD: incremental search not keeping up with typing on atom netbooks" [Undecided,New] https://launchpad.net/bugs/938538 [10:36] hello all! how would i determine what's causing this white pixel to appear at (0, 0) from time to time? → http://img.xrmb2.net/images/984711.png [10:37] xwininfo on (0, 0) says it's the panel, but i'm not so sure it's coming from the panel. [10:37] htorque: bug 927441 [10:37] Launchpad bug 927441 in unity (Ubuntu Precise) "Far left character in panel (and launcher popups) distorted" [High,Confirmed] https://launchpad.net/bugs/927441 [10:37] jokerdino: no, that's not it. [10:38] oh wait, may be it is not relevant. [10:41] htorque, do you have your launcher exposing on top left or left ? [10:41] no, i disabled all hiding functions. [10:42] was wondering if it was the activation 'window' for something like that [10:42] i remember seeing this for a while, likely happens more often after unlocking/resuming the system [10:43] no way to reliably reproduce it, though. [10:43] what does xprop say about that window? [10:43] mgedmin: http://paste.ubuntu.com/852485/ [10:44] for the record, I've never seen this bug [10:45] i've seen it on both of my precise systems [10:45] * mgedmin is still on oneiric [10:46] it's easy to see with the dark panel, so i expected to find a bug report, but nothing. i just have no idea against which package i should report it. [10:47] hm, it's gone after a unity restart [10:48] screenshot? [10:48] http://img.xrmb2.net/images/984711.png [10:49] saw that one yesterday [10:51] .xsession-errors might have some debug messages maybe [10:52] could it be related to dual-head? [10:52] unity creates a separate panel window for each monitor [10:53] mgedmin: nope, just one monitor [10:53] is the window sized 1x1, according to xwininfo? [10:54] or is it just a drawing bug in the regular-sized unity panel? [10:54] according to xwininfo it's the panel [10:55] don't know if windows can hide from xwininfo [10:58] can you pastebin what xwininfo says, exactly? [11:00] the only place where I can find a "panel" string in the source code is in ./plugins/unityshell/src/PanelController.cpp [11:02] mgedmin: :-/ unfortunately i got rid of the pixel by restarting unity. i'm trying to make it reappear. [11:02] and you don't remember the window size? [11:03] the code that I can see always creates panel windows 24-pixels high and as wide as the monitor [11:03] i *think* it matched the panel size [11:03] if that window is 1x1, then either it doesn't belong to unity, or there's something very interesting going on [11:04] if it matches the panel size, then it's a drawing bug, not a window creation bug [11:04] unfortunately the internal layout of the unity panel is not introspectable with xwininfo... [11:05] I would file a bug [11:05] i will, just trying hard to find a way to reproduce it === _salem is now known as salem_ === chrisccoulson_ is now known as chrisccoulson [11:48] didrocks: ping! (about OneConf, I'm Andrea) [11:50] Andy80: hey! [11:51] Andy80: how are you? :) [11:51] didrocks: I'm fine thanks, you? :) [11:51] Andy80: I'm good :) [11:52] Andy80: so, do you volonteer to help in getting some data syncing stuff for P+1? ;) [11:53] it's something I didn't implement yet on OneConf (just did package syncing) due to lack of time mainly [11:53] didrocks: I surely have time and willing to help, let's see if I also have the knowledge to do it :P [11:55] Andy80: heh, do you code in any particular language? [11:55] didrocks: where are the actual sourced of OneConf? and where I can find more documentation about its state? [11:55] Andy80: lp:oneconf [11:55] Andy80: it's included by default in ubuntu [11:55] integrated with software-center [11:55] didrocks: (in order of better knowledge ---> worst): C++, Python, C#, Java, C [11:55] ("share between computers") [11:55] ok ;) [11:56] so data setting sync are different than package syncing [11:56] my thought was that most of the data we want to sync [11:56] are stored in dconf [11:56] so maybe, we can try to have a look how to interact with dconf-service [11:56] and pushing that to ubuntu one [11:56] (so different from the package syncing service) [11:57] didrocks: but, how the service works? I mean... the daemon run in background, reads from ubuntu-one shared folder and writes data to d-conf? [11:58] Andy80: the settings syncing is not in OneConf yet, but that was the plan [11:58] Andy80: right now, oneconf-service is only about package sharing [11:58] (which is what is in ubuntu for 2 cycles) [11:59] didrocks: ok, we have to define an architecture anyway ;) [11:59] I think we need another approach for the data settings sharing [11:59] right [11:59] so, we have this dconf-service [11:59] which is already running [11:59] and have all the needing info [11:59] upstream is really friendly to us, I think we can discuss with him how we can integrate that to u1 [12:00] the idea will be to "watch for some key and trigger an external syncing" and checking regularly on u1 the changes [12:00] Andy80: the right place to discuss that is at UDS, did you plan to come? === MacSlow is now known as MacSlow|lunch [12:06] didrocks: ok, coming back to oneconf and dconf-service. The dconf-service is an existing service that is currently used by applications to save their settings or is it a specific component of oneconf? [12:07] Andy80: no, dconf-service is the new "gconf" (a place to store settings) [12:08] ah ok, so it's the same I already gave a look to [12:08] you said that we can trigger settings changes, right? [12:10] if yes, the settings part is correctly watched. Now, since I don't know ubuntu-one API, I suppose there is already a FileWatcher API or similar? To detect if a file changed.... [12:21] Andy80: sorry, was in a discussion :) [12:21] Andy80: so, there are two way to accomplish this [12:21] Andy80: either putting that one files [12:21] Andy80: or using the new shiny API to only sync what we need :) [12:21] (like data) [12:21] I'll talk with them for that [12:22] didrocks: about the "new shiny API" you're talkng about Ubuntu One? [12:22] Andy80: yeah, they changed it recently [12:22] So two parts: - I would say, discussing with dconf upstream how to plug that in dconf-service [12:22] didrocks: ok, never used that API, so I'll give a look to the documentation today [12:22] - Look at how we can get the other way around with the u1 :) [12:22] Andy80: yeah, it's a good start [12:23] Andy80: sorry, nowdays, I don't have the time to look at P+1, I try to focus on the LTS :) [12:23] but as soon as we are a little bit further in the cycle, we can really start preparing that together :) [12:23] didrocks: after these two parts are ready, we need a UI to let the user choose what they wanna sync [12:24] Andy80: this should be in gnome-control-center I think [12:24] Andy80: the ui is not the real issue I guess :) [12:24] didrocks: a little thing I need is that you can explain me "which class is used for" in oneconf sources: http://bazaar.launchpad.net/~ubuntu-desktop/oneconf/trunk/files/head:/oneconf/ [12:25] didrocks: I was just giving a look at it but I cannot understand everything [12:25] Andy80: the oneconf only contains right now the package syncing [12:26] Andy80: so, not really relevant to what we try to do here, as it's more "plugin" for dconf-service [12:26] Andy80, found it: http://wiki.meego.com/QtWorkshop/TeamSirloin [12:26] Saviq: cool! [12:26] Andy80, you're not on the team list, though [12:27] Saviq: exactly, but yesterday I did need a very basic example of a twitter client to understand some things and that example came into my mind [12:30] the colour in the dash and all other launcher componants with has updated in 5.4 unity how can i enable it it need any further package to instal ? [12:30] Andy80, cool, hope it helps, it's majorly basic, though :) [12:30] didrocks: with "plugin for dconf-service" you mean that rather than watching the oneconf source code I should give a look to the dconf-service docs? [12:30] Andy80: exactly [12:30] Andy80: it's dconf on gnome infra [12:31] Saviq: well, at the end I did something completly different using ListView/TwitterDelegate and a TwitterModel that uses XmlListModel class [12:31] Andy80, probably the more QML way [12:33] didrocks: you did read the Stuart Langridge's comment on my blog post? Do you thik we should coordinate with him? [12:33] didrocks: this is the comment I'm talking about http://www.andreagrandi.it/2012/02/21/ubuntu-syncronizing-settings-among-multiple-pc-using-ubuntu-one/#comment-77058 [12:34] Andy80: totally, anyway, I already needed to speak with him :) [12:36] didrocks: perfect, so... for today I read ubuntu-one docs and dconf-service docs and I try to use some API, just to take confidence with them (is it ok if we do this in Python? Long time I don't use it, but I love using it :) ) [12:36] didrocks: but since it's your "pet" you have right to decide which language to use ;) [12:37] Andy80: I'm afradi that the dconf-service binding will need some C foo :) [12:37] as we try to not have another daemon [12:39] ouch :\ I'm good with C like Paris Hilton is good at not spending money :P but I can give a look, don't worry ;) [12:40] Andy80: do not hesitate if you have any question! :) [12:42] ok, so: dconf-service docs, ubuntu-one docs and all in C. Let's start! :) [12:45] * Andy80 well... lunch first :P [12:52] :) [12:52] good morning [12:52] didrocks: did you send me an MP? [12:54] oh nvm, I see it in my inbox now [12:55] mhall119: hey [12:55] mhall119: my package is in :-) [12:55] ;) [13:00] bug #938643 [13:00] Launchpad bug 938643 in unity (Ubuntu) "HUD: keyboard focus is not returned to the original window after menu item is selected" [Undecided,New] https://launchpad.net/bugs/938643 [13:00] gotwig: in where? [13:00] bug #938538 [13:01] Launchpad bug 938538 in unity (Ubuntu) "HUD: incremental search not keeping up with typing on atom netbooks" [Undecided,New] https://launchpad.net/bugs/938538 [13:01] didrocks, i've filed a couple of HUD bugs, could you check they are on the right package pls [13:01] apw: looking [13:02] apw: bug #938643 is a dup of a bug I already set on the priority list [13:02] Launchpad bug 938643 in unity (Ubuntu) "HUD: keyboard focus is not returned to the original window after menu item is selected" [Undecided,New] https://launchpad.net/bugs/938643 [13:03] didrocks, cool, the duplicate finder never seems to find my duplicates ... sigh [13:03] apw: yeah, you are not alone in that situation :/ [13:03] apw: the second, I reassign as it's only backend to indicator-appmenu [13:03] didrocks, i suspect its my peculiar way of using words when i write [13:04] cool [13:04] apw: bug #934061 [13:04] Launchpad bug 934061 in unity (Ubuntu) "doesn't give the focus back to the active application after dash/hud use" [High,Triaged] https://launchpad.net/bugs/934061 [13:04] I'm dupping :) [13:05] thanks [13:05] yw ;) [13:06] davidcalle, ping? [13:06] davidcalle, the video lens is using remote scopes, right? [13:06] mhr3, one remote scope, yes [13:07] davidcalle, how is the process called? [13:07]