=== Ursinha-afk is now known as Ursinha [04:57] Good morning [07:43] good morning [07:46] good morning [07:48] bonjour jibel [07:49] bonjour pitti === jibel_ is now known as jibel === yofel_ is now known as yofel [12:45] i'm trying to do upgrade tests for xubuntu, but i have problems installing Q... === _salem is now known as salem_ === fader_` is now known as fader_ [15:35] HELP FOR TESTING: Someone please test the Lubuntu images...... [15:40] smartboyhw: no need, I'm content enough. We have a PPC iso available. that is always our 'night mare' :) [15:40] phillw, LOL [15:40] * balloons lubuntu iso is only 20% dl'd [15:40] phillw, just why don't you guys drop powerpc? [15:40] Really wondering [15:41] Every time when I package KDE SC apps the powerpc builds slows down or breaks everything... [15:41] smartboyhw: coz we're the only ones dedicated to supporting it :) [15:41] lubuntu is the last bastion of support for such things [15:42] balloons, you're getting ready for a fistfight......:P [15:42] powerpc often builds faster than arm these days [15:42] well, except when sagari is down as it currently is [15:42] cjohnston, not for me that is [15:43] * cjwatson goes to ask about that [15:43] I am NOT cjohnston. 1 2 3 tab [15:43] 1 + 2 + 3 + tab [15:43] BAH forgotten that again [15:43] * smartboyhw bangs himself [15:46] I'm assuming that the arm team were not taking part in beta 1. But, the arm image under lubuntu is still under their team :) [15:46] phillw, really? [15:47] smartboyhw: indeed, they are the only ones with the kit to test it :) [15:47] phillw, grr:P [15:47] phillw, ask in #ubuntu-arm [15:47] no need, they are quite organised and have their release schedule. [15:48] phillw, anyway that's just it:P [15:48] We don't have much to do [15:49] phillw, upgrade testcases? [15:49] that's beta 2 stuff :) [15:50] lol [19:38] thomi, you about? [19:39] balloons: just about to go to lunch - can I talk to you when I get back? [19:39] sure thing [19:39] enjoy [19:39] thanks [20:49] balloons: I'm back now, what's up? [20:49] thomi, well a couple things [20:49] we'll start easy ;-) [20:49] \o/ [20:49] are you about next tuesday ? [20:49] in between March 19th 1200 UTC - 2300 UTC somewhere's? [20:50] uhhh [20:50] * thomi thinks [20:52] balloons: it looks to me like 20:00 - 23:00 on that date would be within my working day [20:52] Wednesday morning for me I guess [20:52] yes, indeed [20:52] I wonder if I should roll it a bit later than that even.. [20:52] I should tell you what I'm talking about :-) [20:53] in the past, we've had some hackfest sessions.. get people together to write tests [20:53] well, I'm planning another one of those sessions, with some tweaks [20:53] and we're going to include manual testing this time [20:54] I didn't like picking the full day, so I thought I'd try a 12 hour window where yourself, me, martin, jean-baptiste, daniel, and everyone else, could all be around during (at some point of course) [20:54] hey Letozaf_ and Noskcaj [20:54] balloons: sounds good [20:54] hello balloons [20:55] but... autopilot isn;t "manual testing" [20:55] did you mena "automated testing?" [20:55] balloons, Hi :D [20:55] since your online, what do you think of March 19th 1200 UTC - 2300 UTC as the timeframe for the hackfest? [20:55] thomi, yes it would be manual and automated testing [20:55] ahh ok [20:55] any test contribution :-) [20:55] autopilot, autopkg, manual [20:55] right [20:55] sounds fine by me, i would be able to be online for the end of it [20:56] the other question I have is about autopilot itself, but i'll hold it for a moment [20:56] since I siderailed this [20:56] balloons: so Marth 19th sounds doabl. I think it might be a good idea to see if veebers, alesage and mzanetti would be interested in joining [20:57] hmm.. well your pings I'm guessing will alert them [20:57] I'm sorry, I left you and friends off the mail completely when I asked [20:58] balloons, for me March 19th would be fine I can be on line at about 2000 UTC [20:58] balloons: heh, no worries [20:59] should we slide back the timeframe at all? I didn't want to roll over the day in order to not confuse people :-) [20:59] hence I ended at 2300 [21:00] if not, I'll send the mail about it to the list, see what everyone thinks and probably stamp it official [21:00] thanks for the feedback all :-) [21:00] ok, so thomi the other question I had was about autopilot.. specifically I'm getting some lovely dbus warnings [21:02] * balloons tries to find the error again [21:02] essentially it stemmed from using the get_all_instances class in dbus [21:02] a warning about how slow it was.. and indeed, I did several calls in a row and kind of killed the test [21:03] ahh.. here's an example [21:03] 17:01:53.574 WARNING dbus:133 - Constructing object 'GeditWindow' without path information. This will make queries on this object, and all child objects considerably slower. [21:03] 17:01:53.574 WARNING dbus:135 - To avoid this, make sure objects are _not_ constructed with the get_all_instances(...) class method. [21:03] now, I'm of course using select_single and select_many [21:04] so a few things.. in general, I actually know the full path from my objects.. i could specify it, but I don't see how given those 2 calls [21:05] (I did poke in dbus.py a bit and found some interesting stuff about traversing the tree, or grabbing root nodes, etc) [21:05] balloons: yeah... there's a bit of a problem with autopilot right now in that regard. [21:05] essentially we need to change the DBus wire protocol to make it more performant [21:05] ok, so this is a known thing then? if so, I'll shut up about it ;-) [21:05] balloons: as a workaround, I recommend you use get_children_by_type multiple times to traverse the tree. [21:06] thomi, hmm.. ok [21:06] balloons: I realise it's ugly, but I'm looking at fixing this real soon [21:06] * balloons notes I'm always bugging thomi right before he fixes things [21:06] balloons: if you hide that code behind a 'get_foo_widget' method, then when autopilot gets support for more elegant selectors you can swap out the ugly code for the good stuff [21:07] ok.. I think we can maneuver around for know.. The second question is about focus control [21:08] so, when I'm using introspection i feel like I lost some of the control I had over the window (since I don't get the xid anymore), as well as knowing what's focused, and how to direct my focus [21:08] aka, when I type something it's a blind assumption on where the text is landing [21:09] that's actually a bigger problem than the other one.. aside from doing some ugly things, I was hoping you might have an insight into reining this in [21:10] balloons: hmmmmm [21:10] balloons: it seems like ideally the UI toolkit would have a 'widget_is_focused' property [21:10] I *think* Qt has something like this? [21:11] in which case you can add a 'self.assertThat(mywidget.is_ficused, Eventually(Equals(True))) [21:11] * balloons notes if it does, he'll just switch to writing qt autopilot only.. haha [21:11] balloons: I'm not saying that Gtk doesn't, I just don't know anything about Gtk at all :-/ [21:11] perhaps charles will know? [21:11] thomi, yea.. being able to assert is good.. but also, I'd like to see something like [21:12] self.mouse.focus(object) [21:12] or something.. clicking a label, text field.. something [21:12] i suppose realistically we just manipulate the data stream [21:13] but gtk isn't nice in that way etheir [21:13] balloons: you could do that, but it seems like something's wrong if your app doesn't focus the correct window when it should [21:13] thomi, well it's a timing thing atm.. [21:13] for example, I have a routine to save a file in an app.. generate a tmp file name, click the save button and type it in [21:14] balloons: ahhhh, so if you had a way of asserting window focus, that would solve the timing issue, right? [21:14] how am I to "know" when the window appears (the save window).. and I have to assume it gets proper focus as well [21:14] thomi, yes it would go a long way.. [21:14] the other assumption on focus we can just continue to ignore/assume for now [21:15] I'd rather have more fine control, but it doesn't break things (till it does, haha!) [21:15] balloons: yeah, I agree that's a problem. We should look into a solution. This is probably something we should bring up at the next autopilot planning meeting [21:16] on the unity tests side.. does this come up for you at all? [21:16] I know timing was a big deal at one point [21:17] balloons: yeah, we had timing issues, but most of them were solved by explicitly asserting that the window was present [21:17] I've found that you can almost always get autopilot to wait for what you want, you just need to find the correct assertion :) [21:17] ah.. no subwindow issues, etc? I mean, I miss some of the bamf stuff on the introspection side of things [21:18] yes, if you think a little, usually there's a slick way to make ap do it :-) [21:24] balloons: yeah. A lot of this stuff needs to go into the new FAQ section of the documentation [21:24] balloons: which, BTW, would be a great place for community members to contribute to autopilot ;P [21:24] :-) [21:41] balloons: I'm trusting that only ubuntu-kylin and ubuntu-gnome are the ones approved for 13.04? :) [21:41] phillw, ? [21:41] you mean flavor wise? [21:41] yes [21:41] *new* flavor wise :) [21:43] ahh.. indeed [21:47] ta, just updating my mirror server for new comers :) === salem_ is now known as _salem