ubuntu-appstore-developers team mailing list archive
-
ubuntu-appstore-developers team
-
Mailing list archive
-
Message #00452
Re: click-desktop, upstart-app-launch-desktop and AppArmor
On Thu, Aug 15, 2013 at 4:35 PM, Sergio Schvezov
<sergio.schvezov@xxxxxxxxxxxxx> wrote:
> On Thu, Aug 15, 2013 at 3:23 PM, Jamie Strandboge <jamie@xxxxxxxxxxxxx>
> wrote:
>>
>>
>> Hi!
>>
>> IIRC, the plan all along was to remove the click-desktop hook in favor of
>> the
>> upstart-app-launch-desktop. I reviewed upstart-app-launch and it is
>> working well
>> ('start application APP_ID=$pkgname_$appname_$version' launches apps under
>> confinement (on 3.10 kernels-- patch pending for 3.11). That's great!
>>
>> One thing that has had me concerned though is that apps are going to be
>> hitting
>> the appstore and more than just Unity users should be able to use them. My
>> understanding is that flavors and derivatives would either have to create
>> their
>> own launcher based on Ted's click-exec or we could be sneaky and start the
>> upstart job via the desktop file. That won't work on systems that use an
>> upstart
>> user session. I then noticed that both the click-desktop and
>> upstart-app-launch-desktop hooks are both on my system, and they both run.
>> The
>> application-click upstart job uses click-exec to find the desktop file by
>> using
>> 'click pkgdir' and generates its own exec line for use in the click
>> upstart job.
>> Meanwhile, the click-desktop hook outputs a desktop file in
>> ~/.local/share/applications that uses aa-exec.
>>
>> Not sure if all this was planned, but if we keep both the click-desktop
>> and
>> upstart-app-launch-desktop hooks, then Unity keeps the application
>> lifecycle
>> goodness and flavors and derivatives don't need to do anything so long as
>> they
>> can handle normal desktop files, and click will work as expected. :)
>
>
> Will we eventually get double icons in the App lens if we keep both? I'm not
> sure how unity8 is going to figure out what Apps it has available through
> click and I expect it would still support traditional desktop files from a
> convergence point of view at least. I'm not aware of how unity8 is going to
> work with this.
unity-scope-click will get a list of installed applications with
"click list --manifest", and build uris for each scope result like:
"application:///home/phablet/.local/share/applications/pkgid_appid_version.desktop"
Some duplication may happen because unity-lens-applications will also
be parsing the .desktop files in that same folder, so we are planning
to de-duplicate using just one of the following:
* deduplicate on the dash, based on the application:// uri,
priorizing results from u-s-click
* or, filter .desktop files on unity-lens-applications that have the
"X-Ubuntu-Application-ID" field (meaning they are apps installed by
click)
we've not decided which method we'll use yet, so any comments are appreciated.
cheers,
--
alecu
Follow ups
References