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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
