> It is just one step forward for having a central extension manager. It
> may not happen now but It would be good to have one.
> extensionModule.main(meta); is for loading the extension
> On Mon, May 9, 2011 at 7:22 PM, Giovanni Campagna
> <scampa giovanni gmail com
> This is the last day for feature proposals, but unfortunately
> I've been
> very busy lately and didn't have time to write it down
> formally. And
> actually, mine is more a question than a proposal: what are
> planning to
> do with additional functionality that is provided as plugins?
> I believe there are two specific questions we need to answer
> on this
> topic. The first one is technical, and related to distribution
> of code.
> Some of Core modules have related external modules that
> extensions, like eog-plugins, gedit-plugins,
> gnome-shell-extensions, gnome-applets.
> First of all, should those modules be provided as tarballs?
> Last time I
> asked this for gnome-shell-extensions, I was answered no,
> distributions should not provided packages of those.
> Nevertheless, all
> them appear packaged in most common distros, which makes that
> moot, and actually increases the work required by packagers.
> Plus having
> git be the primary way to distribute code makes it difficult
> to mark
> buildable/usable release (both for distro packages and for
> building), resulting for example in people using
> g-s-extensions master
> with released (incompatible) gnome-shell.
> More on that: should those modules be part of the Core as
> well? On the
> one hand, they provide functionality that is additional to
> Core, and
> often against accepted design. On the other hand, they're
> packaged, installed and used together with core modules, as
> well as
> having the same developers/maintainers.
> A different issue is then UI. Some time ago it was proposed to
, skip the (rpm/deb) packaging completely and
> instruct users to go, download the plugin and install it.
> This has the problem that the plugin must be in an installable
> (xpi?), not just a random python/js file to drop
> in .local/share (or
> even worse, an autotools tarball).
> I think we can solve this in the same way we're going to deal
> with Gnome
> Apps, by leveraging and extending PackageKit (with native repo
> metadata), meaning that users will be able to browse through
> in gpk-application (or an improved software center-like app)
> or in the
> same UI they currently use for enabling/disabling them, and
> get them
> installed automatically from the repository.
> This would leave the problem of enabling third parties to
> plugins, but I believe it has to be solved at the distro
> level, if they
> want to have some kind of AppStore for unsupported
> (often non-free) desktop apps.
> I'm looking forwards to see your opinions on these issues and
> I'm ready
> to help with whatever work (at the UI/platform/releng level)
> is needed
> to get a better plugin experience in GNOME 3.2
> desktop-devel-list mailing list
> desktop-devel-list gnome org