[01:25] <nemo> mcphail: pong
[01:26] <nemo> hm bit late sorry, but did you get a verbose log?
[02:31] <mcphail> nemo: if it is helpful, http://paste.ubuntu.com/12412453/ is all I got. Off to bed now
[02:40] <nemo> kk
[02:40] <nemo> gn
[07:10] <dholbach> good morning
[08:01] <aquarius> appdevs, I'm trying to build an app and am having problems with cmake stuff; http://paste.ubuntu.com/12416080/ shows the error, and indeed "/var/lib/schroot/chroots/click-ubuntu-sdk-14.10-armhf/usr/lib/arm-linux-gnueabihf/qt5/bin/moc" does not exist. What do I need to install to get it?
[08:30] <aquarius> ah, fixed
[08:30] <mcphail> what was the problem?
[08:31] <mcphail> (I'd have thought moc would be installed by standard in the chroots...)
[08:31] <aquarius> so would I
[08:32] <aquarius> apt-get install qtbase5-dev-tools:armhf got what was needed
[08:32] <mcphail> maybe worth a bug report?
[08:34] <aquarius> no idea whether it's a bug, or my setup, or what. A bug report would be useless; I can't report back on whether a fix fixed it
[08:35] <aquarius> currently being frustrated by: "lint_hooks_multiple_apps: more than one desktop app specified in hooks"
[08:35] <aquarius> which is a stupid error because it's preventing me from building a package which works fine!
[08:35] <mcphail> aquarius: yes - these appear to be banned
[08:35] <aquarius> yes, I'm specifying more than one desktop app because I have more than one desktop app in my package, which works fine and is allowed!
[08:37] <mcphail> aquarius: I did work out an exploit for the multiple apps thing, so they are probably banned for good reason
[08:39] <mcphail> aquarius: http://themcphails.uk/leakytrust.njmcphail_0.1_armhf.click is an example where you can leak information from one trusted app to another which has network permissions
[08:41] <mcphail> (open the trusted one then the malicious one and look at the logs)
[08:42] <aquarius> indeed. The point of having multiple apps is that they can share information.
[10:00] <mcphail> aquarius: yes, but the problem is the multiple apps don't have to have the same security permissions, hence information can leak/be leaked from an app the user trusts
[10:47] <t1mp> what should happen when an app changes the height of the header? should it always show?
[10:49] <aquarius> t1mp, I don't think I can see why changing the header height should change its behaviour?
[10:52] <t1mp> aquarius: well there are some corner cases, for example to expose the header you have to drag the linked flickable for at least half of the header's height
[10:53] <t1mp> aquarius: so increasing the header height might bring you in a state where you cannot easily expose the header by dragging any more
[10:53] <t1mp> I could just check for that case
[10:53] <aquarius> You can legitimately limit the header's height so it can't be any more than, say, 50% of screen, I would think
[10:53] <t1mp> and in other cases keep the header hidden/exposed as it was before changing the header height
[10:53] <aquarius> since a header which is 60% of my screen is in no meaningful way a header :)
[10:54] <t1mp> aquarius: I'm working on a new Header component that app developers may want to abuse in ways that I did not consider useful
[10:54] <aquarius> also, I think that the amount you drag the flickable down to show the header ought to not vary with the header's height but with the screen's height, myself
[10:55] <t1mp> aquarius: currently when you drag the flickable, the header will move the same amount as the flickable
[10:55] <aquarius> yup
[10:55] <t1mp> aquarius: and when you release, the header will show/hide depending on whether it is more or less than half open
[10:55] <aquarius> and when a certain amount of the header has been pulled on screen, it will then be in "I get shown" mode when you let go, agreed
[10:56] <aquarius> but I think that the "certain amount" should be min(header.height/2, screen.height/10)
[10:56] <t1mp> aquarius: currently the certain amount is header.height/2, and nobody complained about it yet
[10:56] <aquarius> so I don't have to pull a large header further onto screen before it shows
[10:56] <aquarius> yeah, but nobody sets the header to be large, at the moment :)
[10:56] <aquarius> I didn't even know you *could* set the header height!
[10:57] <aquarius> and this is only a concern for large headers, right?
[10:57] <t1mp> aquarius: you cannot now, the new Header will be an Item that you can size the way you want
[10:57] <aquarius> *nod*
[10:58] <t1mp> aquarius: another issue is that if the flickable contentHeight is not much bigger than the flickable height, then its amount of flicking is limited, maybe less than header.height/2 or screen.height/10
[10:58] <aquarius> t1mp, and there's also a problem if the flickable is not the screen height
[10:58] <aquarius> that is: you have a header, then a flickable, then a static thing at the bottom of the screen
[10:59] <t1mp> that should work fine
[10:59] <aquarius> if the flickable can't be flicked the amount needed to make the header appear, then I'd say: the header always shows :)
[10:59] <t1mp> the header should not be above the flickable in y-direction though, but overlay it (in z-direction)
[10:59] <aquarius> mm... sorta
[10:59] <aquarius> I *constantly* have issues with that because the stuff at the top of my flickable ends up under the header :(
[11:00] <t1mp> brb, meeting
[11:33] <t1mp> aquarius: the header supposedly sets the topMargin of the Flickable to avoid that. When do you have problems with it?
[11:52] <aquarius> t1mp, next time I run into the issue I'll ping you about it and see what I'm doing wrong
[11:53] <t1mp> aquarius: ok, thansk
[11:53] <t1mp> *thanks
[11:53] <aquarius> Is it actually the truth that multiple apps in one click package are banned?
[12:01] <davmor2> popey: in the reminders app you setup for testing can you switch to local storage and try and set a reminder on a note please, I get a blank time and date wheel
[12:03] <popey> davmor2: ok, let me try
[12:06] <popey> http://people.canonical.com/~alan/screenshots/device-2015-09-15-130552.png
[12:06] <popey> wfm
[12:07] <davmor2> popey: cool might just be an issue here then I'll do a fresh install and see if something got screw up after Lunch
[12:07] <cwayne> aquarius: don't think so, i've got some in the store like that (well, a scope and a webapp in one click)
[12:08] <aquarius> cwayne, scope + app works, but two apps throws a lint error :(
[12:09] <aquarius> *and* there's no way to hide an app from the apps scope, either :(
[12:09] <cwayne> yeah, thats obnoxious
[12:31] <aquarius> cwayne, hence asking :)
[12:32] <cwayne> i hadnt realized of the lint errors, just that we couldnt hide apps :)
[12:39] <kenvandine> mzanetti, i pushed another revision of my twoeleven branch that updates all the sdk usage to 1.3 and fixes the UbuntuShape deprecation
[13:00] <mzanetti> kenvandine, thanks!
[13:03] <mzanetti> kenvandine, cann you please propose a MP with that branch?
[13:04] <kenvandine> mzanetti, i can't for +junk branches
[13:04] <kenvandine> i tried that last night :)
[13:05] <kenvandine> mzanetti, you should create a project for that
[13:05] <mzanetti> oh... right
[13:05] <mzanetti> :D
[13:40] <davmor2> popey: Meh fresh install and I still get this http://people.canonical.com/~davmor2/no-date.png
[13:41] <davmor2> popey: works in the clock app I assume it is the same element?
[13:42] <popey> hmmm
[13:44] <popey> davmor2: you're right, I had the wrong version of the click.
[13:45] <popey> mzanetti: ^
[13:46] <popey> davmor2: its only a problem on rc-proposed, on retail device it's fine
[13:47] <mzanetti> wat?
[13:48] <mzanetti> popey, is this a real problem?
[13:48] <popey> well, I can only reproduce it on rc-proposed which says it's probably a UITK issue
[13:48] <mzanetti> fwiw, don't see it here
[13:48] <popey> it's fine on my retail phone
[13:48] <mzanetti> I use rc-proposed
[13:49] <popey> davmor2: what you using?
[13:49] <davmor2> rc-proposed
[13:49] <davmor2> ubuntu-device-flash touch --bootstrap --channel ubuntu-touch/rc-proposed/meizu.en --recovery-image recovery-arale.img
[13:49] <popey> I'm on krillin
[13:49]  * mzanetti on bq
[13:50] <mzanetti> does this onlyhappen with the qs-submitted click package or also with the publised one?
[13:50] <davmor2> no idea let me reflash
[13:51] <popey> lemme downgrade it on my phone to see
[13:53] <popey> version from the store on my rc-proposed phone is fine
[13:56] <davmor2> mzanetti: so the version on rc-proposed works as expected
[13:59] <popey> and if you upgrade, it breaks?
[14:02] <davmor2> popey: yeap
[14:02] <popey> davmor2: any chance you can file a bug and paste the app log file?
[14:03] <davmor2> popey: sure let me try stable first though
[14:03] <popey> kk
[14:04] <popey> if you could finish the QA and let us know if there's any other issues or if that's the only issue, that would be magic
[14:04] <davmor2> popey: will do
[14:08] <popey> thanks!
[14:12] <davmor2> popey, mzanetti: so it is working fine on stable.  I have a theory is rc proposed using 1.3 of the uitk and stable using 1.2?
[14:14] <popey> i see same version on both devices
[14:15] <davmor2> popey: so not that then
[14:31] <mzanetti> davmor2, it is using 1.3
[14:31] <mzanetti> davmor2, but on stable too ;)
[14:31] <mzanetti> davmor2, might mean 1.3 broke on rc-proposed
[14:32] <davmor2> mzanetti: yeah figured that out now it was just the only difference I could think of
[14:35] <mzanetti> davmor2, there's an upgrade to my phone... doing that now
[14:35] <mzanetti> let's see if I start hitting this
[14:36] <davmor2> mzanetti: I'm on image 113
[14:36] <mzanetti> those numbers are random to me
[14:38] <davmor2> mzanetti: http://paste.ubuntu.com/12417883/
[14:39] <mzanetti> still not happening for me
[14:41] <mzanetti> davmor2, I might have spotted an issue from that log you pasted
[14:43] <davmor2> mzanetti: \o/
[14:52] <mzanetti> popey, can you please test it with this branch on a device where you can repro the issue: https://code.launchpad.net/~mzanetti/reminders-app/align-imports/+merge/271139
[14:52] <mzanetti> davmor2, ^
[14:56] <popey> mzanetti: yes.
[14:56] <popey> just building now
[14:56] <mzanetti> thanks
[15:00] <davmor2> meh sorry screen had blanked while I looked at the rest of the app, thanks popey
[15:11] <popey> mzanetti: nope, same issue
[15:12] <mzanetti> ok... I'm lost them... can't repro...
[15:12] <popey> file:///usr/lib/arm-linux-gnueabihf/qt5/qml/Ubuntu/Components/Pickers/1.3/DatePicker.qml:592: TypeError: Cannot call method 'resetPicker' of null
[15:12] <mzanetti> that's an issue in the Picker itself
[15:12] <popey> ok
[15:33] <carlduke> check out my project IntelligentSecurity on github!! https://github.com/charslab/IntelligentSecurity
[15:33] <carlduke> its for ubuntu!
[15:33] <carlduke> facial recognition for security :D
[15:51] <balloons> ahayzen, ping
[15:51] <ahayzen> balloons, pong
[16:48] <davmor2> popey: I just realised it is the same on desktop already :(
[16:58] <popey> davmor2: "yay"
[17:12] <popey> davmor2: so, do we get a pass then?
[17:13] <davmor2> popey: nope can't create an account from the app, you tap the button nothing, was stuck in meetings so picked up again now
[17:14] <davmor2> popey: infact it crashes the app I can't do anything now :(
[17:14] <davmor2> back after tea
[17:18] <popey> kk
[17:55] <davmor2> popey: there is definitely something screwy going on here.  Because I selected no to the initial asking of setting up an account, when I go into the menu and select the add account button the ui hard freezes all I can do is close the app
[18:41] <davmor2> popey, mzanetti: https://bugs.launchpad.net/reminders-app/+bug/1496084 https://bugs.launchpad.net/reminders-app/+bug/1496086
[18:44] <davmor2> popey, mzanetti: oooohhhhh that's interesting, I just noticed checking against my ota6 device,  ON ota 6 if I goto settings→accounts evernote accounts shows notes,  on 0.5.490 it shows as com.ubuntu.reminders_reminders  I wonder if that is having any adverse effects on things like apparmor
[18:51] <aquarius> rschroll, well... it all works, here, as far as I can tell. The basics, anyway. Rock.
[18:53] <davmor2> popey, mzanetti: Bingo syslog is showing a load of apparmor DENIED's
[18:55] <kivi> popey, hey is the competition still on? I want to submit my app I've been working on
[19:22] <aquarius> rschroll, also, the absolute-path-to-container-icon trick works too, although it is (again) rejected by lint, so we may not be actually able to do it
[19:31] <aquarius> rschroll, and they have semi-good reasons to reject it, too, admittedly.
[19:48] <rschroll> aquarius: Even if we get it in place with the absolute paths, I suspect the UI does its own caching.  Who knows when the updated image would actually be shown
[19:48] <aquarius> rschroll, this is true, actually
[19:49] <aquarius> rschroll, was nice to see that it worked, but I don't think it's a goer for us...
[19:49] <aquarius> rschroll, I think you're right though that we should give them all distinct icons so visual recognition kicks in
[19:50] <aquarius> annoyed that it can't be dynamic. It seems that people *want* dynamic icons -- the calendar and clock apps, for example -- and there may be some work going on to make that happen, and if it does we can take advantage of it
[19:51] <rschroll> With Beru, I've already done work on generating sensibly spaced colors.  We can probably use that to generate icons with the same pattern and different colors for all the containers.
[19:52] <rschroll> Scopes question for the floor: Is it possible to alter a result in an ActivationQueryBase::activate, to change the URL to be activated?
[19:53] <rschroll> Alternatively, is it possible to launch a URL from a scope programatically?
[19:54] <aquarius> t1mp, do you know about scope stuff? or is that all michi?
[19:56] <aquarius> mzanetti, do you know about the scope api?
[19:57] <mzanetti> depends on what
[19:57] <mzanetti> I have an idea... but not in detail
[19:57] <aquarius> mzanetti, see rschroll's question above, which we're trying to do :)
[19:59] <mzanetti> hmm... I think altering the result set should be possible, yes. haven't ever tried myself
[19:59] <mzanetti> launching programmatically should be possible too I think. however your code is only triggered on user interaction...
[19:59] <rschroll> I've tried result().set_uri(), but that doesn't seem to do anything
[20:00] <rschroll> I worry that it's operating on a copy
[20:00] <rschroll> What's going on in more detail:
[20:01] <rschroll> I have a result with a URL to be launched.  But when the result is activated, I want to run code in the activation handler to change that URL, to launch another app.
[20:01] <rschroll> I haven't been able to alter the uri, as noted above.
[20:01] <mzanetti> erm... why not just give the real target in the first place?
[20:02] <rschroll> We're planning an array of webapp containers, and we want to target a free one.
[20:02] <rschroll> The list of free containers may change between when the results are prepared and one is activated
[20:09] <aquarius> rschroll, I have had a thought. One can't start an app other than from the scope. So all that can happen in between the results being prepared and a result being activated is that the user kills one or more containers from the app switcher, right? But if that happens it doesn't invalidate the URLs because all that can happen is that the container we were targeting is now free?
[20:11] <rschroll> Suppose we launch one bookmark, switch back to the scope, and launch another.  I don't think the scope will refresh its results in between
[20:12] <rschroll> So all bookmarks other than the 15 most recent will be trying to use the same container, and will clobber each other until the scope is refreshed
[20:12] <aquarius> aah, yes. Unless we can command a refreshed query when an app is launched
[20:13] <aquarius> (which would also involve "run code after a thing is tapped on", although it wouldn't need access to the chosen URL)
[20:13] <rschroll> I've got code running as a result of the icon being selected.  (That's the activation function I mentioned.)
[20:14] <aquarius> ah, cool. Can that code clear the existing query or refresh it or something?
[20:14] <aquarius> or does that have the same "you don't have access to it from there" issue that ovewriting the URL does?
[20:15] <rschroll> We can perform a new query, which ought to refresh the list.  But I don't think we can do that and have the existing URL still load.
[20:15] <rschroll> Those are two different return codes for the function
[20:15] <aquarius> darnit
[20:17] <aquarius> mzanetti, who knows about this stuff in detail? I've sorta lost track. Is it just michi?
[20:21] <mzanetti> aquarius, alecu perhaps
[20:22] <aquarius> good thought.
[20:22] <aquarius> alecu, ping! also, long time no see :)
[20:23] <alecu> Hello!
[20:23] <aquarius> heya alecu :)
[20:23] <alecu> Hey there, sil
[20:24] <t1mp> aquarius: I don't know about scope stuff
[20:24] <aquarius> t1mp, no worries -- we have summoned alecu :)
[20:24] <t1mp> ok :)
[20:24] <aquarius> alecu, see the scrollback for our question
[20:25] <t1mp> kalikiana, zsombi: about the Header API https://docs.google.com/document/d/1wUUKtPmRmwbUELC1BUB9l0VOAwS_zAPRSCqMopUxR1c/edit# ,
[20:25] <alecu> Sure, catching up with scrollback now
[20:25] <t1mp> ^I think I can drop the locked property completely. You can simply not set a flickable..
[20:25] <t1mp> I don't see a use case where that doesn't work
[20:26] <t1mp> anyway what 'locked' does now is disconnecting the flickable
[20:31] <kalikiana> t1mp: say you do have a Flickable but want it to be "locked" at one point, could interactive:false be sufficient?
[20:31] <t1mp> kalikiana: flickable.interactive? then you cannot scroll the flickable any more
[20:31] <kalikiana> hmmm no forget that, that makes no sense
[20:31] <t1mp> kalikiana: header.flickable = null will lock the header
[20:31] <kalikiana> yeah
[20:32] <t1mp> an unlocked header means that it scrolls with the flickable
[20:32] <kalikiana> so what matters is there's a way to stop the header from knowing about it
[20:32] <t1mp> having the unlocked property requires additional code (to disconnect from the flickable) and tests
[20:32] <t1mp> kalikiana: just set header.flickable = null, or header.flickable = yourFlickable to enable scrolling
[20:33] <kalikiana> yeah, or even a simple binding if needed
[20:33] <kalikiana> that is pretty fine
[20:34] <t1mp> cool :)
[20:34] <kalikiana> it will still need tests, though ;-)
[20:35] <t1mp> kalikiana: I write the tests before I add the functionality :)
[20:40] <aquarius> alecu, let us know if the question doesn't make sense :)
[20:40] <rschroll> (I think we scared him off.)
[20:41] <aquarius> I think I still owe him a pint from last time I was in Buenos Aires :)
[20:41] <alecu> lol
[20:42] <alecu> aquarius: I think rschroll is right: there's no way to update an existing result set so far. The only way is to force a refresh, but I don't recall if that's available for every scope
[20:43] <alecu> the click scope does so via a dbus signal to the scopes-shell, that ends up redoing the scope query
[20:45] <alecu> rschroll: aquarius: lines 68 and 69 here: http://bazaar.launchpad.net/~ubuntuone-control-tower/unity-scope-click/trunk/view/head:/bin/install-helper#L68
[20:46] <aquarius> hm.
[20:46] <aquarius> I bet we can't do that :)
[20:46] <alecu> this warrants a bit of explaining...
[20:47] <alecu> since scopes can be killed at any point, we can't do the download of the app from the click scope. So, we ask download manager to do it. And install-helper is a script that's run when the download is completed
[20:47] <alecu> and it also asks the click scope to refresh.
[20:48] <alecu> both the "installed apps" scope, and the "ubuntu store" scope.
[20:49] <rschroll> Can that be done with arbitrary scopes, or are those two special?
[20:49] <alecu> rschroll: I've read the backlog, but I'm still not understanding your use case
[20:49] <aquarius> how does the scope start the download manager? does the scope do it with code, or does the scope provide URLs for packages which look like magicdownloadmanagerurl://?package=http://click.ubuntu.com/whatever ?
[20:50] <alecu> rschroll: I don't know about that bit. I suspect that there might be some dbus apparmor limitation on that, and install-helper not being affected by that.
[20:50] <alecu> aquarius: with the download manager client library.
[20:50] <rschroll> alecu: aquarius and I are working on a scope that launches webapps in their own containers
[20:51] <rschroll> We have a collection of containers to use and want to launch into an empty (or recently idle) container on activation.
[20:51] <alecu> aquarius: startDownload here: http://bazaar.launchpad.net/~ubuntuone-control-tower/unity-scope-click/trunk/view/head:/libclickscope/click/download-manager.cpp#L130
[20:51] <alecu> rschroll: nice
[20:51] <rschroll> The list of which are in use can change between query evaluation and result activation
[20:52] <rschroll> So we want to change the uri at activation time to use the correct container
[20:52] <rschroll> I can run code at activation with ActivationBase::activate(), but I haven't been able to alter the uri or trigger another uri to be opened
[20:53] <rschroll> Another alternative to is to force a refresh of the query whenever a container is opened, so the container to be used isn't stale.
[20:53] <rschroll> (Thus the questions about refreshing)
[20:53] <alecu> rschroll: what about not including the container id in the result set, and instead trying to find the available container in whatever is handing the opening?
[20:54] <rschroll> That's another possibility, but it involves opening two apps (perhaps)
[20:54] <rschroll> triggering the right one right away would be faster
[20:54] <aquarius> alecu, the thing which handles the opening *is* the chosen container. If we had another app which handled the opening then you'd see that other app open and then immediately the chosen container would open, which looks horrible and doubles our container startup time ;)
[20:56] <alecu> what's a "container" in this context? a browser-like qml app?
[20:56] <aquarius> yup
[20:56] <aquarius> there are 16 of them pre-defined.
[20:57] <aquarius> we want to choose one of them which is currently empty, or the least recently used one
[20:57] <aquarius> we can work out which one is least recently used when the scope is opened
[20:57] <alecu> aquarius: and they will all be shown in the right-side spread? they are running apps after all
[20:57] <aquarius> yup
[20:57] <aquarius> that's why they are separate pre-defined containers.
[20:58] <aquarius> if we work out which container is least-recently used when the user opens the scope (let's say it's container 6) so all the URLs look like container6://some-bookmarked-webapp.com, then that's fine -- choosing any web app will open it in container 6
[20:59] <aquarius> but if the user then switches *back* to the Dash and chooses *another* webapp, the query will not have been refreshed, so all the URLs will still be container6:// and we don't want them to be, because that container is in use now.,
[21:00] <aquarius> so what we want to do is decide which container is least-recently-used *after* an app is tapped, rather than when we get the list of apps to show.
[21:03] <alecu> aquarius: I'm going to assume this something you guys don't plan to upload to the store as a regular click.
[21:04] <alecu> aquarius: in that case, you may use a special apparmor profile to allow talking dbus and refreshing the query after each container is activated with a new url
[21:07] <rschroll> How would that work?  Does the scope need special code, or would the container be talking to unity8?
[21:07] <aquarius> alecu, absolutely not. This is absolutely intended to be in the regular store, from my perspective at least.
[21:07] <rschroll> We'd need an exception for multiple desktop files, but that's all right now.
[21:08] <aquarius> yup
[21:08] <aquarius> (and I am talking to people about that)
[21:08] <alecu> ah, I see.
[21:08] <aquarius> saying "you can write an app which works like this, but actual normal people can't have it" is avoiding the problem ;-)
[21:08] <alecu> aquarius: there's always the open store... :-)
[21:08] <aquarius> "actual normal people". :)
[21:09] <aquarius> "The scope starts a helper app which then starts the appropriate container" will obviously work, it's just a terrible user experience
[21:09] <rschroll> aquarius: I may have a work around.  It's a little bit complicated, but shouldn't be too bad.
[21:09] <rschroll> The scope would just code a fixed container for all but the recently-used apps.
[21:09] <aquarius> unless it's possible to have a helper app which can be started by URL and which can itself start URLs but which presents no UI, which I bet it isn't :)
[21:10] <rschroll> If a container is started, it just runs.
[21:10] <rschroll> If a container receives a URL, it checks, using the same algorithm as the scope, if it was the right one to receive that URL.
[21:10] <rschroll> If it was, it loads it.
[21:10]  * aquarius asks tedg the no-ui question :P
[21:11] <rschroll> If it wasn't, then we chain to the right one.
[21:11] <rschroll> This means only one app start-up per launch
[21:11] <rschroll> There may be a flicker of the first container if we have to transfer
[21:11] <aquarius> so... basically we have the helper app, we just build it into every container?
[21:12] <rschroll> yeah
[21:12] <aquarius> tedg says that if you have a helper app which itself starts the right container that it will probably start and pass on fast enough that you won't notice it
[21:13] <alecu> stress on *probably*
[21:13] <aquarius> so that'd work, if an app can be url-dispatched but not have a .desktop file...?
[21:13] <tedg> alecu: I'm talking non-QML here :-)
[21:13] <alecu> :-)
[21:14] <alecu> aquarius: remember that you can set some flag on .desktop files so they are hidden from the app scope
[21:14] <aquarius> ah, we need a desktop file so the urldispatcher knows which executable to start
[21:14] <aquarius> and the helper app would have to explicitly quit after it sent out the new URL
[21:14] <aquarius> which is a shame, because if it could stay running then it wouldn't incur any startup cost
[21:14] <aquarius> but if it stays running, it'll appear in the launcher.
[21:15] <aquarius> rschroll, so, we have two options there -- separate helper app, or helper app built into each container
[21:15] <tedg> aquarius: It doesn't have to quit explicitly, it'll just get suspended.
[21:15] <aquarius> tedg, if it doesn't quit, it will appear in the launcher
[21:15] <tedg> aquarius: If it is small enough, it'll run forever.
[21:15] <aquarius> but can't be switched to, because it has no UI
[21:16] <aquarius> thus, a launcher button which doesn't do anything, which is horrid
[21:16] <tedg> If it gets switched to it could go to the scope
[21:16] <tedg> scope://webappsscope
[21:16] <aquarius> yeah, but that's not a solution, that's "well, this bad thing has happened, so how can we make the best of it" :-)
[21:16] <aquarius> but that's possibly a workable idea!
[21:17] <aquarius> rschroll, is that (a) a neat little hack or (b) terrible?
[21:17] <rschroll> Those are not distinct
[21:17]  * aquarius laughs
[21:17] <rschroll> To get good startup time, this would need to be compiled
[21:18] <aquarius> yup
[21:18] <rschroll> Is there a C or C++ API for the URI handler?
[21:18] <tedg> Yeah, liburl-dispatcher is what the QPA uses.
[21:18] <rschroll> thanks
[21:18] <tedg> Oh, and for the running app stuff you can use GApplication
[21:19] <tedg> Might be easier to export that one endpoint on your own though.
[21:19] <tedg> YMMV
[21:19] <aquarius> rschroll, if we were going to do the absolute-icon-path thing then the helper app would be the thing which sets the icons :) But we aren't
[21:19] <alecu> here's how to hide all those 16 .desktop files from the apps scope: http://bazaar.launchpad.net/~ubuntuone-control-tower/unity-scope-click/trunk/view/head:/libclickscope/click/interface.cpp#L110
[21:19] <alecu> "NoDisplay: true"
[21:20] <aquarius> alecu, we're setting OnlyShowIn=Old atm; is there a better way?
[21:20] <aquarius> rschroll, huh. Our desktop file has NoDisplay in it, but commented out; did you do that?
[21:20] <alecu> yeah, that works too.
[21:20] <rschroll> alecu: NoDisplay=true breaks the url-dispatcher
[21:20] <rschroll> because obviously
[21:20] <aquarius> :D
[21:20] <alecu> I see you guys are way deep into the hack :-)
[21:21] <alecu> let me know if I can help with anything else, and I'm definitely looking for suggestions on how to improve the scopes api, or the scopes api docs
[21:21] <aquarius> way to improve the scope API: let us overwrite the chosen URL after click. :)
[21:22] <aquarius> cheers for the help, alecu :)
[21:23] <alecu> what I think it's not clear from the docs is that the scopes are stateless, and that these kind of things go against their own nature :-)
[21:23] <aquarius> we're stateless too!
[21:23] <alecu> hmmm
[21:23] <rschroll> yeah, but the device isn't
[21:25] <rschroll> tedg: Are there docs for liburl-dispatcher?
[21:26] <tedg> rschroll: It's only three functions: http://bazaar.launchpad.net/~indicator-applet-developers/url-dispatcher/trunk.15.10/view/head:/liburl-dispatcher/url-dispatcher.h
[21:26] <rschroll> alecu: Thanks for your time!
[21:27] <alecu> hmmmm.... I wonder if we can have an extra optional step in the scopes api, where each scope would get an extra chance to massage the url
[21:27] <alecu> something similar to what you can do with scope previews
[21:27] <aquarius-phone> Yeah, that'd be dead useful to us here
[21:28] <alecu> rschroll: aquarius: perhaps you guys can open a bug in lp:unity-scopes-api or lp:unity-scopes-shell and I'll take it to michi, pstolowski and the other scope gurues.
[21:28] <alecu> still, it sounds like an ABI break, so I don't think I can promise anything before your hack is ready :-)
[21:28] <AndChat-28784> The helper app should work
[21:29] <aquarius-phone2> Gnah.
[21:29] <aquarius-phone2> rschroll: do you think the independent helper is better than having the container do it?
[21:29] <alecu> ok, I need to run. Great talking to you guys, and aquarius-phone2: it's me that owes you a beer :-)
[21:30] <rschroll> tedg: Gotcha.  I don't see anything for receiving URLs, though.
[21:30] <rschroll> dunno offhand.
[21:30] <aquarius-phone2> Cheers alecu :)
[21:30] <rschroll> The nice thing about the independent dispatcher is that code only has to be in one place, not both in the scope and in the container
[21:31] <aquarius-phone2> Agreed
[21:31] <rschroll> But it means another moving piece
[21:31] <aquarius-phone2> Also we can call the helper "Launching your web app..." :)
[21:31] <tedg> rschroll: No, for receiving we use the FD.o standard. So it's implemented by GApplication, I think QtApplication, etc.
[21:32] <tedg> rschroll: It is only one DBus endpoint if you just want to implement that though.
[21:32] <aquarius-phone2> We can talk to D-Bus?
[21:32] <rschroll> tedg: I see.  Thanks!
[21:34] <aquarius-phone2> I thought we were confined away from D-Bus. Cool.
[21:35] <rschroll> I think DBus access is curtailed by not completely prohibited.  At least based on my reading of the apparmor files
[21:35] <tedg> aquarius: aquarius-phone2: Everything is DBus or Mir
[21:35] <tedg> You should listen to my talk :-)
[21:35] <aquarius-phone2> Ya, but I thought we were only allowed certain things; the URL stuff is on that list?
[21:35] <tedg> Yes. There is in fact a rather long list.
[21:36] <tedg> And anyone who is unconfined can send you anything, so in this case you just set yourself up to recieve the URL
[21:36] <aquarius-phone> Oh, it must be, or nobody could use URL dispatcher
[21:37] <tedg> You'll note that the full API isn't available to confined apps. Only 2 of the 3 functions. The otehr is for the push service and scopes.
[21:37] <tedg> (well dash)
[21:38] <aquarius-phone> Cool.
[21:39] <aquarius-phone> So, something else goes on the "the platform should do this, but we managed to work around the lack with this suboptimal but working approach" :)
[21:40] <aquarius-phone> This IRC app does not handle changing networks well :)
[21:41] <aquarius-phone> This is going to make for the world's best talk about how to get things done on new Ubuntu in the face of fierce opposition ;-)
[21:43] <aquarius-phone> But I think that's the last serious platform impediment we had to overcome. Now, in theory, everything that could work, we know how to do. I think.
[21:43] <rschroll> Until the next existential crisis
[21:46] <aquarius-phone> Well, yeah.
[21:46] <aquarius-phone> But I'm being optimistic :)
[21:50] <aquarius-phone> tedg: question. When I ship an icon in my click package and the Icon desktop file key points to it, does everything reference that file, out does the install process take a copy of it to somewhere else?
[21:52] <tedg> aquarius-phone: Everything references it. For stuff that uses the desktop file in your click package it'll look relative to the click directory. For stuff that uses the desktop file in ~ the desktop file has the path expanded to be the absolute path.
[21:54] <aquarius-phone> rschroll: so, the container desktop file could have Icon=containerN.png and that... is a symlink to ~/.l/s/atd/container0.png ...
[21:57] <aquarius-phone> I'll test that at some point :)
[21:58] <rschroll> Poking around a bit, I've managed to get the scope dispatch a URL from the activate() method.  But it's blocked by apparmor
[22:05] <aquarius-phone> Huh. That's presumably because scopes themselves aren't allowed to despatch URLs? Only the scope framework is?
[22:05] <aquarius-phone> I suspect the security peeps will not wanna relax that requirement
[22:05] <tedg> I belive that you can return a URI as a response to an activate.
[22:05]  * tedg doesn't quite remember the scopes doc there
[22:06] <aquarius-phone> Nope
[22:07] <aquarius-phone> We spoke to alecu who _does_ know the scopes api and he says no :)
[22:10] <rschroll> "# Scopes shouldn't use URL dispatcher directly"
[22:25] <rschroll> aquarius: It works!  If the scope is unconfined.
[22:25] <rschroll> Somehow, I don't think that'll fly
[22:25] <aquarius-phone> Ha!
[22:25] <aquarius-phone> Yes. I think this is not the way forward :)
[22:26] <rschroll> Well, dinner time now....  I'll look at your pull request eventually, I swear.
[22:26] <aquarius-phone> Is OK :)
[22:26] <aquarius-phone> It finds icons properly now
[22:27] <aquarius-phone> And everything works end to end: I added a web app from the browser and launched it from the scope in a container
[22:27] <aquarius-phone> We should talk about nomenclature at some point too; I think we should talk about apps, not bookmarks. But that's not important right now :)
[22:30] <aquarius-phone> Anyway, ttfn. I shall go too. Later!