Re: Plugins, modules and extensions

[Vamsi Krishna Brahmajosyula <vamsikrishna brahmajosyula gmail com>]

On Mon, May 9, 2011 at 9:12 PM, Giovanni Campagna <scampa giovanni 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 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
>
>