Il giorno lun, 09/05/2011 alle 17.13 +0200, Florian Müllner ha scritto:
> On Mon, 2011-05-09 at 15:52 +0200, Giovanni Campagna wrote:
> > A different issue is then UI. Some time ago it was proposed to introduce
> > addons.gnome.org, skip the (rpm/deb) packaging completely and just
> > instruct users to go, download the plugin and install it.
> > This has the problem that the plugin must be in an installable format
> > (xpi?), not just a random python/js file to drop in .local/share (or
> > even worse, an autotools tarball).
>
> I'm not sure we need to take extensions into account which do stuff that
> requires more than the metadata/js/css files - I'd consider extensions
> already as warranty-breaking, and even more so if it requires
> compilation/installation outside
> ~/.local/share/gnome-shell/extensions/foo.
>
> So I'd imagine something simple as a gzipped tarball with a custom
> extension (gsx == GNOME Shell extension?) which is distributed on
> addons.gnome.org - then we can have a dedicated app ("Desktop Extension
> Manager"?) registered as MIME handler to deal with
> installation/removal/disabling/... .
So .gsx (application/vnd.gnome.shell-extension) for the Shell, .gdp
(application/vnd.gnome.gedit-plugin) for Gedit, .epe
(application/vnd.gnome.epiphany-extension) for Ephiphany, etc.? How
would it integrate with, for example, libpeas?
Or a more generic .plugin.tar.xz, and the .plugin contained in it would
reference Eog / Rhythmbox?
What format for the container? .tar.xz, even if the extension is
different? Or a big compressed xml file bundling metadata and code?
What about more complex extensions, like libsocialweb providers or gimp
filters? Should they go through the traditional distro channels?
Giovanni
Attachment:
signature.asc
Description: This is a digitally signed message part