On Mon, May 9, 2011 at 7:44 PM, Vamsi Krishna Brahmajosyula < vamsikrishna.brahmajosy...@gmail.com> wrote:
> 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. > > 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 > > > sorry I have hit the send button too soon extensionModule.unload(meta); is for unloading the extension please send your opinions. > 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
