[00:51] <tgm4883> When installing a new scope, how do I tell dbus that there is a new scope without having to reboot? (in packaging)
[00:57] <jo-erlend> I thought it was the scope that made the connection?
[00:58] <jo-erlend> forget that. I'm tired. :)
[00:59] <tgm4883> so the issue is that it installs just fine, but I have to reboot the machine in order for stuff to show up when searching
[00:59] <tgm4883> indicating that dbus doesn't know it exists
[00:59] <jo-erlend> certainly not reboot? A logout and back in must be sufficient?
[01:00] <tgm4883> nope
[01:00] <tgm4883> well, I did a quick test, it might have been searching
[01:00] <jo-erlend> sounds strange. It runs on the session bus as the local user?
[01:01] <tgm4883> um, sure?
[01:02] <tgm4883> IDK, it's my first time really playing with dbus stuff
[01:02] <tgm4883> I'm just creating a scope for the videos lens for MythTV
[01:03] <tgm4883> which works great, although I had to monkey around with some stuff since it doesn't seem unity supports episodic content too well
[01:15] <jo-erlend> no, I'm not sure.
[01:16] <jo-erlend> tgm4883, what do you mean Unity doesn't support episodic content?
[01:17] <tgm4883> so pushing things into the videos lens, there isn''t a good way to display episodic content. Basically I had to stuff NameSeasonEpisode into the name field
[01:17] <mhall119> jo-erlend: I think he means heirarchical data
[01:17] <jo-erlend> right.
[01:17] <tgm4883> it works fine for Unity, since it's searching, but will need fixed when UTV rolls out
[01:17] <mhall119> Unity results are very flast
[01:17] <mhall119> flat
[01:18] <tgm4883> yes
[01:18] <jo-erlend> the Video lens could easily support Season categories though?
[01:19] <mhall119> jo-erlend: you'd have to be able to drill down
[01:19] <tgm4883> heh, categories are another pet peeve of mine
[01:19] <jo-erlend> what does that mean?
[01:19] <tgm4883> I'm not sure they would work so well for episodic content
[01:19] <tgm4883> you mean have a category for "season 1"?
[01:19] <mhall119> pick "Show A" and get "Season 1, Season 2, Season 3".  Pick "Season 1" and get "Episode Z, Episode Y, Episode X, etc"
[01:20] <mhall119> like a directory tree
[01:20] <mhall119> you can't do that with flat results
[01:20] <tgm4883> that would be the usual way of looking at episodic content
[01:20] <jo-erlend> it would show all episodes for Season 1, regardless of series.
[01:21] <tgm4883> yea that would be kinda strange I think
[01:21] <mhall119> that's a hard way to find an episode
[01:21] <jo-erlend> sure. It would work though. Not saying it'd be optimal. :)
[01:21] <jo-erlend> but while we're at the subject.. Is the unity-tv thing available for install yet?
[01:22] <mhall119> it wasn't a functional thing
[01:22] <mhall119> just a mockup app
[01:22] <tgm4883> it's completely made up
[01:22] <mhall119> it didn't even use Dash, it was just made to look like it
[01:22] <tgm4883> like europe ;)
[01:23] <jo-erlend> oh.
[01:24] <tgm4883> Categories aren't great right now as you have to look in the lens source to see whats available
[01:24] <jo-erlend> Damn. I wish Canonical would be better at communicating things like that better. I've made a fool of myself showing this to people. I never got the impression it wasn't real. And now I have to wonder if Ubuntu for Android is also just a mockup?
[01:25] <tgm4883> If the scope could create categories, that would be better IMO
[01:25] <mhall119> tgm4883: the lens author could always provide documentation
[01:25] <mhall119> tgm4883: it would be messy though
[01:25] <tgm4883> mhall119, who is the author of the videos lens?
[01:25] <tgm4883> mhall119, yea it would
[01:25] <mhall119> tgm4883: davidcalle I believe
[01:26] <tgm4883> yea looks like he is the maintainer
[01:26] <mhall119> the good thing about the current categories is that they're always the same, no matter what scopes you install
[01:26] <mhall119> installing a scope should just give more results, not change the user experience
[01:27] <tgm4883> mhall119, I'll agree with that
[01:27] <tgm4883> a better solution is to fix the categories, there are only 4 right?
[01:27] <tgm4883> online, local, remote, ???
[01:28] <tgm4883> I'd like a recorded/dvr category
[01:28] <mhall119> I see "recent", "my videos" and "online" as categories
[01:28] <mhall119> I think "recorded" might be a good category
[01:28] <mhall119> or "downloaded"
[01:29] <mhall119> same thing, different ways of doing it
[01:29] <tgm4883> yea
[01:29] <tgm4883> downloaded and recorded
[01:29] <tgm4883> two new categories
[01:30] <tgm4883> mhall119, do the categories only exist for videos, or do they also have to work for music as well
[01:37] <mhall119> tgm4883: they are per-lens
[01:37] <mhall119> so the music lens has it's own set of categories
[01:37] <tgm4883> ok that makes sense
[01:37] <tgm4883> then no reason not to add these I say
[01:37] <mhall119> why would downloaded and recorded be separate categories?
[01:38] <mhall119> the both mean the same thing "Something that was available from somewhere else, and is now available locally"
[01:38] <tgm4883> perhaps
[01:38] <tgm4883> but the MythTV stuff isn't local to the machine
[01:38] <tgm4883> it's still on the backend
[01:38] <tgm4883> as would any other DVR backend
[01:38] <mhall119> local to the network then
[01:39] <tgm4883> ok, but still not downloaded
[01:39] <mhall119> you don't have to fetch it from the internet or broadcast
[01:39] <mhall119> downloaded to the backend
[01:39] <mhall119> I would consider the backend "local"
[01:39] <mhall119> tgm4883: maybe the category should be "Shows"
[01:40] <mhall119> that way it can be local or remote
[01:40] <tgm4883> I think downloaded and recorded are fundamentally different enough to warrant different catagories
[01:40] <mhall119> tgm4883: are they different enough from a user's intent?
[01:40] <tgm4883> I believe so
[01:40] <tgm4883> actually, I'm not sure you even need downloaded
[01:40] <mhall119> do you approach it thinking "Do I want to watch something recorded, or something downloaded?"
[01:40] <tgm4883> I want to watch a show :)
[01:41] <mhall119> then make the category "Shows"
[01:41] <mhall119> doesn't matter where they live
[01:41] <tgm4883> hmm
[01:42] <tgm4883> perhaps Local is the better spot for it
[01:42] <mhall119> I think "Shows" and "Movies" would be good categories
[01:42] <tgm4883> I agree with that
[01:42] <tgm4883> Shows and Movies
[01:46] <tgm4883> mhall119, should I be filing bugs against unity for the videos scope, or is there a better place?
[01:50] <mhall119> against the video lens
[01:51] <mhall119> https://launchpad.net/unity-lens-videos
[01:58] <tgm4883> !bug 984507
[01:58] <tgm4883> thanks mhall119
[01:58] <mhall119> np
[04:47] <bschaefer> thomi, ping, or more or less to confirm you new changes to the ibus branch
[04:47] <bschaefer> Ran 32 tests in 270.267s
[04:47] <bschaefer> OK
[04:47] <bschaefer> :)
[04:48] <thomi> bschaefer: hey
[04:48] <thomi> I was looking for you
[04:48] <bschaefer> sorry, was in class
[04:48] <bschaefer> for 3 hours, now im back haha
[04:48] <thomi> no worries - could I get you to review some branches?
[04:48] <bschaefer> sure!
[04:49] <thomi> cheers :)
[04:51] <bschaefer> any branch in particular or all the ap ones you pushed?
[04:52] <thomi> bschaefer: if you have time - all the AP ones
[04:53] <thomi> lots of them were approved, then I pushed more revisions
[04:53] <bschaefer> alright! Yeah I do, I spent this morning confirming the mem leaks I was looking at the last couple days gone
[04:53] <bschaefer> so reviewing for a little would be a nice change of pace haha
[04:54] <thomi> Sweet, I need to head out for a bit. WIll be back later though
[04:54] <thomi> talk to you later :)
[04:54] <bschaefer> alright cool! Ill be running this ap test after I review the code, so it might take a litte haha
[04:54] <bschaefer> yup
[05:41] <davidcalle> tgm4883, ping
[05:55] <tgm4883> davidcalle, pong
[05:56] <davidcalle> tgm4883, nice scope :)
[05:56] <tgm4883> thanks
[05:56] <davidcalle> tgm4883, I've just answered your bug. I think I could push something for you in 12.04.1.
[05:57] <tgm4883> that would be awesome
[06:00] <thomi> bschaefer: I'm back
[06:00] <thomi> only one branch left - well done! https://code.launchpad.net/~thomir/unity/ibus-test-to-wait_for-feature/+merge/102236
[06:03] <bschaefer> thomi, I need to review the hud one, but it crashed, then I saw your branch to fix that haha
[06:03] <bschaefer> and was about to look at it
[06:04] <bschaefer> and no problem! These ap test are look nice!
[06:04] <thomi> :)
[06:04] <bschaefer> but forgot to re approve the ibus test, done
[06:04] <thomi> cheers!
[06:05] <bschaefer> thomi, wait are you working on the ap hud crash atm?
[06:06] <bschaefer> thomi, cause I see one that isn't proposed and one branch that is suspended
[06:06] <thomi> bschaefer: I'm not sure what you mean by the hud crash
[06:06] <didrocks> thomi: nice work on all the AP stuff! :)
[06:06] <bschaefer> https://code.launchpad.net/~thomir/unity/ap-hud-crashing
[06:06] <didrocks> I didn't get the chance enough to tell you that ;)
[06:06] <thomi> didrocks: thanks - any chance we can get the merge bot fixed? It's filling me with rage :(
[06:06] <didrocks> thomi: the pre-dependency issue?
[06:06] <thomi> it doesn't handle prerequisite branches well at all
[06:06] <thomi> yeah
[06:07] <didrocks> thomi: do you have a test case? you are the only one triggering it. I have some tests for prerequisite and when both branches are approved, I don't reproduce the issue
[06:07] <thomi> did yeah I know what' shappening
[06:07] <didrocks> thomi: so, really interested in knowing what exactly triggers it :)
[06:07] <didrocks> thomi: if you can decypher any pattern, I would be interested
[06:08] <bschaefer> thomi, because I got this crash while running the hud ap test
[06:08] <bschaefer> http://paste.ubuntu.com/935041/
[06:08] <thomi> The merge bot doesn't merge a branch while it's prerequisite branch isn't merged (so far so good), but once the prerequisite branch is merged, the MP dissapears, and the merge bot gets stuck because it can't find a MP for the listed prerequisite branch
[06:09] <thomi> bschaefer: running unity trunk? There was a problem, but gord fixed it
[06:09] <didrocks> thomi: ah, so you mean, master branch merged, and dependency branch just approved?
[06:09] <bschaefer> thomi, oo, cool must have not pull that version when I pull your branch
[06:09] <didrocks> thomi: if you are interested, we can have a look together at the pre-sprint, wdyt?
[06:09] <thomi> didrocks: that'd be cool. I can probably come up with a test case before then
[06:10] <didrocks> thomi: because I tested that case IIRC and didn't trigger the issue either. There is clearly something wrong, we just need to find what :)
[06:10] <didrocks> thomi: thanks ;)
[06:10] <thomi> no, thank *you* :)
[06:22] <bschaefer> thomi, hmm a hud ap test is failing but when I check it manually it passes
[06:22] <thomi> bschaefer: which one?
[06:22] <bschaefer> i mean manually like I try it and it works
[06:22] <bschaefer> def test_hud_to_dash_disabled_alt_f1(self)
[06:22] <bschaefer> AssertionError: True != dbus.Boolean(False, variant_level=1)
[06:22] <thomi> .... that's interesting, how does it fail?
[06:22] <bschaefer> let me run it on its own
[06:23] <bschaefer> because the code looks fine...
[06:23] <thomi> timing issue possibly? Maybe we need a wait_for somewhere in an emulator
[06:24] <bschaefer> oo the dash doesn't close!
[06:25] <bschaefer> http://paste.ubuntu.com/935053/
[06:25] <bschaefer> the whole stack trace
[06:25] <thomi> ahhh
[06:26] <thomi> that's my fauly
[06:26] <thomi> *fault
[06:26] <thomi> you can't use the launcher emulator in that test
[06:26] <thomi> you need to use the keybindings
[06:26] <thomi> since we don't expect it to work
[06:26] <bschaefer> oo
[06:26] <thomi> can you change it please?
[06:26] <bschaefer> can I push it on your branch?
[06:27]  * thomi is eating dinner and watching pycon talks :)
[06:27] <bschaefer> o haha, yeah, let me look those keybindings up!
[06:27] <thomi> bschaefer: nah, just make a new MP
[06:28] <bschaefer> ok
[06:35] <bschaefer> thomi, dammit I just found a  bug, un related to the ap tests
[06:35] <bschaefer> well not dammit
[06:35] <bschaefer> haha good, but Im surprised it hasn't been found. If you go from hud then to dash then exit you don't get window focus back
[06:37] <thomi> bschaefer: I think there's tests for that
[06:38] <bschaefer> hmm, really? That one wasn't failing for me...
[06:38] <didrocks> thomi: on the "no commit specified", please blame thumper who asked for this check ;)
[06:38] <bschaefer> the 2 that were failing were because the launcher thing
[06:38] <bschaefer> thomi, Ill check if there is an ap test for it
[06:38] <bschaefer> after I push this branch
[06:46] <bschaefer> thomi, https://code.launchpad.net/~unity-team/unity/hud-tests-to-wait/+merge/102440 (I forgot the _for after wait)
[06:46] <bschaefer> the diff should be done soon
[06:46]  * thomi looks
[06:47] <bschaefer> it saved 2 more lines of code
[06:47] <bschaefer> http://bazaar.launchpad.net/~unity-team/unity/hud-tests-to-wait/revision/2249
[06:47] <bschaefer> easier to see
[06:48] <thomi> bschaefer: so that branch superceeds mine?
[06:48] <bschaefer> yeah
[06:48] <bschaefer> thats what you wanted isn't it?
[06:48] <bschaefer> or do you want to me do just make a side branch?
[06:49] <bschaefer> yeah, I think I messed that one up haha. Let me make a new branch...and Ill delete that one
[06:49] <thomi> bschaefer: not hat's fine,
[06:49] <thomi> I'm asking if you replaced my MP (you probably should)
[06:49] <bschaefer> no, I didn
[06:49] <bschaefer> didn't
[06:50] <bschaefer> I just put it against unity, because I've never had to merge it to a different back
[06:50] <thomi> ok, if you just click 'resubmit' on my MP for that branch and list your own
[06:51] <thomi> ...as the source branch then we avoid conflicts
[06:51] <bschaefer> yeah
[06:51] <bschaefer> I soon as you said that I realized what other open was for in the mp process
[06:51] <bschaefer> haha
[06:53] <bschaefer> thomi, wait, it already is the source, and the target branch should be pointed at your branch?
[06:53] <thomi> no... target should be lp:unity
[06:53] <thomi> actually, I'll just delet my MP - much simpler :)
[06:53] <bschaefer> ok then I was just confused from something, it should be ready already
[06:54] <thomi> cool.
[06:55] <thomi> bschaefer: I just approved it... seems a bit cheeky as it's still mostly my code, but you approved mine, so we're safe :)
[06:55] <bschaefer> thomi, I was thinking it would be cool if I could just merge a change into your branch you made, so you would approve of any of someone elses changes
[06:55] <bschaefer> yup :
[06:55] <thomi> bschaefer: we could have done that.
[06:55] <bschaefer> :)
[06:56] <bschaefer> o well to late haha, that is what I thought you were asking haha
[06:56] <bschaefer> but when I tried to put your branch as a target it couldn't find it :(
[06:57] <thomi> ahh well
[06:57] <bschaefer> well it's all fixed, and I should make dinner (as my I had a very very late lunch)
[06:57] <bschaefer> as I*
[06:58] <bschaefer> thomi, do you need any thing else reviewed?
[06:58] <thomi> bschaefer: no thanks, I'm just trying to get everything merged now :)
[06:58] <bschaefer> nice, don't forget commit messages!
[06:58] <bschaefer> Ill also check if that ap test there for the hud to dash then window focus
[06:59] <bschaefer> else Ill report that bug...
[06:59] <bschaefer> and most likely work on it tomorrow haha. Have a good night!
[07:01] <thomi> cheers, you too!
[07:36] <didrocks> thomi: in most of the case, the rejection is because in those case is because the parent branch got rejected (no commit message) and so not approved, rejecting the child one then
[07:37] <thomi> didrocks: yeah I saw those too.
[07:37] <thomi> didrocks: let's look at it in SF
[07:37] <didrocks> thomi: but I know there is a wrong case as well, that's the one we need to debug ;)
[07:37] <didrocks> in this case, the rejection are "normal" :)
[07:38] <thomi> didrocks: for some of them, yeah. I forgot a bunch of commit messages
[07:39] <thomi> for a few others however, there was a commit message, but it got the other problem.
[07:50] <malin> davidcalle: this http://pastebin.com/DCN8TC9G gives this error:
[07:50] <malin>   File "/usr/lib/unity-lens-buss/buss", line 82
[07:50] <malin>     results_list.reverse ()
[07:50] <malin>                ^
[07:50] <malin> SyntaxError: invalid syntax
[07:53] <davidcalle> malin, because your line 71 is not correctly closed, it misses a bracket : results_list.append(test(full_url,patjunk)
[07:54] <davidcalle> malin, and don't reverse the model, it will fail. (l 83)
[07:54] <malin> ah
[07:54] <thomi> bschaefer: you have conflicts on your hud branch...
[07:54] <malin> so If I reverse that, it wil reverse the text instead?
[07:54]  * thomi -> EOD. Talk to you tomorrow maybe
[07:55] <davidcalle> malin, I don't understand what you mean.
[07:56] <malin> I could ask another way. What exactely will fail, and how :)
[07:56] <malin> I added a : to the end of results_ists.append(test(full_url,patjunk):
[07:56] <malin> so it looks like that, but still it gives syntax error
[07:57] <malin> ah, okey. I removed the reversing of the model. Indeed that dosen't sounds right :)
[07:58] <davidcalle> malin, no, the syntax issue you have is because of a missing ")" You need to do "results_lists.append(test(full_url,patjunk))"
[07:58] <malin> of corse :S
[07:58] <malin> how could I forget, when I belived I did :p
[08:02] <malin> davidcalle: http://pastebin.com/NvMyUJKJ
[08:05] <davidcalle> malin, model = search.props.results_model
[08:05] <malin> ah, so that one shouldn't be changed? :)
[08:06] <davidcalle> malin, never ever :)
[08:06] <malin> oki :)
[08:09] <malin> in model.append(and things in here)  should I change test(full_url,patjunk)  with results_list   ?
[08:09] <malin> looks like it don't like it
[08:15] <davidcalle> malin, if it's a list you have to iterate over it: http://paste.ubuntu.com/935120/
[08:16] <malin> ah, so I actually need a for-loop :) I see
[08:16] <malin> but where do the result comes from,  I can't remember having such a variabel
[08:16] <davidcalle> malin, yeah, because each model.append is a single dash result.
[08:17] <davidcalle> result is a variable the loop creates for each element in results_list
[08:17] <malin> yeah, I see. it's made after the for :)
[08:17] <malin> then I understand
[08:17] <davidcalle> for number in [1, 2, 3, 4, 5]:
[08:17] <davidcalle>     print number
[08:18] <malin> yeah, and then it wil print all numbers from one to five
[08:18] <davidcalle> malin, yep
[08:18] <malin> in java it would be something like: for (int i = 0; i <= 5; i ++) {
[08:18] <malin> system.out.println(i)
[08:18] <malin> }
[08:18] <malin> ish
[08:18] <davidcalle> malin, that's why I love Python :)
[08:19] <malin> I can understand that......
[08:19] <malin> I learn java at school
[08:20] <malin> is it possible to do like this in python?
[08:20] <malin> for number in number <= 500:
[08:20] <malin> to get all numbers from zero to 500?
[08:20] <davidcalle> malin, yes
[08:20] <malin> nice
[08:21] <malin> in fact it semce easier, but java is faster
[08:21] <malin> *looks easier
[08:21] <davidcalle> i = 0
[08:21] <malin> yeah
[08:21] <davidcalle> while (i < 500):
[08:21] <davidcalle>     i = i + 1
[08:22] <davidcalle>     print i
[08:22] <davidcalle> Not exactly the same spirit as java, but yes, it's very easy to read and understand.
[08:23] <malin> the lense works again, but the results isn't present in reverse order :)
[08:24] <davidcalle> malin, what do you see when you print results_list ?
[08:25] <rye> hello, may I poke somebody with compiz knowledge about bug #946388, and especially my last comment with a vala test code which exhibits the same behavior?
[08:25]  * davidcalle needs coffee and cigarette, back in 10 min
[08:26] <malin> davidcalle: first it print the first result again
[08:27] <mhr3> davidcalle, for x in xrange(500) ;)
[08:27] <malin> davidcalle: it prints like this: http://paste.ubuntu.com/935133/
[08:33] <davidcalle> mhr3, sure, but it was to show the basic structure of loops :)
[08:34] <gord> rye, duflu here may be able to help :)
[08:34]  * duflu looks at the bug
[08:34] <duflu> Hi rye
[08:35] <davidcalle> malin, it's the result of only one search?
[08:35] <rye> duflu: hello!
[08:36] <duflu> rye: I'm still getting up to speed on the bug, and multitasking :)
[08:37] <malin> davidcalle: it's the result after two search
[08:37] <malin> It print the first result twice
[08:37] <rye> malin: i think you may want to print the whole array first to see whether there are indeed 2 duplicate items
[08:38] <malin> I do print the arra as far as I know
[08:38] <malin> I make the array like this:
[08:38] <malin> results_list = []
[08:38] <duflu> rye: I encountered a very similar fullscreen bug in geeqie, which is now fixed. Unfortunately the fix was to fix the app in that case.
[08:39] <malin> then I add results to the array like this:
[08:39] <malin> results_list.append(test(full_url,patjunk))
[08:39] <malin> and I reverse it:
[08:39] <malin> results_list.reverse ()
[08:39] <malin> and print it:
[08:39] <malin> print results_lis
[08:39] <malin> t
[08:39] <rye> duflu: I don't like the following comment in src/window.cpp of compiz - /* Don't allow maximization or fullscreen of windows which are too big to fit the screen */ - suggesting that if a window + decorations does not fit, it won't be switched to fullscreen mode, even though it is already in fullscreen mode
[08:40] <duflu> rye: Agreed.
[08:40] <davidcalle> malin, ok. Then replace lines 70 and 71, with results_list = test(full_url,patjunk).split('.Buss ')
[08:40] <duflu> The aforementioned geeqie fix was *before* I joined the compiz team
[08:40]  * duflu looks
[08:41] <rye> duflu: i wonder if it works if i ask the wm to disable the decorations...
[08:42] <davidcalle> malin, it will directly make a list from your result string returned by test. Creating a new item in the list each times it finds ".Buss "
[08:42] <duflu> rye: What is the expected behaviour for oversized fullscreen windows? How does Gnome etc deal with it? Just show part of the window?
[08:43] <rye> duflu: it is not oversized, it is exactly the size of the screen
[08:43] <malin> davidcalle: shit... it made an answer for each bus, how did taht happend :D
[08:43] <rye> duflu: however in gnome the request_size_change does not make the window to stop being fullscreen
[08:44] <malin> sometimes two different bus routes goes from the same place to the same stop, but different routes
[08:44] <duflu> rye: OK, the bug in window.cpp looks simple
[08:44] <malin> and the results was splited up in two D:
[08:44] <malin> :D
[08:44] <duflu> I'll just verify your test case and then it's triaged....
[08:44] <rye> duflu: and no, if i disable decorations the window is simply displayed the same broken way but without the decorations
[08:45] <malin> davidcalle: that looked great. But still, it puts last answer in the end and not in the start
[08:45] <duflu> rye: Yes, it looks likely to be bad dimension calculations in window.cpp
[08:47] <davidcalle> malin, even with results_list.reverse () ?
[08:47] <malin> davidcalle: yes, but  maybe I have it on wrong line ?
[08:48] <malin> anyway. Now I really understand the .split thing
[08:48] <malin> that was very smart
[08:48] <davidcalle> You should have it between the line where you create the list and the for loop
[08:49] <malin> ah
[08:49] <malin> but it is
[08:51] <davidcalle> malin, hmm. Try to print the list before reverse, and after. Is the list the same ?
[08:54] <duflu> rye: Thanks. The bug is triaged. Looks like a relatively simple fix. I hope we get it done in the next maintenance update.
[08:54] <malin> hm :
[08:55] <malin> it looks the same
[08:56] <malin> hm, it reverse it another way
[08:56] <malin> it takes all after split first and the thing before the split first
[08:56] <malin> It dosen't reverse the array, but the content of the array
[08:57] <davidcalle> malin, ok, then don't use reverse and use results_list = results_list[::-1]
[08:57] <davidcalle> malin, it will reverse the array.
[09:00] <malin> aha
[09:04] <malin> hm, now it just printed the previous results once more, before it gave the next result. It still puts last answer in the last and not the top
[09:04] <malin> maybe it is possible to use a stack in stead?
[09:05] <davidcalle> malin, can you pastebin your code?
[09:05] <malin> yeah
[09:06] <malin> http://pastebin.com/4kYiTgrY
[09:07] <davidcalle> malin, uncomment model.clear ()
[09:09] <malin> aha
[09:10] <davidcalle> malin, I thought your issue was about several busses results from a single search and that you wanted this list reversed :)
[09:10] <davidcalle> malin, but in fact your lens wasn't cleared of results from previous searches.
[09:12] <malin> what I want is: several results, but the last search-result at top, not bottom. if there is a long list with previous results, thats okey
[09:13] <angeloc> hi guys, i'm having trouble with a java application in unity, it opens two pixel wide, a vertical ribbon that's impossible to resize
[09:13] <davidcalle> malin, in the Dash, you can't reorder results once they have been displayed. Results from next searches will only be added after the existing ones.
[09:14] <angeloc> it works in unity-2d
[09:14] <malin> davidcalle: okey, so it is impossible to get it at the top? I see
[09:14] <malin> but then I it just is the way it is then :)
[09:15] <davidcalle> malin, yeah, to have a result in the first position, you have to clear the Dash from existing results.
[09:16] <malin> I see, but In fact I think that's the best solution. There is no good reasons to store an old result, as the result is not valid for long time, as the day goes on
[09:17] <malin> so I think I will let it be like it is now. Splitting up the results in two, so the different buses appears in different results is smart and I didn't know about it :)
[09:18] <davidcalle> malin, this way, most of the time, you won't need to click on the result to get the full text.
[09:19] <malin> davidcalle: indeed. I never thought about it actually because I didn't know it was possible, but I now understand how it work to split the resutlts
[09:20] <malin> something.split('text where the new result should start and the first stop ')
[09:20] <malin> that's so genius :)
[09:22] <davidcalle> malin, hehe :)
[09:22] <malin> yeah :)
[09:23] <malin> maybe I should make it not write: Tidene angir tidligste passering osv også
[09:23] <malin> ah, that's norwegian :p
[09:27] <davidcalle> malin, yes, just need to result.replace ('the tidene string', ''), in the for loop, before appending to the model
[09:27] <malin> ok
[09:27] <malin> or I can clean it up in the patjunk-thing too?
[09:28] <davidcalle> malin, yes you can
[09:28] <malin> but when you say in the for-loop
[09:28] <malin> you mean in the for result in results_list
[09:28] <malin> ?
[09:28] <malin> but on the line before model.append
[09:29] <angeloc> hi guys, i'm having trouble with a java application in unity, it opens two pixel wide, a vertical ribbon that's impossible to resize, it works in unity-2d, anybody has infos about that?
[09:30] <davidcalle> malin, yeah, to do it for each result. But it also works if you do it in patjunk.
[09:31] <malin> if I do it in patjunk, will it be done in every result then?
[09:32] <malin> I think next time I make a lense, I will go on to use the for-loop and result.replace ('the string to change', 'string to change to')  :)
[09:33] <davidcalle> malin, it will replace every  occurence of the Tidene string it founds. So yes.
[09:33] <malin> ok :)
[09:33] <malin> but next time, I will make a lense without patjunk, and just use the for and replace-thing :) looks simple too and maybe more lense-ish :)
[09:57] <malin> pushed :D
[10:36] <apw> didrocks, ok i managed to trigger the stacking issue without an update to prove it is not that.  it _may_ be to do with the mumble dialog boxes, will try and confirm that tommorrow
[10:37] <didrocks> apw: thanks, did you ping sam?
[10:37] <apw> didrocks, didn't remember and hes not on at the times of day i see it
[10:38] <didrocks> apw: please, ping him about it, he's the best to fix this
[10:38] <apw> didrocks, will do
[11:29] <jussi> mr mhall119, are you available?
[11:55] <mhall119> jussi: yes sir I am
[11:57] <jussi> mhall119: mind if I PM for  a minute?
[12:55] <tsdgeos> didrocks: got https://jenkins.qa.ubuntu.com/job/automerge-unity-2d/265/console when merging lp:~aacid/unity-2d/spread_focus into lp:unity-2d
[12:55] <tsdgeos> any idea what's up?
[12:56] <didrocks> tsdgeos: yeah, I made a change in the builder to support multiple ppa, I just forgot to create a directory, already fixing it :)
[12:56] <didrocks> I'll approve it again then
[12:56] <tsdgeos> thanks
[12:57] <tsdgeos> https://code.launchpad.net/~aacid/unity-2d/spread_focus/+merge/102250 is the url for the merge
[12:57] <didrocks> already opened in a tab ;)
[12:57] <tsdgeos> ok
[13:33] <alf_> Hi! How is gtk-window-decorator started by unity? With the arm gles2 compiz/unity packages, I need to run it manually to get any decorations, and I am trying to figure out what's wrong.
[13:33] <alf_> ogra_: ^
[13:33] <ogra_> yep
[13:35] <alf_> ogra_: Do you get that, too?
[13:35] <ogra_> alf_, just started testing the panda images so not there yet
[13:36] <alf_> ogra_: ok, because it may just be a problem with my setup (although Ricardo encountered something similar)...
[13:37] <ogra_> i will report back later today once i'm done with testing
[13:38] <thumper> alf_: I'm not sure, but you can ask smspillaz
[13:38] <thumper> alf_: he knows most
[13:39] <alf_> thumper: thanks
[16:33] <hyperair> how does one set the title of an application indicator in python?
[17:12] <mhall119> hyperair: http://bazaar.launchpad.net/~mhall119/hello-unity/trunk/view/head:/hello_unity/indicator.py#L50
[17:12] <mhall119> like that
[17:13] <hyperair> mhall119: didn't work for me in precise. there wasn't a set_title() function.
[17:13] <hyperair> mhall119: i had to do set_property("title", _("Deluge"))
[17:13] <hyperair> oh hang on....
[17:13] <hyperair> from gi.repository..
[17:13] <hyperair> hmmm
[17:13] <hyperair> that's gtk3
[17:14] <mhall119> oh yeah, I'm using gtk3
[17:14] <hyperair> deluge is still gtk2 unfortunately
[17:14] <mhall119> oh, let me see if I can find those docs
[17:15] <mhall119> hmm, it should have set_title
[17:15] <mhall119> how are you importing appindicator?
[17:16] <hyperair> mhall119: https://paste.debian.net/163710/
[17:16] <hyperair> should have, but doesn't.
[17:16] <hyperair> python -c "import appindicator; help(appindicator.Indicator)" | pastebinit -i-
[17:16] <mhall119> and setting it as a property doesn't work either?
[17:16] <mhall119> try import appindicator3
[17:17] <hyperair> doesn't that use gtk3?
[17:17] <hyperair> no module called appindicator3
[17:17] <hyperair> set_property works
[17:17] <hyperair> but it had a __setattr__ method so i thought i could just do foo.title = _("Deluge")
[17:17] <hyperair> looks like that didn't wokr
[17:17] <hyperair> or are attributes and properties different?
[17:18] <mhall119> I think they're different
[17:18] <mhall119> at least, when doing it the GObject way
[17:18] <mhall119> tedg: any idea why Indicator.set_title isn't available to hyperair?
[17:18] <hyperair> i see
[17:19] <hyperair> probably because i'm using the old and dated appindicator library
[17:19] <mhall119> hyperair: you're on the latest Precise right?
[17:19] <hyperair> the "title" probably got dynamically added due to the new libappindicator
[17:19] <hyperair> yes
[17:19] <hyperair> could it be that libappindicator was updated to have the new "title" property (that's installed into the gobject type system)
[17:19] <hyperair> but not python-appindicator?
[17:19] <hyperair> that would explain thigns
[17:20] <hyperair> presumably the documentation is auto-generated
[17:20] <mhall119> could be, since it'll directly reflect changes to the GObject
[17:20] <mhall119> I know the API docs are generated, yes
[17:20] <mhall119> if that's the case, it's a bug in python-appindicator
[17:21] <mhall119> tedg should be able to say for sure
[17:21] <tedg> Yeah, I'd guess that's the case.
[17:21] <tedg> The docs are from the GIR package.
[17:21] <mhall119> hyperair: you can always upgrade deluge to Gtk 3 :)
[17:21] <tedg> Which if it's something you're coding now, I'd recommend using :-)
[17:22] <tedg> Also we have a patch to allow the title to be set by using g_set_application_name() which might be easier.
[17:22] <tedg> (what ever that is in Python)
[17:23] <mhall119> tedg: does that require using GApplication?
[17:23] <tedg> mhall119, I don't believe so
[17:23] <mhall119> I know how to set window name, but not application name
[17:26] <rye> hyperair: erm, i was able to set title on python indicator which was not using gir...
[17:27]  * rye looks
[17:27] <rye> hyperair: indicator_object.set_property("title", label)
[17:27] <rye> there is no set_title() but you can set the property
[17:33] <gotwig> mhall119: hey there
[17:33] <gotwig> have a question to workspace switcher quicklist: why is there no quicklist for it?
[17:34] <gotwig> I saw one from the community that allowed you to add workspaces, etc.
[17:34] <gotwig> but its not in upstream
[17:34] <gotwig> and why is (really) lo-menubar not included :/
[17:34] <mhall119> gotwig: where did you see it?  was it working code or just a mockup?
[17:34] <hyperair> tedg: weird. i tried g_set_application_name first with alarm-clock but that didn't work
[17:34] <mhall119> I don't know the details about libreoffice, sorry
[17:34] <hyperair> o
[17:35] <gotwig> mhall119: wait. I search for a link
[17:36] <mhall119> gotwig: last I heard there was some stability concerns with lo-menubar
[17:36] <gotwig> mhall119: yes, but only for china :/
[17:36] <mhall119> but that was at least one cycle ago, so I'm not sure if it still applies
[17:36] <gotwig> mhall119: you cant use the HUD without this lo-menubar (all know)^^
[17:37] <mhall119> right, it has to export the menu structure
[17:37] <gotwig> IMHO that could block many users...
[17:37] <gotwig> or give them a badder experience
[17:38] <mhall119> agreed,  but again I don't know the details, I'm sure there was a risk/reward analysis done
[17:38] <hyperair> tedg: i just tried g_set_application_name with alarm-clock-applet, but it says untitled indicator.
[17:39] <hyperair> tedg: running p g_get_application_name() with gdb shows the correct name, though.
[17:40] <rye> hyperair: set the "title" property on the indicator and it will set the title
[17:40] <hyperair> rye: i know, but title is part of the new libappindicator API.
[17:41] <rye> hyperair: so you get an error about invalid property when you try to set the title?
[17:41] <hyperair> rye: in alarm-clock, which i submitted a merge proposal for, that requires #ifdefs for backward compatibility. whereas g_set_application_name() is present in glib going all the way back
[17:42] <hyperair> rye: earlier i was talking about deluge, which is in python. now, regarding g_set_application_name(), i'm talking about alarm-clock-applet, which is in C.
[17:42] <gotwig> mhall119: I somehow dont find the quicklists on askubuntu again :X
[17:43] <mhall119> gotwig: the workspace switcher is different from App launchers anyway, adding a quicklist to it probably requires code in lp:unity itself
[17:44] <seb128> hyperair, the g_set_application_name() fallback didn't make it to precise, it just got suggested,written this week
[17:44] <gotwig> mhall119: and point 4 on this site is also not included for libre office :/ http://maketecheasier.com/8-really-useful-ubuntu-unity-quicklists/2011/05/07
[17:44] <seb128> hyperair, it will be in a SRU
[17:44] <rye> hyperair: understood. Well, you can query for the "title" property and use it if it exists. But g_set_application_name fallback might be a better thing though
[17:45] <seb128> hyperair, https://code.launchpad.net/~ted/libappindicator/app_name/+merge/102161
[17:46] <hyperair> seb128: i see. that's a pity. weirdly enough, i don't see any hint of tomboy setting its title, but it seems to still get set anyway
[17:46] <seb128> hyperair, I added a patch to tomboy in Ubuntu
[17:46] <hyperair> oh you did?
[17:46] <hyperair> that explains it
[17:46] <hyperair> thanks
[17:46] <seb128> yes
[17:46] <seb128> yw
[17:46] <hyperair> so why don't we get that merged in?
[17:47] <hyperair> the application name one, i mean
[17:47] <seb128> hyperair, because it was acked 5 hours ago and nobody went to merge approved stuff yet (they usually do before rolling tarballs)
[17:47] <mhall119> hyperair: it is, it'll be a post-release update
[17:47] <hyperair> ah, i see
[17:47] <hyperair> cool =)
[17:48] <seb128> hyperair, the tomboy fix I did was to add "indicator.Title = Catalog.GetString ("Tomboy Notes");" to the indicator patch
[17:49] <hyperair> i figured as much. thanks
[17:49] <seb128> yw
[17:49] <hyperair> i was staring at tomboy code some days back and wondering how the "Tomboy Notes" string got onto the indicator
[17:49] <hyperair> heheh
[17:49] <hyperair> hmm speaking of which, that's a new string, so it would be untranslated.
[17:50] <hyperair> or not
[17:50] <hyperair> okay, it's not a new string.
[17:51] <seb128> hyperair, I picked an existing string ;-)
[17:51] <seb128> I would have used "Tomboy" otherwise
[17:52] <seb128> i.e names are usually a good pick to avoid translation issues ;-)
[17:52] <hyperair> aha :)
[17:52] <seb128> well at least when the name is not a function like GNOME does nowadays
[17:52] <hyperair> a function?
[17:52] <hyperair> what do you mean?
[17:52] <seb128> they renamed epiphany "Web"
[17:52] <seb128> or like gnome-contacts is "Contacts"
[17:53] <seb128> those names get translated
[17:53] <seb128> sorry that's frenglish
[17:53] <seb128> function->common name, i.e a word describing the purpose of the app
[17:53] <hyperair> ah, right.
[17:54] <hyperair> but isn't that in the desktop file?
[17:54] <seb128> yes
[17:54] <hyperair> and i thought it was done ages back
[17:54] <hyperair> and reverted
[17:54] <hyperair> it flip flopped a couple of times iirc
[17:54] <seb128> but in practice people will translate "Contact" to the equivalent in their locale
[17:54] <seb128> they will not translate "gimp"
[17:54] <seb128> or "tomboy"
[17:54] <hyperair> indeed.
[17:54] <hyperair> but "Tomboy Notes" would get translated.
[17:55] <hyperair> hmm i wonder if names get translated in the case of japanese
[17:55] <JanC> depends
[17:55] <JanC> nobody would translate "Lotus Notes" for example
[17:56] <hyperair> トンボイノートす
[17:56] <hyperair> tonboi notosu
[17:56] <JanC> well, maybe some would  ;)
[17:56] <hyperair> ;)
[17:56] <hyperair> i made that up
[17:56] <hyperair> i'm not sure if it actually was translated like that
[17:57] <hyperair> msgstr "Tomboy メモ"
[17:57] <hyperair> Tomboy Memo
[17:59] <JanC> it mainly depends on how the name is perceived: is it named "Tomboy" and allows you to make "notes", or is it named "Tomboy Notes"
[18:00] <JanC> for commercial software that's generally clear from marketing, for (some) open source apps things can be more confusing...  ;)
[18:15] <kklimonda> what are the plans for Unity and Gtk "App Menus"?
[18:29] <seb128> kklimonda, what do you mean by 'Gtk "App Menus"'
[18:29] <kklimonda> seb128: check the description for GtkApplication: http://developer.gnome.org/gtk3/3.3/GtkApplication.html
[18:30] <kklimonda> (and a few screenshots)
[18:30] <seb128> kklimonda, they just work, gmenus support was added to indicator-appmenu this cycle
[18:31] <seb128> kklimonda, they will show under the unity panel similar to the mac example
[18:32] <kklimonda> seb128: the example doesn't really work well
[18:33] <seb128> kklimonda, how so?
[18:33] <kklimonda> seb128: when you show the menu it displays the standard, clipped Bloatpad application name, then the "Unknown Application Name" and the standard menu
[18:34] <kklimonda> seb128: I expect that, when the small bug with "Unknown Application Name" is fixed, we'll see the "Bloadpad" name twice - once clipped, and the second time as a part of the menu
[18:35] <seb128> kklimonda, that seems a bug in gtkapplication or the example you use
[18:35] <seb128> kklimonda, tetravex which uses gmenus doesn't have that issue
[18:36] <kklimonda> seb128: and it illustrates my point pretty well
[18:37] <seb128> kklimonda, what does?
[18:37] <kklimonda> seb128: when you launch Tetravex and show the menu you can see name "Tetravex" twice
[18:37] <seb128> oh
[18:37] <seb128> that's the application title and the menu name
[18:37] <kklimonda> seb128: yes, but it looks wrong
[18:37] <seb128> if you don't mouseover you just see the title
[18:38] <seb128> how would you call the menu?
[18:38] <kklimonda> seb128: I know, but it doesn't look right - that's why I've asked if there was a plan to somehow change it
[18:38] <hyperair> does anyone get the idea that the HUD search works a *lot* better than the unity dash?
[18:38] <hyperair> for example searching for compizconfig in the dash doesn't work.
[18:39] <seb128> kklimonda, that changed pretty recently in gtk in fact, the menu was called "applications" until recently
[18:39] <kklimonda> seb128: imo the menu name is not the issue here, the additional window name is
[18:39] <seb128> kklimonda, well menus need to have a name, you can't have a blank space in the panel opening a menu
[18:40] <seb128> hyperair, hud is being smart ;-)
[18:40] <kklimonda> seb128: it wouldn't be the problem if we kept the "Ubuntu" button in it's initial position :(
[18:40] <hyperair> seb128: can we make dash as smart as HUD? it feels really sluggish.
[18:40] <hyperair> and i'm quite sure it's not just a rendering issue. it takes forever to search for stuff
[18:41] <seb128> kklimonda, that has issues as well
[18:41] <kklimonda> seb128: I know
[18:41] <seb128> hyperair, does it?
[18:41] <hyperair> seb128: yeah, compared to the HUD in any case
[18:41] <hyperair> seb128: and compaerd to GNOME Do.
[18:41] <hyperair> if you try out GNOME Do for a couple of days, and then switch back to the dash, you'll get what i maen
[18:41] <seb128> hyperair, well so hud and dash work differently, kamstrup or mhr3 are better person to talk to about the dash
[18:41] <seb128> hyperair, is that an ui stuff?
[18:42] <hyperair> gnome-do?
[18:42] <hyperair> sure it is
[18:42] <hyperair> it's the thing that came with docky sometime back..
[18:42] <seb128> hyperair, no, the "slugish" issue
[18:42] <seb128> because I can "super", type, enter and it always run what I typed for
[18:42] <hyperair> seb128: the spinner continues spinning for a while before getting any results.
[18:42] <seb128> like I can't go faster than it matches
[18:42] <hyperair> hmm weird.
[18:42] <hyperair> maybe i've got a lot of stuff
[18:43] <seb128> what sort of disk do you have?
[18:43] <hyperair> a hard disk.
[18:43] <hyperair> are you running on an ssd?
[18:43] <seb128> rotational or ssd?
[18:43] <hyperair> rotational.
[18:43] <seb128> yes
[18:43] <hyperair> figures.
[18:43] <hyperair> maybe it's an i/o issue after all
[18:44] <seb128> well, mhr3 pointed to me yesterday that most of the "slowness" in the app lens is due to parsing the .desktop on disk
[18:44] <seb128> is gnome-do caching those in some way?
[18:44] <hyperair> i think it does
[18:44] <seb128> that's probably it
[18:44] <hyperair> aha
[18:44] <hyperair> does unity re-parse all the .desktop files each time?
[18:44] <seb128> that's something that should be fixed in gnome-menus
[18:45] <seb128> it uses gnome-menus
[18:45] <hyperair> i see
[18:45] <seb128> which has no cache
[18:45] <seb128> we had one in GNOME2
[18:45] <seb128> but it was not updated for GNOME3
[18:45] <seb128> we should really try to get that back and upstream
[18:45] <hyperair> you mean a gnome-menus with cache?
[18:45] <seb128> yes
[18:45] <hyperair> i see.
[18:46] <hyperair> do you have a link to it?
[18:46] <seb128> the old one?
[18:46] <hyperair> yep
[18:47] <seb128> looking...
[18:48] <seb128> hyperair, https://launchpad.net/ubuntu/+source/gnome-menus/2.28.0.1-0ubuntu2
[18:48] <hyperair> thanks
[18:51] <mhall119> seb128: does appmenu-gtk support both window menu *and* the new GtkApplication menu at the same time?
[18:52] <seb128> mhall119, yes
[18:52] <mhall119> ok
[18:52] <seb128> mhall119, it append the second one to the next one in those case iirc
[18:52] <mhall119> ok, makes sense
[18:53] <mhall119> is the GtkApplication menu single-level, or does it allow nested menus?
[18:54] <mhall119> if single-level, maybe it could be used as a Quicklist intead
[18:55] <seb128> mhall119, I didn't check but I would guess it's any menu you want to build
[18:55] <seb128> it doesn't really make sense to technical limit it, if it's better as a flat list design guideline should suggest that
[18:55] <seb128> then if an app as a valid reason to do differently they still can
[19:09] <kklimonda> yeah, it supports nested menus
[19:10] <kklimonda> I think quicklists and app menu serve different purposes, aren't gnome-shell developers working on quick lists for their launcher?
[19:11] <kklimonda> on Mac, you put stuff like "About" or "Preferences" there and I expect GNOME to create similar guidelines
[19:46] <bschaefer> thomi, ping
[19:46] <thomi> Hi
[19:46] <bschaefer> hey, so Im not sure how those conflicts got in there
[19:46] <bschaefer> but they should be fixed now...
[19:47] <bschaefer> opps some indenting to fix one sec
[19:47] <thomi> ok, I'll take a look in a second...
[19:47] <thomi> :)
[19:47] <bschaefer> yeah, wait a sec haha
[19:47] <thomi> remember to check the trailing shitesapce :)
[19:48] <bschaefer> yeah I have that in my vimrc file, it does it when I save :)
[19:54] <bschaefer> ok the diff is done...
[20:27] <malin> davidcalle: I get this build failed message all the time https://launchpadlibrarian.net/102516068/buildlog.txt.gz
[20:27] <malin> tried to fill in more lines to the description section, but it fails
[20:38] <thomi> bschaefer: approved
[20:40] <mhall119> malin: can you link to your debian/control file?
[20:41] <davidcalle> malin, http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Description
[20:41] <davidcalle> malin, you can't have blank lines in your description. If you want to add a blank line, you have to fill it with one space, and a dot.
[20:42] <davidcalle> mhall119, http://bazaar.launchpad.net/~malinkb/unity-buss/unity-buss-experimental/view/head:/debian/control
[20:42] <malin> mhall119: og davidcalle: http://bazaar.launchpad.net/~malinkb/unity-buss/unity-buss-experimental/view/head:/debian/control
[20:44] <malin> but if I write a long line, how can I break it more lines ?
[20:44] <malin> with a bank line and a dot?
[20:44] <malin> I have to look at the example again
[20:45] <malin> ah, I understand. I needs a dot like here: http://bazaar.launchpad.net/~telepathy/empathy/ubuntu/view/head:/control
[20:45] <mhall119> malin: I think your blank lines need at least a space to indicate that it's a continuation of the previous lines
[20:46] <malin> oki
[20:46] <mhall119> malin: do you run debuild locally before uploading?
[20:49] <bschaefer> thomi, thanks!
[20:53] <malin> nope I haven't done because I don't know how to do it. I Think it would save the launchpad building-server to do it locally first :)
[20:53] <malin> mhall119: but all I do is: debuild <project-folder>   ?
[20:53] <seb128> r
[20:56] <bschaefer> thomi, also there is a failure in test_dash.py, but it's from trying to use the launcher instead of the keybinding
[20:56] <bschaefer> ill be making a branch for the fix to the hud to dash and then losing key focus soon, and I can just push that change with it
[20:56] <thomi> cheers
[20:57] <malin> mhall119: I just installed devscripts
[20:57] <malin> so I can try locally first
[20:57] <mhall119> malin: "debuild -us -uc", no need for signing the binary when you're test-building
[20:58] <mhall119> then "debuild -S -sa" for a signed source package if you're uploading to a PPA
[20:58] <mhall119> or let the recipe do it at that point
[20:59] <malin> can I upload myselv with that method?
[20:59] <malin> upload deb-files
[20:59] <malin> or is just for testing purpose before requesting a build at the launchpad-site?
[21:00] <malin> mhall119: http://pastebin.com/nd55DSPG
[21:03] <bschaefer> thomi, I think the merging bot isn't very happy today
[21:04] <bschaefer> thomi, im not sure what revisions it's talking about here: https://code.launchpad.net/~unity-team/unity/hud-tests-to-wait/+merge/102440
[21:06] <bschaefer> also I just put a commit message for the homes lens, as it kept crying about that
[21:06] <bschaefer> the home lens branch
[21:13] <mhr3> seb128, hyperair, the apps lens startup is slow due to desktop files, then it should be fine
[21:14] <thomi> bschaefer: yeah, it's pretty borked today
[21:17] <malin> mhall119: what do I do wrong with debuild to get the errors?
[21:19] <mhall119> malin: ugh, i'm not sure, try asking in #ubuntu-devel or #ubuntu-motu
[21:20] <malin> mhall119: okey :) Thanx however :)
[21:24] <mhall119> np
[21:49] <bschaefer> thomi, could you review these ap test? https://code.launchpad.net/~brandontschaefer/unity/hud-to-dash-loses-win-focus/+merge/102598
[21:49] <thomi> sure thing
[21:49] <bschaefer> also I should remove that sleep(1)...
[21:49] <bschaefer> I thought I would be a good idea, then the next test realized I didn't need it haha
[21:50] <thomi> bschaefer: yes please
[21:50] <thomi> sleep() is an abomination
[21:50] <thomi> bschaefer: ping me when you need another approve :)
[21:51] <bschaefer> is there anything else that needs to be changed?
[21:51] <thomi> nope, looks good
[21:51] <bschaefer> cool, ill ping you when the diff is done :)
[21:55] <bschaefer> thomi, hmm also looking at it should I change the 41	+ self.assertTrue(calc_win.is_focused) to use eventually?
[21:56] <bschaefer> thomi, also the diff is done updating
[21:57] <thomi> bschaefer: no, the bamf emulator attributes aren't supported by Eventually.... yet
[21:57] <bschaefer> o, hmm then should I change this then? 58	+ self.assertThat(calc_win.is_focused, Eventually(Equals(True)))
[21:58] <bschaefer> it was passing...and failing when I made it
[21:58] <thomi> that shouldn't work at all
[21:58] <bschaefer> well shoot, let me change it
[22:02] <bschaefer> thomi, ok done
[22:02] <bschaefer> and diff is updated
[22:03] <thomi> approved., Thanks
[22:03] <bschaefer> thank you!
[22:40] <thomi> bschaefer: still around?
[22:40] <bschaefer> thomi, yup!
[22:40] <thomi> could I get your to review this (again): https://code.launchpad.net/~thomir/unity/hud-tests-to-wait_for-feature/+merge/102601
[22:41] <bschaefer> yup
[22:41] <thomi> it's the same branch as before, but with the conflicts fixes
[22:41] <thomi> *fixed
[22:42] <bschaefer> thomi, hmm did my branch just break haha?
[22:42] <thomi> bschaefer: how so?
[22:42] <bschaefer> did it get merged?
[22:42] <bschaefer> because my hud one was saying some revisions weren't approved?
[22:43] <thomi> hmm, duno
[22:43] <thomi> it looks good to me
[22:44] <bschaefer> yeah, o well haha
[22:45] <bschaefer> thomi, 149	- launcher_shows_pre = launcher.is_showing
[22:45] <bschaefer> shouldn't that one be used?
[22:46] <bschaefer> as I thought it was a property
[22:46] <thomi> bschaefer: good catch
[22:46]  * thomi fixes
[22:47] <bschaefer> The only reason I know is I ran into that same problem haha ;)
[22:47] <thomi> bschaefer: pushiong new version now
[22:48] <thomi> done.
[22:49]  * bschaefer waits for diff
[22:51] <bschaefer> thomi, approved, now I have to relocate my self...