[02:54] <mhall119> Saviq: happy birthday, btw
[02:59] <kgunn> Saviq: yes...happy bday! hope it was a good one!
[08:09] <tsdgeos> guys, does xvfbtestPreviewPayments succeed for you ?
[08:09] <tsdgeos> @unity8: ↑
[08:09] <tsdgeos> @unity: ↑
[08:10] <Saviq> tsdgeos, LANG=C
[08:10] <tsdgeos> still fails
[08:10] <tsdgeos> very funnily though :D
[08:10] <tsdgeos> ah
[08:10] <tsdgeos> lang doesn't change numeric
[08:11] <tsdgeos> let's see LC_ALL
[08:11] <Saviq> right
[08:11] <tsdgeos> yeah that works now
[08:11] <Saviq> yeah, LC_ALL sorry
[08:11] <tsdgeos> didn't we decide against this and make tests work with all locales at the end?
[08:12] <Saviq> tsdgeos, well, we decided that tests need to make sure they have their env set up correctly... but it doesn't work with our QmlTest macros, /me needs to fix that
[08:12] <tsdgeos> ok
[08:12] <tsdgeos> it's a bug, no worries
[08:12] <tsdgeos> :D
[08:15] <Saviq> tsdgeos, got linkedin around? check the new job of this guy https://www.linkedin.com/profile/view?id=58421147 :D
[08:16] <tsdgeos> lol
[08:16] <Saviq> just couldn't stay away
[08:16]  * Saviq likes
[08:28] <tsdgeos> weird, my dash_overview branch has no qmluitests failures
[08:28] <tsdgeos> i thought it'd fail since i increased the number of dash scopes
[08:29] <tsdgeos> let's see what autopilot says
[08:41] <Saviq> gotta go taxes, biab
[08:55] <tsdgeos> anyone knows why my EdgeDragArea behaves different in ./run.sh than in make tryDash ?
[08:56] <tsdgeos> ah in try the timer is disabled i think
[09:00] <tsdgeos> i think i still don't understand fully how to use the EdgeDragArea
[09:00] <tsdgeos> too much automagic and too few documentation
[09:01] <mzanetti> tsdgeos: yeah... there's a special timing source for testing
[09:02] <mzanetti> iirc you can even control that from your test
[09:02] <mzanetti> but I don't think I did that
[09:02] <mzanetti> ever
[09:39] <tsdgeos> mhr3: any ETA for when we can expect a backend for the dash overview thing?
[09:40] <mhr3> tsdgeos, could you write down somewhere all the changes you need?
[09:42] <tsdgeos> sure
[09:45] <tsdgeos> mhr3: http://paste.ubuntu.com/7802652/
[09:45] <tsdgeos> not much
[09:48] <mhr3> tsdgeos, what do you expect searches to return?
[09:52] <tsdgeos> i hanven't really explored searches (as in my fake backend doesn't implement them), but i think what we discussed with saviq was just getting categories back and i guess if their names are not "favorites" and "all" i switch to results view?
[09:53] <Saviq> tsdgeos, I think it doesn't matter what the categories' names are
[09:54] <Saviq> tsdgeos, as long as search query != "", you switch to standard LVWPH
[09:54] <tsdgeos> Saviq: right
[09:54] <tsdgeos> mhr3: so yeah, just return categories as usual
[09:54] <mhr3> tsdgeos, but you still want the special ResultsModel in there?
[09:55] <tsdgeos> hmmm
[09:55] <mhr3> or will the search be animation-free?
[09:55] <tsdgeos> yes, special resultsmodel there would be great if possible
[09:56] <tsdgeos> Saviq: there's no "Done" on search, right?
[09:56] <Saviq> tsdgeos, nope
[09:56] <Saviq> tsdgeos, there's a "back"
[09:56] <tsdgeos> ok, one weird transition to worry about :D
[09:56] <tsdgeos> Saviq: the header one
[09:56] <Saviq> +less
[09:56] <tsdgeos> no?
[09:56] <Saviq> tsdgeos, yes
[09:56] <tsdgeos> ok
[09:57] <Saviq> tsdgeos, https://f966f709-a-c881af26-s-sites.googlegroups.com/a/canonical.com/unity8dash/scopes/dash-overview/2a.searchbox%20focus.png
[09:57] <Saviq> https://f966f709-a-c881af26-s-sites.googlegroups.com/a/canonical.com/unity8dash/scopes/dash-overview/5.results.png
[09:57] <mhr3> tsdgeos, oh, right you don't need that scopeIndex method if the user just taps on the result directly, right
[09:57] <Saviq> mhr3, nope
[09:57] <tsdgeos> mhr3: correct
[09:57] <tsdgeos> hmmm
[09:57] <tsdgeos> well
[09:57] <mhr3> so no need to mangle search resultsmodels
[09:57] <tsdgeos> hmmm
[09:58] <tsdgeos> let me think :D
[09:58] <mhr3> beep
[09:58] <mhr3> the end, you can't change that decision now
[09:59] <tsdgeos> i don't need the scopeIndex
[09:59] <tsdgeos> but i need the scopeId role
[10:00] <tsdgeos> so i can know if that search result is a favorite or not
[10:00] <tsdgeos> so if you're going to give me one
[10:00] <tsdgeos> give me both ?
[10:00] <mhr3> i could just add that role everywhere
[10:01] <tsdgeos> and waht would it return?
[10:01] <tsdgeos> just "" ?
[10:01] <mhr3> same thing it will return for non-scope results
[10:01] <mhr3> you don't expect the nike result to actually have a scopeId, do you?
[10:02] <tsdgeos> i expect it to be undefined
[10:02] <tsdgeos> not ""
[10:02] <tsdgeos> but nevermind
[10:02] <mhr3> if you want too much, it can be undefined
[10:02] <tsdgeos> it's ok
[10:03] <mhr3> although... hmm, not sure if QVariant() is undefined or null
[10:03] <tsdgeos> small details noone really cares about :D
[10:04] <Saviq> mhr3, undefined
[10:04] <mhr3> good
[10:05] <Saviq> mhr3, oh can you show me designs for header links?
[10:06] <mhr3> sure, let me find them
[10:06] <mhr3> Saviq, page 11 @ https://docs.google.com/a/canonical.com/document/d/1Y9H3SY2uwbeLZSta9bGdLcyGr-tP0LwHyIUigTnieww/edit#heading=h.ihcuz26wprxs
[10:07] <mhr3> or 12
[10:07] <mhr3> depending on your resolution :)
[10:07] <mhr3> yey good gdocs
[10:08] <Saviq> mhr3, ok, that helps, I must've been looking at something old
[10:09] <Saviq> mhr3, btw, should we talk about results-in-previews or not yet?
[10:10] <mhr3> Saviq, had a quick chat with thomas about it, we're starting to find issues with it :/
[10:11] <Saviq> mhr3, uh oh, so not yet
[10:11] <mhr3> Saviq, but the simplest version of it could just could just be {"widget-type": "categories", "query": "foo"}
[10:11] <Saviq> mhr3, yeah that's what I thought
[10:12] <mhr3> i don't like it cause it does multiple queries, but well, good enough for v1
[10:12] <Saviq> mhr3, except I'd rather only have one category
[10:12] <Saviq> I don't think we should ever expect more in there
[10:12] <mhr3> hmmm :/
[10:12] <Saviq> mhr3, but ultimately we can just take the first one and ignore the rest
[10:13] <mhr3> Saviq, can't you just pretend that you have multiple categories widgets if there are multiple categories?
[10:13] <Saviq> mhr3, pretend as in not display them?
[10:14] <mhr3> pretend as in expand one widget into multiple
[10:14] <mhr3> s/expand/duplicate
[10:14] <Saviq> mhr3, we'll get into see more / see less, nested delegate management...
[10:14] <mhr3> oh dear, non-terminated s///, that's gonna bug me now
[10:17] <tsdgeos> oh lol
[10:17] <tsdgeos> testDash segfaults
[10:17] <Saviq> it does indeed
[10:17] <tsdgeos> i was checking for "Fail!" and that's why i thought all my qmluitests worked ^_^
[10:17] <Saviq> ;)
[10:17] <tsdgeos> good guy CO
[10:17] <tsdgeos> -o+i
[10:18] <mhr3> Saviq, my problem is that if it doesn't support multiple categories, you not only have to do 2 queries, but (preview + number of cat widgets)
[10:18] <tsdgeos> Saviq: so the upstart thing seems confirmed only happens in restart and not stop+start, right?
[10:18] <Saviq> tsdgeos, yes
[10:18] <tsdgeos> Saviq: can we change our code not to do restart ever? :D
[10:19] <mhr3> Saviq, and iirc, every design i saw using that had the artist info + at least 2 other cats
[10:19] <Saviq> tsdgeos, it's almost fixed
[10:19] <tsdgeos> ok :)
[10:19] <Saviq> tsdgeos, hmm hmmm
[10:20] <Saviq> tsdgeos, we don't do restart
[10:20] <Saviq> tsdgeos, but maybe if you do stop/start in quick succession, it's triggered as well..
[10:20] <Saviq> mhr3, show me?
[10:21] <tsdgeos> Saviq: i guess you should comment in the bug saying we don't do restart :D
[10:21] <Saviq> tsdgeos, is the only way I could reproduce...
[10:21] <tsdgeos> ah
[10:21] <tsdgeos> ok
[10:21] <Saviq> tsdgeos, it doesn't die for me during autopilot
[10:21] <Saviq> tsdgeos, if it does for you, maybe try and collect the same data I did
[10:22] <tsdgeos> yeah
[10:22] <tsdgeos> let me make sure qmluitests pass
[10:22] <mhr3> Saviq, 12 @ https://docs.google.com/a/canonical.com/document/d/16-RX9drsBRWxQq7upD-nlin-D1NodBp8ICiLQwy262c/edit
[10:22] <tsdgeos> and then i'll run autopilot
[10:22] <tsdgeos> and see what's up
[10:22] <Saviq> tsdgeos, wanna me build a package for you?
[10:22] <Saviq> tsdgeos, with the bugfix?
[10:22] <tsdgeos> Saviq: sure :)
[10:25] <Saviq> mhr3, that's a search, not a preview
[10:25] <mhr3> Saviq, and the reason why we're trying to turn in into a preview
[10:27] <Saviq> mhr3, TBH it starts looking to me like we shouldn't have anything special for previews at all, then, but just allow more card types in standard search
[10:28] <Saviq> mhr3, because suddenly they will want see all in previews, category headers behaving like in search etc.
[10:29] <mhr3> Saviq, fundamentally the second screen is a preview of the artist, it being search is a design hack
[10:30] <mhr3> Saviq, but yes, i don't think anyone thought about the behavior of the results widget in the preview
[10:31] <mhr3> Saviq, so leave for next week?
[10:31] <Saviq> mhr3, so from my PoV if we want multiple categories in previews (that are in a single widget), that's not happening
[10:31] <Saviq> not for RTM
[10:32] <mhr3> then some result cards will be interactive:false
[10:32] <mhr3> and again without any indication :/
[10:32] <Saviq> mhr3, I was only expecting a single category per widget, no expansion or such
[10:33] <Saviq> mhr3, not sure why your last statement?
[10:34] <mhr3> Saviq, cause they will still want that screen, so the big artist card will be search result, and it's just an info card, no tap action, no preview
[10:34] <Saviq> mhr3, not sure what you want me to say
[10:34] <mhr3> "this is crazy"? :)
[10:34] <Saviq> mhr3, which part?
[10:35] <mhr3> i want you to say that
[10:35] <Saviq> but which part?
[10:35] <Saviq> the interactive: false?
[10:35] <mhr3> all of it really
[10:35] <mhr3> misusing searches to display info
[10:36] <Saviq> mhr3, that's fine
[10:36] <Saviq> I mean sure, that's wrong
[10:36] <Saviq> but doesn't weigh into the fact that
[10:36] <Saviq> reality is what I said, we can try and squeeze single-category-per-widget, no expansion or anything like that
[10:37] <Saviq> otherwise we start nesting
[10:37] <mhr3> Saviq, maybe it was supposed to behave like the header link categories
[10:37] <mhr3> Saviq, oh right... yea those shouldn't be expandable
[10:37] <mhr3> even if they do have loads of results
[10:37] <Saviq> mhr3, also no sticky headers
[10:38] <mhr3> Saviq, ok, my takeaway from this is that we need to talk to design how they wanted it
[10:38] <Saviq> mhr3, inded
[10:38] <Saviq> e
[10:39] <mhr3> wanna do that asap, or on the sprint?
[10:41] <Saviq> sprint
[10:41] <tsdgeos> brrr
[10:42] <tsdgeos> running autopilot locally got 38 failures :S
[10:43] <tsdgeos> but the 2 that failed on CI actually pass :D
[10:43] <Saviq> tsdgeos, http://people.canonical.com/~msawicz/upstart+patch.tar
[10:44] <tsdgeos> tx
[10:44] <tsdgeos> someone i misread as rar
[10:44] <tsdgeos> and thught
[10:44] <tsdgeos> what?¿
[10:46] <Saviq> ;)
[10:46] <dednick> Saviq: do local upstart configs (in ~/.config/upstart) override the ones in /usr/share/upstart ?
[10:46] <mhr3> Saviq, omg omg, did you fix upstart???
[10:46] <Saviq> dednick, the ones in /usr/share/upstart/sessions/
[10:46] <Saviq> dednick, yes
[10:46] <Saviq> mhr3, jodh did (maybe)
[10:47] <dednick> Saviq: hm. so a user could change the unity8 startup environment without root access? hmm..
[10:48] <Saviq> dednick, well, yeah, they could echo "FOO=blah" > ~/.profile, too
[10:48] <Saviq> dednick, why?
[10:48] <Saviq> dednick, users generally have power over what's happening in their session...
[10:50] <dednick> Saviq: user can change trusted socket to a local file through an environment variable = bad (as far as i can see it)
[10:51] <Saviq> dednick, they can also launch apps without confinement
[10:51] <mhr3> dednick, we just need to s/trusted/kinda trusted/ :)
[10:52] <Saviq> dednick, as long as *apps* can't do it, it's fine
[10:52] <dednick> Saviq: but won't any app have access to ~/.config/upstart ?
[10:52] <Saviq> dednick, nope
[10:53] <Saviq> dednick, confined apps only have write access to their own folder
[10:53] <dednick> oh. well that's fine then.
[10:53] <Saviq> dednick, and they only have read access to the minimal set of devices / files that's required for them to work
[10:56] <Saviq> dednick, FTR https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement
[11:04] <facundobatista> Holas
[11:10] <tsdgeos> Saviq: how do we define "Search screen" for the purpose of disabling dsah overview,  current scope has a searchquery != "" ?
[11:10] <Saviq> tsdgeos, yeah
[11:10] <Saviq> tsdgeos, as everywhere else we do
[11:10] <Saviq> mhr3, we should probably have a think about this some time ↑↑
[11:11] <Saviq> mhr3, like do changed departments, filters constitute a search?
[11:21] <mhr3> Saviq, yes
[11:22] <mhr3> Saviq, for example design specifies that departments are done only when not doing actual search
[11:22] <mhr3> eh, as in query == ""
[11:22] <mhr3> but dep_id can be changing
[11:23] <mhr3> same for filters
[11:25] <Saviq> mhr3, right, I think you might need to expose "isSurfacing" or something...
[11:26] <Saviq> tsdgeos, ↑
[11:26] <Saviq> tsdgeos, but TBH I really don't see why the limitation to not go into overview when searching / previewing...
[11:26] <tsdgeos> Saviq: don't look at me :d
[11:26] <mhr3> +1, feels very artificial
[11:31] <Saviq> greyback, good news
[11:31] <Saviq> greyback, https://code.launchpad.net/~saviq/qtmir/gles-sync-20140716/+merge/227000 is what we'll need for qtmir-gles packages whenever releasing them
[11:31] <Saviq> s/them/qtmir/
[11:31] <Saviq> greyback, it will pick up the source from which qtmir itself got built
[11:32] <Saviq> packaging updates need to be cloned, too, though
[11:32] <Saviq> but at least no carrying source around
[11:32] <greyback> Saviq: nice! Has qtubuntu similar?
[11:33] <Saviq> greyback, https://code.launchpad.net/~unity-team/qtubuntu/gles-qtcomp-refactor/+merge/226870
[11:34] <greyback> Saviq: bootiful
[11:34] <Saviq> greyback, indeed
[11:35] <greyback> Saviq: so walk me through a future qtubuntu landing. I've a MR for qtubuntu. I create same MR for qtubuntu/gles. I propose both for a silo. Everything just works?
[11:35] <Saviq> greyback, you propose a MR for qtubuntu, put it in a silo and build
[11:35] <Saviq> greyback, then you get the version qtubuntu got and prep a MR for qtubuntu/gles
[11:35] <Saviq> greyback, add to silo, reconfigure, build
[11:36] <Saviq> greyback, if you know the version you'll get, you can add them together, but need to build one after the other
[11:36] <greyback> hence the "X-Auto-Uploader: no-rewrite-version"
[11:36] <Saviq> greyback, yes, we want the exact same version qtubuntu got
[11:36] <greyback> got it
[11:36] <Saviq> greyback, only -0ubuntu1 we might need to bump for no-change rebuilds and such
[12:19] <dednick> Saviq: hey. did you know that qt apps segfault on clean exit?
[12:19] <dednick> on phone.
[12:19] <Saviq> dednick, they were doing that from time to time, but no, I didn't know recently
[12:21] <dednick> Saviq: if started by commandline. dont know of any apps which actually perform a clean exit though... most are stopped through u8
[12:21] <Saviq> dednick, yeah, confirmed
[12:22] <Saviq> dednick, reporting now
[12:23] <Saviq> dednick, crash in mirclient
[12:23] <dednick> Saviq: ah, how did you get a trace? mine was useless
[12:23] <dednick> can you post the stacktrace?
[12:24] <Saviq> dednick, waited for apport to collect
[12:24] <Saviq> dednick, and got it from the .crash
[12:24] <dednick> probably dont have symbols
[12:24] <Saviq> dednick, I don't have symbols either...
[12:25] <tvoss> Saviq, dednick o/
[12:27] <Saviq> dednick, https://bugs.launchpad.net/ubuntu/+source/qtdeclarative-opensource-src/+bug/1342694
[12:28] <dednick> Saviq: thanks. tvoss ^
[12:29] <Saviq> oh wait, gotta subscribe 'im
[12:29] <Saviq> done
[12:33] <greyback> Saviq: plz subscribe me too
[12:33] <Saviq> greyback, done
[12:33] <Saviq> will make public once it retraces anyway
[12:34] <greyback> ta
[12:35] <Saviq> /food
[12:36] <mzanetti> sometimes I get scopes into a state where I can't drag them left/right any more. only up/down
[13:09] <dandrader> mzanetti, are you getting a crash when you tap on an app in qtcomp?
[13:10] <mzanetti> dandrader: no
[13:10] <mzanetti> dandrader: define "app"
[13:10] <dandrader> mzanetti, any app
[13:10] <dandrader> mzanetti, I just flashed and added the ppa
[13:10] <mzanetti> on the app surface?
[13:10] <dandrader> mzanetti, yes
[13:10] <mzanetti> dandrader: nope... works fine here
[13:11] <mzanetti> dandrader: I'm using the silo
[13:11] <mzanetti> dandrader: you're using the phone-right-edge ppa?
[13:11] <dandrader> mzanetti, yes
[13:11] <mzanetti> hmm... not sure when that was rebuilt the last time
[13:11] <dandrader> mzanetti, so I should not use the ppa anymore?
[13:12] <mzanetti> dandrader: hmm... I switched to the silo lately as kgunn keeps that up-to-date for us
[13:12] <mzanetti> dandrader: but both should work, you just might need to trigger rebuilds on the packages in the right-edge ppa
[13:16] <kgunn> mzanetti: dandrader|afk ....i saw a lot of choo-choo silo6 build pings....i assume we've rebuilt all at this point....i think
[13:17] <kgunn> we need upload lp:~unity-team/qtubuntu/qtubuntu-gles & lp:~unity-team/qtmir/qtmir-gles
[13:17] <kgunn> per Saviq's mail ^
[13:18] <kgunn> Saviq: is "ignore twins" ok ? or still we need to upload those packages ?
[13:25] <dandrader> kgunn, where's that silo and how do I use it?
[13:25] <dandrader> and what's "choo-choo"?
[13:26] <kgunn> dandrader: you naughty boy... https://wiki.ubuntu.com/Unity8/QtComp
[13:27] <kgunn> silo 6....all the instructions are there ^
[13:27] <dandrader> kgunn, ok, thanks!
[13:27] <kgunn> choo-choo is freenoded irc bot on #ubuntu-ci-choo-choo
[13:27] <kgunn> that tells you when stuff is built, reconfig'd, failed, merged, uploaded etc in your silo
[13:28] <kgunn> dandrader: you can join it, and it'll tell you when silo6 is being built (i already had added your irc nick to be pung)
[13:33] <kgunn> dednick: so does the ~mirconnection fail only for command line launched apps? or all apps ?
[13:33] <kgunn> fail....crash rathe
[13:33] <kgunn> r
[13:35] <dednick> kgunn: not sure. i'll try
[13:38] <dednick> kgunn: happens with app-launch as well
[13:38] <Saviq> kgunn, you shouldn't need to ignore twins any more
[13:38] <kgunn> Saviq: ta
[13:38] <Saviq> kgunn, I added the MPs that create the twins now
[13:39] <Saviq> kgunn, but any time you rebuild qtmir or qtubuntu, we'll need to bump the respective -gles MPs and rebuild those afterwards, too
[13:40] <kgunn> Saviq:  yep...got it (bump = empty commit? +reconfig)
[13:40] <Saviq> kgunn, no, just bump https://code.launchpad.net/~saviq/qtmir/gles-sync-20140716/+merge/227000 or https://code.launchpad.net/~unity-team/qtubuntu/gles-qtcomp-refactor/+merge/226870 respectively
[13:40] <Saviq> kgunn, and rebuild
[13:40] <Saviq> kgunn, bump == sync the changelog version with what ends up in the silo
[13:41] <Saviq> kgunn, basically `dch -v $the-non-gles-version`
[13:41] <kgunn> Saviq: oh i see....this is the magic i didn't understand....
[13:41] <Saviq> kgunn, yeah, we just magicked it this morning
[13:41] <kgunn> lol
[13:41] <Saviq> kgunn, basically what happens:
[13:41] <Saviq> kgunn, you build qtmir in silo
[13:42] <Saviq> kgunn, then you prepare an MP for qtmir-gles that adds a changelog entry for the same version the silo gave up for qtmir, and update the silo number in debian/watch
[13:42] <Saviq> kgunn, then you add that MP to the same silo and reconfigure
[13:42] <Saviq> and build -gles
[13:43] <Saviq> kgunn, in case you rebuild qtmir, you need to update the -gles changelog bump and rebuild it as well
[13:43] <kgunn> yep, that all makes sense....so upon a rebuild it'll actually fail for the gles's
[13:43] <kgunn> until you bump/rebuild
[13:43] <Saviq> yeah
[13:44] <Saviq> you always need to build non-gles first
[13:44] <Saviq> kgunn, all this because now -gles packages get the qtmir tarball directly from the PPA
[13:44] <Saviq> kgunn, the -gles bzr branch carries no source, just the debian/ folder
[13:44] <kgunn> yep...i see it in those mp's you linked
[13:45] <Saviq> it's a bit convoluted, but feels sanest and safest, and easiest to follow (because there's an actual branch, with only relevant changes)
[13:45] <Saviq> and no need for manual uploads to the silo and such
[14:01] <kgunn> dednick: silo18 will work for purpose of progress right? i mean its annoying, but guys doing payment service can progress
[14:02] <dednick> kgunn: we ned to update unity8 to set an environment variable. just testing now.
[14:02] <dednick> tvoss: we're going with the env var rather than the hack in unity8 right?
[14:02] <tvoss> dednick, yup
[14:03] <tvoss> dednick, please file a bug to remind us of the todo to clean up
[14:03] <dandrader> Saviq, what's the story with those -gles packages? What do they do? I'm lost...
[14:03] <kgunn> thostr_: ^ one sec, looks like we'll need to add one more mp to that silo
[14:03] <Saviq> dandrader, we need them for the i386 emulator
[14:04] <kgunn> hmmm....
[14:04] <kgunn> dednick: actually, cemil marked mir silo as to be released (which i suppose is actually ok)....should we just get a seperate silo ?
[14:04] <Saviq> dandrader, so they basically are built from the same source that normal packages, but build against GL ES instead of GL (until Qt supports live switching / detection)
[14:05] <dednick> kgunn: yeah, it can be done separately
[14:05] <thostr_> tedg: ^
[14:06] <dednick> just needs a mod to the upstart conf file to use trust sessions
[14:06] <om26er> kgunn, is the qtcomp silo ready  with latest changes ?
[14:07] <Saviq> mterry, re "isn't that what -f is for"... sure, it is, but it will also load fake unity, fake foo, fake bar... and it will change the current behaviour
[14:07] <Saviq> mterry, I basically think, if possible, the default behaviour of ./run.sh at least should be that it doesn't require unlock
[14:07] <tedg> dednick, Can you ping me when that gets a silo.
[14:07] <tedg> ?
[14:07] <dednick> tedg: yup
[14:08] <kgunn> om26er: lemme check
[14:08] <kgunn> om26er: yes
[14:10] <mterry> Saviq, I'm not thrilled with making "the real run.sh" be a half-mock monstrosity, but sure.  easy to do
[14:10] <Saviq> mterry, I'm not thrilled about having to enter my password everytime I run it....
[14:11] <Saviq> mterry, and sure, once we get split greeter, we'd just launch unlocked, but until then it would get really annoying to have to unlock every time
[14:11] <dandrader> Saviq, I don't see anything in lp:qtmir/gles that makes it build qtmir sources differently (like a compile or config argument or something)
[14:11] <dandrader> Saviq, how does that magic happens?
[14:12] <Saviq> dandrader, it's greyback's doing
[14:12] <mterry> Saviq, hrm...  I don't suppose there's a way to do QML2_IMPORT_PATH but for only one module instead of a directory of modules...?
[14:12] <Saviq> dandrader, but the least of it is that it depends on the gles -dev packages http://bazaar.launchpad.net/~mir-team/qtmir/gles/view/head:/debian/control
[14:12] <Saviq> mterry, unfortunately not
[14:13] <Saviq> mterry, but maybe you can abuse nonmirplugins
[14:13] <Saviq> mterry, same as we have the mock Unity.Application
[14:13] <Saviq> mterry, which would kind-of make sense
[14:13] <mterry> kind of...  :)
[14:13] <Saviq> mterry, adverse effect would be an X11 unity session... but no one does that anyway
[14:14] <dandrader> Saviq, ahhh... right!
[14:14] <mterry> Saviq, and if they do, they have a greeter right?
[14:14] <Saviq> mterry, sure, they would (but they don't)
[14:15] <Saviq> mterry, I know what you mean, I understand it's not ideal, but it'll get really really annoying real soon
[14:16] <mterry> Saviq, I always tend to run with -f so I don't know your pain, but I can imagine
[14:16] <Saviq> mterry, yeah, I rarely run with -f
[14:16] <Saviq> and I think most of us do
[14:17] <Saviq> dednick, looks like Mir '
[14:17] <Saviq> 'innit
[14:17] <Saviq> https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1342694/comments/2
[14:17] <dednick> Saviq: yup, that it does
[14:22] <mterry> Saviq, run.sh takes a while on my machine to load up.  It didn't used to.  does that happen for you?
[14:22] <Saviq> mterry, bug #1340086
[14:22] <Saviq> mterry, update / restart telephony-service
[14:24] <mterry> ah great
[14:24] <mhr3> tsdgeos, is your overview branch pushed anywhere?
[14:24] <tsdgeos> mhr3: https://code.launchpad.net/~aacid/unity8/dash_overview/+merge/226449
[14:24] <mhr3> thx
[14:24] <mhr3> i'll try to hack the plugin to do what you need
[14:32] <mterry> Saviq, I'm not thrilled with installing it in nonmirplugins for actual installation, but how do you feel about creating a symlink in builddir/nonmirplugins when using ./run.sh?  It's hacky, but it's a development/testing thing anyway
[14:32] <Saviq> mterry, could work
[14:37] <mterry> Saviq, OK done, let me know what you think
[14:38] <mterry> what happened to the meeting?
[14:38] <mterry> did we do mumble today after all?
[14:39] <Saviq> mterry, hangout!
[14:39] <Saviq> dednick, ↑
[14:39] <mterry> I was there since 20 minutes ago, link must have changed
[14:39] <Saviq> oh you're here ;)
[14:39] <dednick> :)
[14:40] <Saviq> mterry, sometimes it happens that even though you have the same link, you're on a different hangout ;)
[14:43] <mhall119> mhr3: we talked briefly the other day about what it would take to support running scopes using the new APIs against the scopes test tool on Trusty, I need to get a little more information about how much work would actually be involved in that
[14:43] <mhall119> my take-away from that conversation was that it's the test tool itself that needs the most backporting work
[14:44] <mhall119> because it uses some new Unity 8 components that aren't in 14.04
[14:44] <mhr3> mhall119, right, which ultimately means you'd be backporting u8 itself
[14:44] <mhall119> all of it, or just the components that are shared with the test tool?
[14:45] <mhr3> all of it... but of course you could try to separate it completely
[14:45] <mhall119> does the test tool use a separate copy, or does it load them from the same system location as Unity 8?
[14:45] <mhr3> same location
[14:46] <mhall119> if we made a copy of those components that it uses, and shipped backported versions of them with the test tool itself, would that be enough? Or do the components themselves have dependencies that we'd need to backport?
[14:46] <mhr3> Saviq, any idea how complex would it be to separate it and run in T?
[14:47] <Saviq> http://nooooooooooooooo.com/
[14:47] <mhall119> Saviq: why?
[14:47] <Saviq> mhall119, because it's work that we don't have time for for another month at least
[14:48] <mhr3> Saviq, estimate, not asking you to do it
[14:48] <Saviq> mhall119, and it's something that will hinder progress
[14:48] <Saviq> mhr3, estimating is work, too, have no idea
[14:48] <mhall119> what mhr3 said
[14:48] <Saviq> we just use what UITK / Qt 5.3 give us
[14:48] <Saviq> as we can get it
[14:48] <Saviq> all that would have to be backported
[14:49] <Saviq> and there was a plan to use utopic LXC on trusty
[14:49] <Saviq> something that stgraber has shown - he ever ran a utopic unity8 desktop session
[14:49] <mhall119> Saviq: to run a utopic version of the test tool on a trusty desktop?
[14:49] <Saviq> mhall119, yes, just a full utopic environment in LXC
[14:50] <mhall119> I haven't heard of that one yet
[14:50] <mhr3> the question is whether that can be "official" dev story
[14:51] <mhall119> mhr3: taking a different path for a moment, how much work would it be to make the trusty test tool *work* with utopic-targeted scopes, even if it doesn't *look* the same as the utopic Unity 8?
[14:51] <mhall119> just something to let scope devs check that their code is returning results?
[14:51] <mhr3> mhall119, depends... how much can it break trusty's u8?
[14:52] <mhall119> not at all
[14:52] <mhr3> mhall119, then no
[14:53] <mhall119> all I'm after is the ability to start a new scope project on my trusty laptop, run it, and see the sample results the template is giving
[14:53] <mhall119> right now I can't do that
[14:53] <mhr3> mhall119, you can, but only with old api
[14:54] <mhr3> which is pointless anyway
[14:58] <mhall119> I'm guessing the QtC templates are already using the new API then, because it doesn't work
[14:58] <mhall119> creating a new scope project and then immediately running it fails
[14:58] <mhr3> then you're not really running T, are you? you have qtc from a ppa
[14:58] <mhall119> yes, that's the officially supported way to get the Ubuntu SDK
[14:59] <mhall119> everybody using the SDK on Trusty should be getting it from the PPA
[14:59] <mhall119> http://developer.ubuntu.com/start/ubuntu-sdk/installing-the-sdk/
[14:59] <mhr3> then the only option is using the cmd line client :)
[15:00] <mhall119> what is that?
[15:00] <mhr3> tool that sends a query to scope and prints the results it returned
[15:00] <mhr3> of course it isn't integrated with qtc... for obvious reasons
[15:00] <cwayne> wait hold up that exists?
[15:01] <mhr3> cwayne, ofc
[15:01] <cwayne> how did i not know these things
[15:01] <mhr3> cwayne,
[15:01] <mhr3> $ dpkg -S `which scopes-client `
[15:01] <mhr3> libunity-scopes-cli: /usr/bin/scopes-client
[15:02] <mhall119> E: Unable to locate package libunity-scopes-cli
[15:02] <mhr3> mhall119, trusty didn't have it
[15:03] <mhall119> so that's not an option either
[15:03] <mhr3> mhall119, well as you pointed out, latest SDK requires latest scopes lib
[15:04] <mhr3> mhall119, hmm, wait
[15:05] <mhr3> if you were to just update u8's scopes plugin things might actually work... ish
[15:05] <mhr3> mhall119, did you try that?
[15:05] <mhall119> how do I do that?
[15:06] <mhr3> mhall119, install all from ppa:unity-team/ppa
[15:17] <tsdgeos> Saviq: i just pushed search support to dash overview
[15:18] <tsdgeos> have to investigate why search results are not shown on top
[15:18] <Saviq> tsdgeos, kthx
[15:18] <tsdgeos> it's kind of weird
[15:18] <Saviq> greyback, mterry, btw, there's something wrong in the ppa for i386 emulator, it's removing qtubuntu-android for some reason
[15:18] <Saviq> maybe a missing Replaces or so
[15:19] <Saviq> because I can `apt install unity8 qtubuntu-android` and then dist-upgrade and everything's better again
[15:20] <mterry> odd
[15:21] <Saviq> mterry, OTOH it might be because of the lack of qtmir-android in the seed
[15:21]  * Saviq will try to install qtmir-android and then dist-upgrade
[15:24] <greyback> Saviq: the ubuntu-touch package should depend on qtmir-android there
[15:24] <Saviq> greyback, yeah yeah, is what I meant, but that can't happen before qtmir is in distro
[15:25] <Saviq> greyback, good news it's working fine after installing
[15:25] <greyback> ok that's good
[15:25] <Saviq> greyback, but that also means (as I wrote in the email) we need a separate silo for qtmir
[15:25] <Saviq> greyback, or get someone to upload it manually after NEWing
[15:26] <Saviq> only then can we build the updated ubuntu-touch-meta and land it with the silo
[15:26] <greyback> Saviq: so which is the best option you think?
[15:26] <Saviq> greyback, I think we need someone to NEW, copy from PPA to distro manually
[15:26] <Saviq> greyback, then we drop from silo and add ubuntu-touch
[15:27] <Saviq> greyback, no need for a separate silo when the result will be the same
[15:27] <Saviq> greyback, and I assume that's safe is it?
[15:27] <greyback> Saviq: sounds good
[15:27] <mhall119> mhr3: wait, I was wrong, you can break Unity 8 on Trusty for all I care
[15:27] <mhall119> as long as Unity7 works
[15:28] <greyback> Saviq: need to get qtmir fully reviewed and approved, then will let you know, and we can get those wheels turning
[15:28] <mhr3> mhall119, good, cause installing that ppa will break it
[15:28] <Saviq> mhr3, mhall119, I don't think we can have our official dev story to be "be on trusty and upgrade from PPA" either
[15:28] <mhall119> Saviq: that is our official story for apps
[15:28] <Saviq> mhall119, well it's not maintainable
[15:29] <Saviq> mhall119, as our framework grows, the burden of backporting all changes to trusty will be too great
[15:29] <Saviq> mhall119, or it will block progress on the "tip"
[15:33] <mzanetti> cwayne: around?
[15:35] <cwayne> mzanetti: whats up?
[15:35] <mzanetti> cwayne: hey, you don't happen to have that chinese app around still?
[15:35] <mzanetti> cwayne: need to test if the splash screen now works with those chars
[15:36] <cwayne> mzanetti: hm let me find it
[15:38] <dednick> Saviq: can you review quick? https://code.launchpad.net/~nick-dedekind/unity8/trusted-socket.prompt-file/+merge/227051
[15:39] <Saviq> dednick, please unset in post-stop
[15:45] <Saviq> mterry, hmm I wanted to land the approved stuff in unity8, can I land your top-ACKed branches, too, or do you want them in your silo?
[15:47] <tsdgeos> Saviq: ok, slight offset issue fixed
[15:47] <Saviq> tsdgeos, you mean dash overview search?
[15:47] <tsdgeos> Saviq: yeah the results where shown starting at -40 for some reason
[15:47] <Saviq> heh
[15:50] <dednick> Saviq: done. and simplified. doesnt need path apparently.
[15:50] <mterry> Saviq, is-active, dbus-greeter-show, and dialer-above could all land fine.  Though I don't think dialer-above is top-approved
[15:50] <Saviq> mterry, yes, only the first ones
[15:51] <mterry> Saviq, yeah that's great to land
[15:51] <Saviq> dednick, tvoss, don't we generally use =1 for "I don't care about the value"?
[15:51] <tvoss> Saviq, that's fine with me as well ...
[15:51] <tvoss> Saviq, although enabled is a bit more verbose
[15:51] <tvoss> and probably more self-documenting
[15:51] <Saviq> yeah ok
[15:52] <dednick> eh. i just changed to 1 :)
[15:52] <mhr3> tsdgeos, how do i run it to get your test backend?
[15:52] <tsdgeos> mhr3: make tryDash
[15:52] <tsdgeos> from builddir
[15:52] <mhr3> ty
[15:54] <tsdgeos> Saviq: mhr3: so what is supposed to happen in the dash overview search click, preview as in regular scope results or going to that scope?
[15:55] <mhr3> noone knows :)
[15:55] <tsdgeos> \o/
[15:56] <Saviq> tsdgeos, nothing
[15:56] <tsdgeos> i can go home then
[15:56] <tsdgeos> oh wait i'm at home
[15:56] <tsdgeos> :(
[15:56] <tsdgeos> Saviq: nothing? really?
[15:56] <Saviq> tsdgeos, for scopes → go to that scope, other results → nothing
[15:56] <tsdgeos> Saviq: how i know if it's a scope?
[15:56] <mhr3> where nothing == handle that uri
[15:56] <Saviq> mhr3, no, *NOTHING*
[15:56] <tsdgeos> wait what?
[15:56] <mhr3> Saviq, hm?
[15:57] <Saviq> or well, maybe no preview ;P
[15:57]  * Saviq reads
[15:57] <tsdgeos> Saviq: you're telling me there can be something else other than scopes on scopes search?
[15:57] <mhr3> of course
[15:57] <Saviq> heh lol
[15:57] <Saviq> from the spec:
[15:57] <Saviq> The top of the search results page displays information matching the query from Wikipedia (if available). IS THIS INFORMATION TAPPABLE? WHAT WOULD OPEN? WIKI WEBSITE OR SCOPE (IF INSTALLED)
[15:58] <tsdgeos> mhr3: that doesn't make any sense, can you please explain?
[15:58] <Saviq> not very spec-y
[15:58] <Saviq> tsdgeos, that's where smart scope search is being put to die
[15:58] <Saviq> https://f966f709-a-c881af26-s-sites.googlegroups.com/a/canonical.com/unity8dash/scopes/dash-overview/5.results.png?attachauth=ANoY7cq7Hzx_zDg_bCQVcXivoGRrTIMBPTp6Tx9yxsf-vpi4COTzsg9WmreCInC_jsM8qus7aHhn0CzWcowiD1UGu35GuK3TiMemmxoq7Rx6hpOWcRNiOK-N1JUTn3Heml-3DZ-jkSbWr6zE5jLh_pJhknTRk7WpOybeDE1OJS_ZD5Cs0yH3mRwm-HHAG46Bri0tjvL6BadLrocukc_TuXWeJnRRpqvMoPvkVjS8GiW_19YD4FkvK_U%3D&attredirects=0
[15:58] <tsdgeos> wait what? why are we showing random wikipedia information in the dash overview?
[15:58] <Saviq> DAMN google
[15:59] <mhr3> tsdgeos, cause it's a search
[15:59] <mhr3> tsdgeos, ^ no, don't search for logic in that statement
[15:59] <tsdgeos> mhr3: might as well show me emails containing that string
[15:59] <tsdgeos> it's a search!
[15:59] <tsdgeos> so i'll wear a red kilt
[15:59] <mhr3> tsdgeos, i'm sure it will do that at some point
[16:02] <tsdgeos> so i still don't have an answer of what should happen :d
[16:02] <tsdgeos> or rather what i'm supposed to do in onClick
[16:03] <Saviq> dednick, ACK'ed, shall I land?
[16:03] <Saviq> tsdgeos, activate
[16:03] <Saviq> tsdgeos, if it's a scope, open that scope, otherwise activate
[16:04] <tsdgeos> ook
[16:04] <tsdgeos> mhr3: so you send me the scopeId too in the search results right?
[16:05] <mhr3> tsdgeos, too late, you said you don't need it earlier today
[16:05] <tsdgeos> mhr3: i can dig the logs, i'm pretty sure i said i did need it
[16:06] <mhr3> tsdgeos, j/k as i said, i'm adding it everywhere
[16:06] <tsdgeos> ok
[16:21] <dednick> Saviq: yes please
[16:22] <Saviq> dednick, k, silo requested
[16:30] <Saviq> mhr3, lp:~saviq/unity8/initial-see-all fixed
[16:31] <Saviq> ugh
[16:31] <mhr3> Saviq, meant header-links?
[16:31] <Saviq> mhr3, yeah, but I think I pushed ↑
[16:31] <mhr3> uh oh
[16:32] <Saviq> mhr3, nw, fixed
[16:35] <Saviq> greyback, mzanetti, http://pad.ubuntu.com/dash-performance-ideas
[16:40] <mhr3> Saviq, one more thing - if (headerLink) seeAll.visible = false;
[16:41] <Saviq> mhr3, orly, maybe collapsed-rows = 0 instead?
[16:42] <mhr3> Saviq, you mean scope should set that?
[16:42] <Saviq> mhr3, or we do
[16:42] <mhr3> Saviq, no, scope might want specific number of rows, but doesn't know how many items per row are there
[16:43] <Saviq> mhr3, hmm k
[16:44] <mhr3> Saviq, fwiw i already had confirmation from mike that there's either header link or see all, never both
[16:44] <Saviq> mhr3, yeah I know
[16:45] <mhr3> hm... although it will be weird cause you'll be able to get those hidden results in preview
[16:52] <Saviq> mhr3, indeed
[16:52] <kgunn> Saviq: curious, for making scopes customizable, is that limited to oem's ? or can any scope writer use the hooks for customizing ?
[16:52] <Saviq> mhr3, maybe we should filter the preview model for that case
[16:53] <Saviq> kgunn, yeah, misnomer
[16:53] <Saviq> kgunn, it's scope customization, nothing to do with OEM really
[16:53] <mhr3> kgunn, is that about the ml thread?
[16:53] <kgunn> Saviq: yeah, i was about to clarify my mail y'day
[16:53] <kgunn> just wanted to be accurate
[16:54] <mhr3> kgunn, scope can set dash background, user can't
[16:54] <kgunn> ....and as part of that, i know of no plans to bring back user setting background
[16:54] <kgunn> mhr3: thanks for the confirmation
[16:54] <kgunn> exactly what i was gonna clarify
[16:55] <mhr3> Saviq, isn't the preview model just a copy of results model?
[16:55] <mhr3> but yea, sure filtering that would do the trick
[16:56] <mhr3> Saviq, unless it's a carousel with header link :)
[16:59] <Saviq> mhr3, yeah, I'll have a look-see tomorrow
[17:00] <Saviq> o/
[17:14] <dandrader> kgunn, the silo is missing the latest qtubuntu and platform api. build seems to have failed due to some missing build deps....
[17:14] <kgunn> dandrader: ok, lemme look
[17:18] <kgunn> dandrader: ok....last handful of builds for that silo have succeeded, there's a 2 day old platform-api package set and 2 day old qtubuntu
[17:18] <kgunn> i know greyback has been building targeted packages (unity8 or qtmir only etc)
[17:18] <kgunn> dandrader: so are you specifically needing those to be rebuilt ?
[17:19] <dandrader> kgunn, yes platform-api and qtubuntu. well I'm building them myself locally now but it would be nice to have them up-to-date in the silo
[17:19] <kgunn> dandrader: ok, i'll kick it off...
[17:20] <dandrader> kgunn, as it would contain the papi API renaming that ricmm asked
[17:20] <kgunn> dandrader: just platform-api & qtubuntu ? or any other packages ?
[17:20] <dandrader> kgunn, just those
[17:20] <kgunn> ok, greyback & mzanetti fyi ^
[17:20] <greyback> ack
[17:21] <greyback> kgunn: unity8 has had some more small fixes, could include that
[17:22] <kgunn> ack and included
[17:24] <kgunn> dandrader: note, it'll be a 2 step build, i gotta build the twin for qtubuntu
[17:43] <Saviq> kgunn, fyi the twin packages only affect i386 emulator
[17:54] <mhall119> Saviq: I updated to image 133, now I have 2 "Recent" sections one with thumbnails or running apps and one with 6 launchers
[17:54] <mhall119> the launchers don't seem to change with actual app usage
[17:57] <Saviq> mhall119, bug #1341713
[18:16] <Saviq> mhall119, on the SDK topic, I believe Jolla's approach to supply the SDK as a VirtualBox VM gets you really high return rate
[18:16] <Saviq> mhall119, we could do the same, and slightly modify that approach to also support lower overhead with LXC
[18:24] <mhall119> Saviq: we could, but we also want to support desktop development, which Jolla doesn't have to concern themselves with
[18:24] <Saviq> mhall119, well, yes, but for desktop development you develop on the platform you target
[18:25] <Saviq> mhall119, meaning that if you target trusty, you develop on trusty, if you target newer releases, you develop on newer releases
[18:26] <mhall119> Saviq: yes, and that's the plan
[18:26] <Saviq> mhall119, then why are we talking about developing for utopic phone on trusty?
[18:26] <mhall119> the issue right now is that you can't target trusty for scopes, and you can't run then on utopic in a vm
[18:26] <kgunn> Saviq: ack,  so i can ignore twins until the end (when we land)
[18:26] <Saviq> you can't? why?
[18:26] <Saviq> kgunn, more or less, yes
[18:27] <mhall119> Saviq: I'm looking for the easiest/fastest way to support scope development from trusty
[18:27] <mhall119> Saviq: 1) the SDK is broken, but even when it's fixed 2) you can't run the scopes test tool in the emulator
[18:28] <Saviq> mhall119, right, not in emulator, but you could run it in a utopic chroot/container with little problem
[18:28] <mhall119> Saviq: then that might be our best solution
[18:28] <Saviq> mhall119, you could even run QtCreator out of that, to basically get a utopic QtCreator on your trusty desktop
[18:35] <kgunn> dandrader: were you messin' around with input ?
[18:35] <kgunn> https://launchpadlibrarian.net/180089781/buildlog_ubuntu-utopic-armhf.qtubuntu_0.60%2B14.10.20140716-0ubuntu1_FAILEDTOBUILD.txt.gz
[18:36] <dandrader> kgunn, you've to build platform-api *before* qtubuntu
[18:37] <kgunn> dandrader: ok...yeah, out of order, restart qtubuntu now
[18:37] <dandrader> kgunn, that error is because the new qtubuntu is still using the old platform-api
[19:12] <kgunn> dandrader|afk: we're good to go, packages built
[19:12] <kgunn> greyback:  ^ if you're using
[19:12] <kgunn> mzanetti: ^
[19:13] <mzanetti> cheers
[19:15]  * kgunn goes to flash
[20:07] <dandrader> kgunn, thanks
[20:16] <kgunn> dandrader: greyback mzanetti...oh man, smooth & fast....love it....let's land it!
[20:22] <greyback> kgunn: that comment makes me happy, thank you
[20:26] <kgunn> greyback: really really great job guys
[20:26] <kgunn> josharenson: i still want #s ^  ;)
[20:31] <josharenson> kgunn, of course :-)
[20:31] <josharenson> but this is good to hear
[20:33] <josharenson> kgunn, might not be as important _now_, but I wanted to discuss the specific use cases you were concerned about, just to make sure we're on the same page
[21:28] <josharenson> Does "ubuntu-app-launch" work? Not sure if its broken or I'm using it wrong.
[21:32] <josharenson> ok, I made it kind of work...
[21:47] <greyback> josharenson: you need to give it the exact app id, else it fails. Getting exact appId not the easiest thing in the world sadly
[21:48] <josharenson> greyback, I see that... would be nice if you could just use the output from 'click list'
[21:48] <greyback> josharenson: indeed. Wonder if that's worth suggesting actually
[21:49] <greyback> tedg: is there any easy way to get appIds that are installed on the system?
[21:49] <greyback> ubuntu-app-launch not that useful if you can't easily find appIds
[21:50] <tedg> greyback, Eh, not formally. But you can do an: ls ~/.cache/ubuntu-app-launch/desktop/
[21:50] <tedg> greyback, And ubuntu-app-triplet will turn package names into appids.
[21:52] <greyback> tedg: there is not a 1-to-1 connection between package names and appIds though, is there?
[21:52] <tedg> greyback, Not always, but largely.
[21:53] <tedg> This is kinda fun: click list | cut -f 1 | xargs -n 1 ubuntu-app-triplet
[21:53] <tedg> Really want to get to making a UAL bash autocomplete script, but haven't found the time.
[21:54] <greyback> tedg: ubuntu-app-list would be nicer
[21:55] <tedg> Than autocomplete? You'd get the same functionality with "ubuntu-app-launch <tab><tab>"
[21:55]  * tedg loves autocomplete
[21:55] <greyback> that can be step 2, but step 1 would be an easy way to list the apps that I have installed
[21:55] <greyback> kinda hard to script <tab><tab>
[21:56] <tedg> Hmm, I'd hope scripts would be more specific than just "all the apps I have installed"
[21:58] <greyback> I try to maintain the philosophy that it's better to give users the data than not to. If they shoot themselves in the foot, it's their own fault, but at least they can if they want to
[21:59] <tedg> Well, right now all the data is the there, there's just a greater barrier to getting it than you want to overcome :-)