Re: Plugins, modules and extensions
- From: Sriram Ramkrishna <sri ramkrishna me>
- To: Giovanni Campagna <scampa giovanni gmail com>
- Cc: desktop-devel-list <desktop-devel-list gnome org>
- Subject: Re: Plugins, modules and extensions
- Date: Mon, 9 May 2011 07:36:25 -0700
On Mon, May 9, 2011 at 6:52 AM, Giovanni Campagna <scampa giovanni gmail com>
First of all, should those modules be provided as tarballs? Last time I
asked this for gnome-shell-extensions, I was answered no, because
distributions should not provided packages of those. Nevertheless, all
them appear packaged in most common distros, which makes that point
moot, and actually increases the work required by packagers. Plus having
Right, and I think this is primarily because they want to satisfy people
who still prefer the GNOME 2 experience and have trouble coping with
the changes. Some of the extensions put functionality back or to fix
issues such has suspend that users do not seem to understand the change
as such. We made extensions hard to get to, thus it got packaged for
git be the primary way to distribute code makes it difficult to mark
buildable/usable release (both for distro packages and for manual
building), resulting for example in people using g-s-extensions master
with released (incompatible) gnome-shell.
It also makes GNOME somewhat unstable..
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 often
packaged, installed and used together with core modules, as well as
having the same developers/maintainers.
Owen and Jon and module maintainers are probably the right one to answer this one..
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.
I personally prefer this. The reasoning is that we are able to control
the experience better. Extensions can create instability in GNOME 3 and
thus we don't want GNOME 3 to be blamed for instability due to the
extensions installed. addons would at least let us add a disclaimer and
also provide us with a way to increase the value and recognizably of
our brand. I don't know how easy it would be to add xpi like features..
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 extensions
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.
That's a possibility as well, but the experience would not be
consistent. For instance, person on one distro would not have the same
set of extensions as another person. It might also lead to distros
making unique extensions only through their distro. Ideally, we'd like
the same set of extensions available on all distros.
One measure could be that addons.gnome.org
could be a software channel
for package kit but using xpi if package kit could be extended to use
This would leave the problem of enabling third parties to provide
plugins, but I believe it has to be solved at the distro level, if they
want to have some kind of AppStore for unsupported externally-provided
(often non-free) desktop apps.
We could use the same set up as PPAs. Again we need to be careful to
communicate to end users that adding something not official is subject
to making their desktop unstable.
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
Hope, my comments were helpful.
] [Thread Prev