Re: Plugins, modules and extensions

2011-05-09 Thread Vamsi Krishna Brahmajosyula
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


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

Re: Plugins, modules and extensions

2011-05-09 Thread Vamsi Krishna Brahmajosyula
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

Re: Plugins, modules and extensions

2011-05-09 Thread Sriram Ramkrishna
On Mon, May 9, 2011 at 6:52 AM, Giovanni Campagna scampa.giova...@gmail.com
 wrote:

 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 easy
dissemination.


 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 reckon not that too
hard given the use of mozilla javascript.

 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 it.


 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.

sri
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Plugins, modules and extensions

2011-05-09 Thread Florian Müllner
On Mon, 2011-05-09 at 15:52 +0200, Giovanni Campagna wrote:
 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'm not sure we need to take extensions into account which do stuff that
requires more than the metadata/js/css files - I'd consider extensions
already as warranty-breaking, and even more so if it requires
compilation/installation outside
~/.local/share/gnome-shell/extensions/foo.

So I'd imagine something simple as a gzipped tarball with a custom
extension (gsx == GNOME Shell extension?) which is distributed on
addons.gnome.org - then we can have a dedicated app (Desktop Extension
Manager?) registered as MIME handler to deal with
installation/removal/disabling/... .

Florian

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list


Re: Plugins, modules and extensions

2011-05-09 Thread Giovanni Campagna
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.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
 

Re: Plugins, modules and extensions

2011-05-09 Thread Vamsi Krishna Brahmajosyula
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 

Re: Plugins, modules and extensions

2011-05-09 Thread Giovanni Campagna
Il giorno lun, 09/05/2011 alle 17.13 +0200, Florian Müllner ha scritto:
 On Mon, 2011-05-09 at 15:52 +0200, Giovanni Campagna wrote:
  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'm not sure we need to take extensions into account which do stuff that
 requires more than the metadata/js/css files - I'd consider extensions
 already as warranty-breaking, and even more so if it requires
 compilation/installation outside
 ~/.local/share/gnome-shell/extensions/foo.
 
 So I'd imagine something simple as a gzipped tarball with a custom
 extension (gsx == GNOME Shell extension?) which is distributed on
 addons.gnome.org - then we can have a dedicated app (Desktop Extension
 Manager?) registered as MIME handler to deal with
 installation/removal/disabling/... .

So .gsx (application/vnd.gnome.shell-extension) for the Shell, .gdp
(application/vnd.gnome.gedit-plugin) for Gedit, .epe
(application/vnd.gnome.epiphany-extension) for Ephiphany, etc.? How
would it integrate with, for example, libpeas?
Or a more generic .plugin.tar.xz, and the .plugin contained in it would
reference Eog / Rhythmbox?
What format for the container? .tar.xz, even if the extension is
different? Or a big compressed xml file bundling metadata and code?
What about more complex extensions, like libsocialweb providers or gimp
filters? Should they go through the traditional distro channels?

Giovanni



signature.asc
Description: This is a digitally signed message part
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Plugins, modules and extensions

2011-05-09 Thread Milan Bouchet-Valat
Le lundi 09 mai 2011 à 17:13 +0200, Florian Müllner a écrit :
 So I'd imagine something simple as a gzipped tarball with a custom
 extension (gsx == GNOME Shell extension?) which is distributed on
 addons.gnome.org - then we can have a dedicated app (Desktop Extension
 Manager?) registered as MIME handler to deal with
 installation/removal/disabling/... .
And upgrade. I think an important part is to allow people to get
up-to-date versions of their extensions at the same time as they update
their system packages. What should we do e.g. when people upgrade to
GNOME 3.2 and their extensions are no longer compatible with the API?

Ideally IMHO, new versions of extensions would be downloaded from
addons.gnome.org when the system packages are upgraded. But if they are
installed per-user, that has to be done per-user too, i.e. on first
login after upgrade... I kind of hate this idea: when all apps are doing
this, users are getting random dialogs about upgrades they don't
understand. Though I guess that's OK if there's a single extension
manager for GNOME (Shell, gedit, Epiphany...) - but don't forget Firefox
is also doing this, and other third-party apps might too.


Cheers


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Plugins, modules and extensions

2011-05-09 Thread Florian Müllner
On Mon, 2011-05-09 at 17:50 +0200, Giovanni Campagna wrote:
 So .gsx (application/vnd.gnome.shell-extension) for the Shell, .gdp
 (application/vnd.gnome.gedit-plugin) for Gedit, .epe
 (application/vnd.gnome.epiphany-extension) for Ephiphany, etc.? How
 would it integrate with, for example, libpeas?

No, I was only talking about GNOME Shell. I don't know if there are any
plans for application extensions to go for the web route as well, but if
they do I don't see how they'd need a dedicated UI - all applications
you mention already provide UI for extension management, it'd seem more
natural to extend those as necessary (of course that doesn't mean that
code couldn't be shared between those applications).

GNOME Shell is a bit special in that it should not have a brand of its
own (e.g. users shouldn't need to know that they are running gnome-shell
any more than they needed to know they were running gnome-panel
+metacity). It's basically the desktop chrome of GNOME 3 - which makes
for a horrible brand :-)

For extensions, this also means that there's no good place for an UI yet
- we don't (and shouldn't) have any GNOME Shell Settings. Looking glass
is a developer tool, I don't think it is where we expect users to manage
extensions. Exposing extensions in the overview (as suggested at some
point) is completely out of the question. Hence my suggestion to have a
dedicated application to manage desktop extensions.

Florian

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list


Re: Plugins, modules and extensions

2011-05-09 Thread Steve Frécinaux

On 05/09/2011 03:52 PM, Giovanni Campagna wrote:

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


For your information, there is currently a Summer of Code project by 
Garett Regier meant to add plugin sources support to libpeas.

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list