On Mon, May 9, 2011 at 9:12 PM, Giovanni Campagna <scampa.giova...@gmail.com > wrote:
> 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. > > Ok, I will file a bug on that. I would like to work on that as well. Will try to get patches on looking glass ( ability to enable/disable an extension) and extensionSystem(to identify and call the unload method when required) . thanks > > > > 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.giova...@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 > > > > > > >
_______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
