Re: [Qgis-developer] Plugins approval
Matthias Kuhn wrote : I remember, I discussed another key website with Borys, which would be shown in a frame in the plugin description page. This could be used to show even pictures in a description. Or we could just embed the URL listed in homepage. Jonathan Moules wrote: If I'm understanding correctly, you're proposing that the explanations etc be hosted online? From what I've picked up reading the lists and elsewhere, QGIS is used in quite a few instances in locations where internet access is lacking or merely unreliable. I think any help/explanation should be integrated and distributed with the software. Guys, We were also discussing another tag: about. Its main purpose was just what we're talking about: to guide the user how to use the plugin. It also allows to lighten the description tag by leaving only a brief note on the plugin purpose. Please see the example: http://tmp.borysjurgiel.pl/description-about.png Currently the plugin manager supports it for a test, but we didn't perform any broader discussion in Brighton, so it's unofficial and not implemented in the repository. We definitely have to discuss it here or in Vienna and either proceed or drop it. Regards, Borys ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Plugins approval
Is there a real problem we are trying to solve with this? I am not sure, each plugin will belong to exactly one menu and the rules can technically be enforced. IMO They can as well have some entries in two different menus. Or require a totally new menu (although there need to be really good reasons for this). This discussion seems related to the category vs. tags discussion for plugins, which we had some time ago, where I also think, that the category solution is not flexible enough in comparison to the possibilities offered to plugin authors by the extensive QGIS API. Therefore, I would propose not to implement hard rules (like specifying the menu in metadata) but leave all the options to the plugin author and have some intelligent soft rules, which can be considered for each case individually, and eventually be discussed with the plugin author in the approval process. Best Matthias ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Plugins approval
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 07/01/2014 09:04, Matthias Kuhn ha scritto: Therefore, I would propose not to implement hard rules (like specifying the menu in metadata) but leave all the options to the plugin author and have some intelligent soft rules, which can be considered for each case individually, and eventually be discussed with the plugin author in the approval process. Thanks for your comments. I'd like to keep things simple at this stage: what I think we should avoid (and this is easy to do) is having new plugins going to the Plugins menu, instead of the appropriate one. Rationale: * keeping a tidy interface * make it predictable for users where to find a command. I suggest to check this for each new plugin, and ask the author to chenge it if necessary before approval. All the best. - -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlLLtk8ACgkQ/NedwLUzIr4mtwCfSyoFXQ3Dfc0OdgwVeSHRc61w DBkAn2OgJocEBCi869XEG+Yz59PUFuG1 =A0P6 -END PGP SIGNATURE- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Plugins approval
On 7 January 2014 08:04, Matthias Kuhn matthias.k...@gmx.ch wrote: Is there a real problem we are trying to solve with this? Users (even technical ones) have problems finding where plugins have actually installed stuff - I've seen it first hand. By using a logical and consistent approach, that issue is minimised. The biggest weakness of QGIS in my mind is the fact that it's extremely hodge-podge and inconsistent from the user-interface/user-experience perspective. Anything to fix that is a good thing IMHO. Cheers, Jonathan -- This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Plugins approval
Hi Paolo and Jonathan, Thank you for sharing your thoughts. We should encourage plugin-authors to write a good get-started section in the description in their metadata. Or we could include yet another getstarted metadata section. I remember, I discussed another key website with Borys, which would be shown in a frame in the plugin description page. This could be used to show even pictures in a description. Or we could just embed the URL listed in homepage. Why I think this is a better idea: * E.g. The processing plugin creates a new menu, this would not fit into the previously described scheme. (But the scheme could be adapted to contain an array of menu entries) * Plugins can have more than one menu entry (Sending them back to the plugins menu would totally fail to fulfill the requirements listed by you) * Evenmore: There may as well be plugins with no menu entry at all. (E.g. You could write a plugin just to add new attribute editor fields) Optimally we should have a good guideline where we can point people to. And the plugin builder plugin should already help people to get this done. So I would not say anything to fix that is a good approach, but a well-designed solution will be very welcome. The other (technical) option which I can think of would be to define access rights or hooks which a plugin can acquire in the metadata section and then the app will be delivered with these. So a plugin could acquire the Register a new toplevel menu item or the Register a vector menu item or the Register a new attribute editor widget or the Register a new raster pipe function hooks. Smartphones use something like this for their permission management. While this offers some advantages (you can exactly list, what the plugin will do) it seems a bit over-engineered for this problem IMHO. And it would require to rewrite all plugins :) Therefore my preference: Solve it with human sense instead of technique. Cheers Matthias On 01/07/2014 09:09 AM, Paolo Cavallini wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 07/01/2014 09:04, Matthias Kuhn ha scritto: Therefore, I would propose not to implement hard rules (like specifying the menu in metadata) but leave all the options to the plugin author and have some intelligent soft rules, which can be considered for each case individually, and eventually be discussed with the plugin author in the approval process. Thanks for your comments. I'd like to keep things simple at this stage: what I think we should avoid (and this is easy to do) is having new plugins going to the Plugins menu, instead of the appropriate one. Rationale: * keeping a tidy interface * make it predictable for users where to find a command. I suggest to check this for each new plugin, and ask the author to chenge it if necessary before approval. All the best. - -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlLLtk8ACgkQ/NedwLUzIr4mtwCfSyoFXQ3Dfc0OdgwVeSHRc61w DBkAn2OgJocEBCi869XEG+Yz59PUFuG1 =A0P6 -END PGP SIGNATURE- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Plugins approval
I remember, I discussed another key website with Borys, which would be shown in a frame in the plugin description page. This could be used to show even pictures in a description. Or we could just embed the URL listed in homepage. If I'm understanding correctly, you're proposing that the explanations etc be hosted online? From what I've picked up reading the lists and elsewhere, QGIS is used in quite a few instances in locations where internet access is lacking or merely unreliable. I think any help/explanation should be integrated and distributed with the software. So I would not say anything to fix that is a good approach A poor choice of words on my part. Obviously a good fix is preferable to. :-) Cheers, Jonathan -- This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Plugins approval
On 01/07/2014 02:29 PM, Jonathan Moules wrote: I remember, I discussed another key website with Borys, which would be shown in a frame in the plugin description page. This could be used to show even pictures in a description. Or we could just embed the URL listed in homepage. If I'm understanding correctly, you're proposing that the explanations etc be hosted online? From what I've picked up reading the lists and elsewhere, QGIS is used in quite a few instances in locations where internet access is lacking or merely unreliable. I think any help/explanation should be integrated and distributed with the software. Good point. Not necessarily, a get started text could be saved in the metadata as well. Or alternatively an html folder structure. Or maybe a combination of on- and offline, so as long as the plugin is not installed, it would be loaded on-demand, so we don't need to transfer everything everytime we check for updates, but as soon as the plugin is installed it is loaded offline for machines without internet access. But these are just ideas, I don't have any strong opinion about this (yet). So I would not say anything to fix that is a good approach A poor choice of words on my part. Obviously a good fix is preferable to. :-) No worries, I just want to be sure we don't need to switch methods again in a couple of months ;-) Best Matthias ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Plugins approval
Richard, We were discussing it already, without any success, and I can't imagine how it could be done with the 2.x API. Currently each plugin just calls one of the QgisInterface methods: addPluginToVectorMenu, addPluginToRasterMenu etc. An obvious idea is to create an universal method addPluginToTheRightMenu, but unfortunately it's not so simple. QgisInterface doesn't know who calls the method, so it can't access its metadata. The only way would be to explicitly pass the plugin module name: moduleName = os.path.split(os.path.dirname(__file__))[1] iface.addPluginToTheRightMenu( A menu label, action, moduleName ) I guess it's too nasty to even discuss it ;) So the only real solution I see would be to create an abstract plugin class and forece authors to inherite their plugins from this class. I'm not convinced if it's worth of the effort at all, but anyway it would be definitely a major change that has to wait for API 3.x But maybe somebody has a simpler idea? Regards, B. Dnia niedziela, 5 stycznia 2014 20:40:35 Richard Duivenvoorde pisze: Currently the 'menu'-functionality is half way there, I think. While one defines a 'menu' in the metadata.txt, the actual placing has to be done by the coder self in python. Not sure what the reason was (alexander?)... (was it that the pluginmanager had to know it, or that the plugins were loaded before the gui or). But I think it would be nice to have this fixed first. Then a user can even 'move' a plugin by changing the metadata.txt. Regards, Richard Duivenvoorde ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Plugins approval
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 06/01/2014 20:22, Borys Jurgiel ha scritto: But maybe somebody has a simpler idea? I see. In any case, I think we should not approve a plugin unless it goes in the appropriate menu. BTW, could someone point out where we have a list of the items to be checked for approval? Thanks. - -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlLLskgACgkQ/NedwLUzIr77jgCfaK3va94iBuFyV6hogYkbt7Ez HwAAmgP/LzSXeqaYvbDlrohVoeN0FPqS =AvKo -END PGP SIGNATURE- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Plugins approval
Hi all. I would suggest an additional rule to accept a new plugin: we should make sure it registers itself in the appropriate menu (Vector, Raster, Database, Web, etc.), leaving in Plugins menu only those who cannot be classified because they belong to more than one category, This will help keeping the interface tidy. Thoughts? All the best. -- Paolo Cavallini - www.faunalia.eu QGIS PostGIS courses: http://www.faunalia.eu/training.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Plugins approval
On 05-01-14 19:00, Paolo Cavallini wrote: I would suggest an additional rule to accept a new plugin: we should make sure it registers itself in the appropriate menu (Vector, Raster, Database, Web, etc.), leaving in Plugins menu only those who cannot be classified because they belong to more than one category, This will help keeping the interface tidy. Thoughts? Currently the 'menu'-functionality is half way there, I think. While one defines a 'menu' in the metadata.txt, the actual placing has to be done by the coder self in python. Not sure what the reason was (alexander?)... (was it that the pluginmanager had to know it, or that the plugins were loaded before the gui or). But I think it would be nice to have this fixed first. Then a user can even 'move' a plugin by changing the metadata.txt. Regards, Richard Duivenvoorde ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
