On Thu, Jul 18, 2013 at 7:09 PM, Rasmus Eneman <ras...@eneman.eu> wrote: > I really like a MIME type only approach for this because that makes apps > pluggable. If you for example have an app called barcode scanner for > scanning > barcodes and a shopping app called price checker that can use barcode > scanner > to scan barcodes to scan a products barcode and see where it's cheapest. > > Now a new app releases called qr code scanner that can do the same thing but > I for one reason or another preffer this one over barcode scanner a MIME > type > approach lets me use the app I prefer if qr code scanner implements the same > API. > But with a app name/id/path approch I would have to use barcode scanner if > that's > what price checker were designed for. >
I think what you really want (guessing here :)) is URL handling. Any app that can handle the URL: qr-code://scan could handle your request of scanning a QR code. I think mime-types are the wrong level of detail here, what I have in mind is a generic way of addressing specific functionality, and a URL is perfect for that. Makes sense? Thomas > Of cource all apps needs to be able to register new MIME types. If you have > multiple > apps that support the same MIME type one popup should appear letting you > choose > which one to use. > > > 2013/7/18 Jamie Strandboge <ja...@canonical.com> >> >> On 07/18/2013 11:14 AM, Michał Sawicz wrote: >> > W dniu 18.07.2013 17:38, Marc Deslauriers pisze: >> >> For the browser, I imagine a URL handler will take care of it, but what >> >> about >> >> spawning a different application that doesn't necessarily handle URLs >> >> or MIME types? >> > >> > And for network access I expect some platform API instead. >> > >> > I feel like the only instance where we would indeed allow spawning other >> > apps directly would be if it's bundled in the same package - and handled >> > through upstart as usual, I'd say. >> >> Well, an app may want to spawn a browser rather than implementing a >> webview >> itself. Marc mentioned the URL handler, but I don't know how this would >> work. >> Marc, can you elaborate? >> >> But for the other cases consider the MyApp click package that ships two >> desktop >> files for myapp and myapp-settings. Upstart works fine for launching >> either of >> these from the Dash. However, if myapp wants to launch myapp-settings from >> within itself, we need to define how that is supposed to happen (the >> specific >> problems are in another mailing list[1]). It can't just use: >> start application APP_ID=myapp-settings >> >> because we don't have a way to prevent it from doing: >> start application APP_ID=some-other-app >> >> There are some things we can do with AppArmor, but they don't include the >> executed app being managed by upstart. >> >> [1]https://lists.launchpad.net/ubuntu-appstore-developers/msg00296.html >> -- >> Jamie Strandboge http://www.ubuntu.com/ >> >> >> -- >> Mailing list: https://launchpad.net/~ubuntu-phone >> Post to : ubuntu-phone@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~ubuntu-phone >> More help : https://help.launchpad.net/ListHelp >> > > > > -- > Rasmus Eneman > > -- > Mailing list: https://launchpad.net/~ubuntu-phone > Post to : ubuntu-phone@lists.launchpad.net > Unsubscribe : https://launchpad.net/~ubuntu-phone > More help : https://help.launchpad.net/ListHelp > -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp