Re: Gnome Feature Request
Le lundi 09 mai 2011 à 00:58 -0400, Erick Pérez a écrit : Finally, I do think this childish behavior is not getting anything useful for no-one of us. If the spirit of the Gnome Team, is: 'Bring some code/mockups, then we will judge' Ok. Mockups would help understanding your idea, but code isn't necessary at this point. I think you'd best write a few use cases that are enough to prove that your project would be beneficial to the user experience, and that the implementation you suggest is really needed to achieve them. Have a look at the Online Accounts panel for 3.2 thread to get an insight on what kind of rationale people are expecting. I'll do it myself. And then maybe, you find it interesting, or not. That's also a possibility, of course, but you might waste time if it's not going to be accepted in the end... Mockups and use-cases are cheaper. ;-) Regards ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome Feature Request
Hi, Please see comments inline. 2011/5/8 Erick Pérez erick@gmail.com: On 08/05/2011, Jasper St. Pierre jstpie...@mecheye.net wrote: 2011/5/8 Erick Pérez erick@gmail.com Why not at the time of the menu? Cause it will be to slow, way to slow. Making choices based on the data you think we should send to the service will be slow, any decision at all will take to long for a responsive UX to act. What makes you think that? Profile it and then make decisions. Don't degrade the experience a user has because it could possibly be too slow. Fair, enough, anyway what's make think like my programming experience. I'd rather see No definitions inline in the menu than having a new popup window tell me the new thing. No one is talking about new popup windows. That's a pretty rushed thought for something is still an idea, and, it's up to the app developer how they will handle the data and the interaction with the service, so It's kinda naive to assume you will have popup windows informing you of the results of anything. If the app developer already has to implement a UI for a dictionary result, then why don't they just call gnome-dictionary directly? No one says that. You just assumed it that way. You said that you didn't want a daemon started, so we can't use D-Bus in that case, unless we use D-Bus autostart, but I don't see the value in that either. You miss-understood me, when I said I didn't want a daemon, I was talking about a daemon of each application registered. In the first email I said that D-Bus should provide the infrastructure for the service/module A D-Bus daemon needs to be running for you to be able to call it. D-Bus can start the daemon for you if it isn't started or it crashes, but the daemon needs to keep running. You keep miss-understanding, when I talk about daemon, I meant, I didn't want a dictionary daemon, and a daemon for every app publishing actions/services, course it has to be a daemon for the apps to query it, and to answer back Now the hard part: The only tangible idea I can extract out of this is querying a service with something akin to a mimetype, and getting a list of programs that can handle it. I query the service with SEMANTIC_WORD, and I get /usr/bin/gnome-dictionary-lookup-word %s back. That's more or less the whole point of it. With SEMANTIC_WORD would return gnome-dictionary, and some others too, and even more than not regular gnome-dictionary, but gnome-dictionary called in a way that the app show just a small overlay with the definition, and nothing else If they have to implement a UI for every result that could be possibly returned, they can only implement a certain number of actions... so the middleman aggregator that you're suggesting is useless. Every time you add a UI, you add support for the tool. I don't see how this is an answer to what I said before ... and I still can't see how you would build jumplists out of this Ohh, that so easy, the jump list are composed of two main things, recent files opened with that app, and sub-actions other than the main purpose of the app. Well the for recent files part there's already zeitgeist for that, but for a list of sub-actions of every app that allow it, then you can query the service I'm proposing. Because you should already know by now that querying the service about a specific action is not the only way of interacting with it. We already have a way to find the programs that have the ability to open a file. It's been around for a long time now, too, and even works with KDE: http://portland.freedesktop.org/xdg-utils-1.0/xdg-mime.html This is what nautilus talks to with its Open With dialog, for instance. Yeah, already know that, but xdg-open still handles just files based on a mime-type. I'm thinking more generally. There might be an inch of value in that idea, but I don't see it. I don't see the value in this service Hopefully, you're not the main man behind Gnome. I'm not. I don't even know who the main man is, or even if there is one. Gnome Desktop actually needs integration/communication between applications, to start looking as whole, like is already doing with the system settings trying to provide a niche for a bunch of somewhat different settings, and the way to provide that is centralizing communications and interactions, acting as a middle man between desktop apps. Of course gnome desktop would be better if it had integration. It would be excellent if everything just worked, but like any other timely, shipped system, there are warts. GNOME 3.0 certainly isn't as integrated as we would have liked it to be, but we have a schedule, we have time constraints, and we have manpower constraints. If we had infinite time to design and work on GNOME, we'd all be staring at the perfect desktop environment: It would literally be the most usable, most customizable, least crashy desktop environment that ever
Plugins, modules and extensions
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 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
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 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
GUPnP inclusion
Hi all, Rygel is planned to included back into GNOME in 3.1 as part of the 'Sharing' feature[1]. GUPnP dependencies of Rygel has so far been used as blessed external dependencies. Since GUPnP is moving [2] to GNOME infrastructure and Rygel development is very closely tied with GUPnP, I propose that we now treat GUPnP as part of GNOME (developer platform). If we decide to do this, I also recommend we not only take the components that Rygel directly depend on[3] but gupnp-tools as well since those tools are very useful for developing, testing and tracing UPnP issues. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 [1] https://live.gnome.org/ThreePointOne/Features/Sharing [2] https://bugzilla.gnome.org/show_bug.cgi?id=648704 https://bugzilla.gnome.org/show_bug.cgi?id=625933 https://bugzilla.gnome.org/show_bug.cgi?id=648112 [3] gssdp, gupnp, gupnp-av, gupnp-dlna and gupnp-vala ___ 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, 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
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
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
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: Documentation build plans for 3.2
On Mon, 2011-05-09 at 17:14 +0200, Jorge González wrote: Shaun, What has happened to gnome-help package? I don't see it anymore in damned lies?! This? http://l10n.gnome.org/module/gnome-user-docs/ The POT file on DL is messed up, because DL doesn't know how to deal with all the new stuff I talked about. I'll get fixed. That's why we're doing this at the beginning of the cycle. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
First release of geocode-glib available
Heya, This is the first release of geocode-glib, a small library on top of the Yahoo! Place Finder API. This first release allows you to do geocoding (going from a place name, to a longitude/latitude pair) and reverse geocoding (finding a place name from coordinates). It also implements caching (so that starting up Empathy doesn't flood the service), and helper functions to use Telepathy location properties to do geocoding. There's everything you'd expect from a glib-based library, GObject introspection for Python, Vala or Javascript, API documentation, and a test suite. The dependencies are gvfs, libsoup, and json-glib, though the gvfs dependencies might be removed in the future. This library should be used in place of Geoclue's D-Bus API for geocoding and reverse geocoding. Finally, the responses to requests also include information about the timezone and the closest airport to the location, which could be of some use to libgweather and date time settings. Code is at: http://git.gnome.org/browse/geocode-glib And tarballs at: http://ftp.gnome.org/pub/GNOME/sources/geocode-glib/0.99/ 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
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: First release of geocode-glib available
On Mon, 2011-05-09 at 17:14 +0100, Ross Burton wrote: On 9 May 2011 16:52, Bastien Nocera had...@hadess.net wrote: This is the first release of geocode-glib, a small library on top of the Yahoo! Place Finder API. What are the terms of service on this API? If they are in any way restrictive, can you document them in the API docs? 50k requests per day, and the fact that the data gathered doesn't belong to you. See rate limits and terms of use, as linked from the API docs: http://developer.yahoo.com/geo/placefinder/ We (me, with GNOME Foundation Board hat on) are still in touch with Yahoo!, and we should be able to increase the rate limits. Right now, I'm taking a we'll see approach. If it turns out that using Yahoo!'s APIs is not manageable, we'll probably start using Nominatim from OpenStreetMap instead. But I'd rather force the issue with them, showing what advantages their APIs could provide us. 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
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: First release of geocode-glib available
On 9 May 2011 17:21, Bastien Nocera had...@hadess.net wrote: What are the terms of service on this API? If they are in any way restrictive, can you document them in the API docs? 50k requests per day, and the fact that the data gathered doesn't belong to you. See rate limits and terms of use, as linked from the API docs: http://developer.yahoo.com/geo/placefinder/ We (me, with GNOME Foundation Board hat on) are still in touch with Yahoo!, and we should be able to increase the rate limits. Right now, I'm taking a we'll see approach. If it turns out that using Yahoo!'s APIs is not manageable, we'll probably start using Nominatim from OpenStreetMap instead. But I'd rather force the issue with them, showing what advantages their APIs could provide us. Sounds like a good plan, good luck. :) Ross ___ 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 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
