Il giorno lun, 09/05/2011 alle 19.44 +0530, Vamsi Krishna Brahmajosyula ha scritto: > I am sorry for the late proposal, but I feel its important to put > forward my views on extension management. > > > This is regarding the extension system. A 'main' method to be called > when the extension is loaded is a simple way to inject > code to the existing shell. What about un-doing certain changes with > out having to reload the shell? If the developer of the extension > knows say ,how to add a button to the panel. He/she > will definitely know how to revert it back. > > > What I am proposing is to add an additional method say "unload" in the > structure of extension.js (optional only). If the method is > found, the extension is eligible to unload dynamically with out "Alt > +f2 < "r"" . The extensions listed in looking glass can now have > additional method of load/unload based on whether the extension comes > with one. I am not sure if this is planned already. This is not a platform-wide feature, it affects just one module. And since it is definitely worth-while, file a bug and someone (which could be me) will work on it. > > 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 > > > > > thanks > -- > vamsi > > > > On Mon, May 9, 2011 at 7:22 PM, Giovanni Campagna > <scampa giovanni gmail com> wrote: > 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 > provide > extensions, like eog-plugins, gedit-plugins, > epiphany-extensions, > 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, > 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 > 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. > 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. > > 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 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. > 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. > > 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 > > Giovanni > > _______________________________________________ > desktop-devel-list mailing list > desktop-devel-list gnome org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > >
Attachment:
signature.asc
Description: This is a digitally signed message part