Re: Gnome Contacts developers wanted
I am interested as well. I have done a couple extensions for the shell in javascript. I have only done a few examples in vala but i am sure i can learn it well with time. On Thu, Oct 20, 2011 at 5:31 PM, Alexander Larsson al...@redhat.com wrote: On Thu, 2011-10-20 at 14:00 +0200, Seif Lotfy wrote: What is the language used to develop? Its written in vala, and so is libfolks which is the primary dependency. ___ 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
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
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
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
