Re: Resource framework, relocatability (was Re: Glib: a Win32 discussion)
- From: David Zeuthen <zeuthen gmail com>
- To: Alberto Ruiz <aruiz gnome org>
- Cc: gtk-devel-list gnome org
- Subject: Re: Resource framework, relocatability (was Re: Glib: a Win32 discussion)
- Date: Mon, 18 Apr 2011 14:17:14 -0400
Hi,
On Mon, Apr 18, 2011 at 1:41 PM, Alberto Ruiz <aruiz gnome org> wrote:
> 2011/4/17 David Zeuthen <zeuthen gmail com>:
>> Honestly, I'm not that interested in solving the "make relocatable app
>> providing plug-ins work without installing the app" use-case work
>> outside Linux.
>>
>> FWIW, even on Linux, I'm not even sure it's something worth worry
>> about - for the few cases where you need this (such as when installing
>> a MP3 or H264 decoder (e.g. a GStreamer plug-in)), it's fine just
>> using the platform mechanism (e.g. RPM or DEB).
>
> David,
>
> I'm afraid it's not just fine for several reasons:
Alberto, I don't think you understood what I was saying... what I was
saying is that apps should indeed be using something like AppFolders
(in a single file or whatever) but plugins etc. should just keep using
RPM/DEB/whatever via e.g. PackageKit. The point of my mail was simply
answering the "do we need to handle the case where an app ships a
plugin" case with a "no".
For example, if I'm writing a movie player, then I use alexl's
mechanism to produce a single file to distribute the movie player.
Specifically, I don't include any plugins in my app because I simply
don't need to...the OS has been already setup to make GStreamer get
the plugins via e.g. PackageKit or whatever.
I also said that if we wanted, we could even handle plugins via
something like this
https://mail.gnome.org/archives/gtk-devel-list/2011-April/msg00090.html
which funny enough is a lot like what OS X is doing with their
LaunchServices approach (I didn't know that at the time of writing).
My point was just that it's not really an interesting corner case.
David
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]