Re: [Qgis-developer] Plugins without source code
2014-06-02 17:12 GMT+02:00 Martin Dobias : > Hi > > I have just found out there is a plugin "Vgi2Shp" in QGIS plugin > repository, all of its functionality is in a .pyc file - compiled > python module, with no source code (.py). Also the code repository on > GitHub is completely empty. I believe this is not allowed under the > terms of GNU GPL - and probably we do not want to allow such code in > the repository (basically it is an opaque binary blob). What are your > opinions? > > I think we could create a list of unwanted python extensions which > should not be allowed, e.g.: > - .pyc (compiled .py) > - .pyo (optimized .pyc) > - .pyd (compiled module) > > It is clear that this cannot serve as a real security measure as it is > easy for malicious code to work that around anyway - I think it should > be merely a warning to the developers that they may be doing something > wrong. (Packaging a .pyc file is normally useless and just inflates > package size - the .pyc will be created automatically by the > interpreter). > > Hi Martin, We can add a rule in the validator.py to generate a warning when a blacklisted extension is in the package. Checking if for each .pyc there is also a .py is a bit more complicated but also possible. -- Alessandro Pasotti w3: www.itopen.it ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Plugins without source code
2014-06-02 22:48 GMT+02:00 Paolo Cavallini : > Il 02/06/2014 17:12, Martin Dobias ha scritto: > > BTW, I now cannot switch between > https://plugins.qgis.org/plugins/Vgi2ShpConverter/#plugin-details > and > https://plugins.qgis.org/plugins/Vgi2ShpConverter/#plugin-versions > etc.: anything wrong with the application? > http scripts not loading after we switched to https... please file a ticket. -- Alessandro Pasotti w3: www.itopen.it ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Share some of my Processing Scripts
I’m ok to share my scripts in the official repository (and thanks a lot for it). In a previous mail, Victor Olaya encouraged the use of progress.setInfo instead of progress.setText and of GeoAlgorithmExecutionException. There may also be some other new programming tools available + some best practices. How late is the documentation and what could be done ? ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Share some of my Processing Scripts
Il 03/06/2014 07:27, kimaidou ha scritto: > It could be handy to be able to add other repositories, as we can for > plugins. This > way anyone can have its own script repository , and share some of the script > when > wanted. The script writers and the end users will have the choice to add some > repositories. Although in principle nice, I think this can prove problematic. For Python plugins we reverted to one centralized repo, to have more consistency and predictability. Thanks Victor (and kimaidou), amazing! A long standing wish fulfilled. -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: 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] Share some of my Processing Scripts
Hi Victor, I am amazed by your reactivity ! Thanks for improving Processing ! My answers : 2014-06-02 23:00 GMT+02:00 Victor Olaya : > I have just uploaded a first version of a tool to manage Processing > resources (basically models and scripts) > > You will find tools named "Get scripts/models from on-line repository" in > the scripts and models branches of the toolbox. They open a dialog where > you can select the elements to install/uninstall, similar to the plugin > manager > I will need to recompile QGIS to test this new feature. Hopefully I will have time at the end of the week. > > Scripts and models are stored in a repo named QGIS-Processing under the > QGIS organization. I recommend all people with scripts/models that they > want to share, to make pull requests against that repo. > This sounds good to me. > > I have added the scripts by Michael and Vincent there, to add some > intitial content (I haven't added any model yet). Please, let me know if > you do not want them to be shared there. > I fully agree to have my scripts shared in this repository. You should probably add a licence file (and a message in the readme) announcing all the scripts in this repository are GPL V2. Thank you for having already added them there. > > There is a list.txt with some info about the resources available. It's > created automatically by running the create_lists.py script, and it acts > like an easy to retrieve index, so there is no need to browse all the > content and extract metadata from the help files. > OK. > > In the help files, there is now a ALG_VERSION element to indicate a > version, which is 1.0 if it is not provided. That allows the interface to > know if a script/model is up to date or not. > ok > > Notice that the format for help files is now json. That solves the issue > that some people reported, cause by trying to unpickle the help > description. I have converted the help files for the scripts that I added > to the repo, using the help_converter.py script. Feel free to use it for > your own scripts if needed (I might remove it from this repo, since i a not > sure it belongs here...maybe better put it as a gist) > Thank you for converting the help files. I think you could keep the converter here for a while, since it does not harm ;) Or add a link to the future gist in the README so that people can easily find it when using QGIS-Processing repository. > > Things to discuss from now: How do we classify the algorithms? How do we > allow people to add new scripts? The pull request mechanism might be too > complex for some people, and the GitHub API allows to add a new file and a > comit to a repo, so we can probably simplify it. > I think someone must review the scripts put in this new repository, since it is the "official" QGIS sharing script repo. Pull requests are good for this. This way some checking could be done by the reviewer : * the category could be checked among a pre-defined required list (to be defined) * the script must have a complete help file to be accepted * the script should not duplicate an existing script (if so better improve the existing script which does the same) etc. > > Ideas are welcome. This is just a first try done in a couple of nights so > there is plenty of room for improvement. > Another idea then ;) It could be handy to be able to add other repositories, as we can for plugins. This way anyone can have its own script repository , and share some of the script when wanted. The script writers and the end users will have the choice to add some repositories. > > Thanks in advance! > Thank you for you amazing work around Processing ! > > > 2014-06-02 10:52 GMT+02:00 kimaidou : > > Hi all >> >> Victor, thanks for your review, I will modify the scripts as soon as >> possible. >> >> Sharing scripts raises some questions : >> >> * How can we categorize the scripts to help the users find one particular >> among the many potential scripts that will be shared ? The "group" can >> help, but any script writer can at present use the group he wants to. For >> example, I used "3liz - Database" or "3liz - Vector", etc which makes sense >> for me, but surely not for other users. >> >> * How do we assure that the user has got the last version of each script >> ? As proposed before, I think some "git magic" could help. >> >> * Because it is more easy to create or modifiy, I usually create >> "scripts". We could on the contrary "force" people who share scripts to use >> the capability of Processing to integrate external algo via "provider". >> This supposes to create a plugin for a set of scripts, which is more >> complicated. But this would answer some of the questions above, for example >> "how do we update the scripts", because QGIS plugin architecture would do >> the job. I would also allow the user to temporarilly disable a set of >> script (by disabling the corresponding plugin). >> >> IMHO we should not add more plugins for sharing scrip
Re: [Qgis-developer] Legend refactoring branch merged
Hi On Mon, Jun 2, 2014 at 10:36 PM, Martin Dobias wrote: > Hi Hugo > > On Mon, Jun 2, 2014 at 10:13 PM, Hugo Mercier > wrote: > > Hi Martin, > > > > Le 21/05/2014 19:11, Martin Dobias a écrit : > >> Hi everyone > >> > >> I have just merged the first part of the legend refactoring work to > >> master [1]. It does not really bring any new features for the end > >> user, the changes are mainly under the hood. Things should ideally > >> work as before, if not then probably it is a bug. > >> > > > > Thanks for all the great work. > > > > When adding a new layer, the behaviour used to be that the new layer was > > placed on top of the active layer. It is not the case anymore if I am > > correct. > > Works for me exactly as expected - new layer is placed on top of the > active layer. > > > > When passing a list of layers in a certain order to > > QgsMapCanvas::setLayerSet(), the obtained order seems random (from > > Python). Is it wanted ? (not sure if it was already the case before your > > changes) > > I am not sure if I understand what you mean order obtained from > where? from map canvas? > > Ah on this topic I dont know if we mentioned it in Vienna when you were gathering requirements, but one thing I *often* get asked by users is why when adding new layers (multiple at once) QGIS does not add them in 'natural z-order' with polygons below then lines in the middle, then points above. Is this something you could do? I believe sorting should only apply to the added layers (so adding the sorted layer above the current layer rather than above the last layer of their geometry type). Though no doubt somebody will think just the opposite:-) Regards Tim > > > Is there a way to modify the order of layers in the legend (and in the > > rendering) via the Python API ? > > Not yet, I am about to add python bindings very soon (tomorrow probably). > > Regards > Martin > ___ > Qgis-developer mailing list > Qgis-developer@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/qgis-developer > -- Tim Sutton - QGIS Project Steering Committee Member == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Irc: timlinux on #qgis at freenode.net == ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Share some of my Processing Scripts
I have just uploaded a first version of a tool to manage Processing resources (basically models and scripts) You will find tools named "Get scripts/models from on-line repository" in the scripts and models branches of the toolbox. They open a dialog where you can select the elements to install/uninstall, similar to the plugin manager Scripts and models are stored in a repo named QGIS-Processing under the QGIS organization. I recommend all people with scripts/models that they want to share, to make pull requests against that repo. I have added the scripts by Michael and Vincent there, to add some intitial content (I haven't added any model yet). Please, let me know if you do not want them to be shared there. There is a list.txt with some info about the resources available. It's created automatically by running the create_lists.py script, and it acts like an easy to retrieve index, so there is no need to browse all the content and extract metadata from the help files. In the help files, there is now a ALG_VERSION element to indicate a version, which is 1.0 if it is not provided. That allows the interface to know if a script/model is up to date or not. Notice that the format for help files is now json. That solves the issue that some people reported, cause by trying to unpickle the help description. I have converted the help files for the scripts that I added to the repo, using the help_converter.py script. Feel free to use it for your own scripts if needed (I might remove it from this repo, since i a not sure it belongs here...maybe better put it as a gist) Things to discuss from now: How do we classify the algorithms? How do we allow people to add new scripts? The pull request mechanism might be too complex for some people, and the GitHub API allows to add a new file and a comit to a repo, so we can probably simplify it. Ideas are welcome. This is just a first try done in a couple of nights so there is plenty of room for improvement. Thanks in advance! 2014-06-02 10:52 GMT+02:00 kimaidou : > Hi all > > Victor, thanks for your review, I will modify the scripts as soon as > possible. > > Sharing scripts raises some questions : > > * How can we categorize the scripts to help the users find one particular > among the many potential scripts that will be shared ? The "group" can > help, but any script writer can at present use the group he wants to. For > example, I used "3liz - Database" or "3liz - Vector", etc which makes sense > for me, but surely not for other users. > > * How do we assure that the user has got the last version of each script ? > As proposed before, I think some "git magic" could help. > > * Because it is more easy to create or modifiy, I usually create > "scripts". We could on the contrary "force" people who share scripts to use > the capability of Processing to integrate external algo via "provider". > This supposes to create a plugin for a set of scripts, which is more > complicated. But this would answer some of the questions above, for example > "how do we update the scripts", because QGIS plugin architecture would do > the job. I would also allow the user to temporarilly disable a set of > script (by disabling the corresponding plugin). > > IMHO we should not add more plugins for sharing scripts, but instead use > the same architecture : we could have a new Processing sub-menu > "Manage/Install external scripts and models" which would show a similar > interface as the plugin manager, and similar features : tagging, vote, > categories, descriptions, etc. > > I confess sharing my scripts had a double objective : > * share them :) > * begin a discussion about the future workflow to share scripts and > algorithms. > > Cheers > Michael > > > > > 2014-06-02 1:27 GMT+02:00 Giovanni Manghi : > > > - Contour : make contours around points at levels (based on the contour >> plugin) >> > - Buffer contour : make and merge circular buffer around points at >> levels >> > - Points at crossing / touching lines : make a point layer where lines >> cross or touch each other (2 scripts) >> > - Fill holes : remove holes in polygons under a certain area >> > - Remove parts : delete parts in multi polygons under a certain area >> > - cut by field : cut one polygon layer by another when 2 polygons share >> a field value >> >> >> very nice both sets of scripts! why not adding them into processing? >> >> cheers! >> >> >> -- G -- >> ___ >> 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 > ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Plugins without source code
Il 02/06/2014 17:12, Martin Dobias ha scritto: > I have just found out there is a plugin "Vgi2Shp" in QGIS plugin > repository, all of its functionality is in a .pyc file - compiled > python module, with no source code (.py). Also the code repository on > GitHub is completely empty. I believe this is not allowed under the > terms of GNU GPL - and probably we do not want to allow such code in > the repository (basically it is an opaque binary blob). What are your > opinions? > > I think we could create a list of unwanted python extensions which > should not be allowed, e.g.: > - .pyc (compiled .py) > - .pyo (optimized .pyc) > - .pyd (compiled module) > > It is clear that this cannot serve as a real security measure as it is > easy for malicious code to work that around anyway - I think it should > be merely a warning to the developers that they may be doing something > wrong. (Packaging a .pyc file is normally useless and just inflates > package size - the .pyc will be created automatically by the > interpreter). > > The question is whether to allow also other binary executables / > libraries, such as: > - .exe > - .dll > - .bat > - .com > - .scr (windows screensaver - same as .exe) > - .so > > [1] https://plugins.qgis.org/plugins/Vgi2ShpConverter/ Thanks Marting for pointing this out. This is also mentioned in the updated guidelines. During my approval process I regularly check the above, so I believe somebody else approved the plugin you mentioned. Of course an hard constraint on the Django application would be preferable. BTW, I now cannot switch between https://plugins.qgis.org/plugins/Vgi2ShpConverter/#plugin-details and https://plugins.qgis.org/plugins/Vgi2ShpConverter/#plugin-versions etc.: anything wrong with the application? All the best. -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: 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] Fwd: request to revert "deprecated" tag for my plugin "SimpliPy"
Hi Albert, Am Sonntag, 1. Juni 2014, 14.28:57 schrieb Albert Ferràs: > > My plugin http://plugins.qgis.org/plugins/simplipy/ has the tag "This > plugin is deprecated" and I don't know why. What can I do to fix this? > I had the same problem with the OpenLayers plugin some time ago. As far as I remember it was solved after removing "deprecated=False" from metadata.txt. Regards Pirmin -- Pirmin Kalberer - @PirminKalberer Sourcepole - http://www.sourcepole.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Plugin site policy
Il 02/06/2014 10:54, Jürgen E. Fischer ha scritto: > Hi Alex, > > On Mon, 02. Jun 2014 at 11:35:23 +0300, Alexander Bruy wrote: >> Also I propose to ask authors of mentioned plugins to add English UI ASAP >> and unapprove plugins after some time if this is not done. > > Asking would be a good thing. > > I'm not so sure about unapproving, as the plugin might still be perfectly > usable, the developer might not be able to translate it to English or the > plugin might have only local application and translating it might be of > limited > value. > > And English description should be feasible for anyone - at least something > that > describes why there is no localization. But IMHO the author should be open > for > contribution - if anyone else wants to help with localization that. Agreed: +1 for asking (I'm doing it for new plugins) -1 for making EN compulsory +1 for asking a code repo: without it it is difficult to cooperate on a plugin, including providing a translation; adding a repo is a matter of 5 min, I see no reason why an author should avoid it. All the best. -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: 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] Fwd: request to revert "deprecated" tag for my plugin "SimpliPy"
Yes; now it's not showing as Deprecated :) Thanks! 2014-06-02 22:32 GMT+02:00 Paolo Cavallini : > Il 02/06/2014 22:09, Alex Mandel ha scritto: > > On 06/01/2014 05:28 AM, Albert Ferràs wrote: > > >> My plugin http://plugins.qgis.org/plugins/simplipy/ has the tag "This > >> plugin is deprecated" and I don't know why. What can I do to fix this? > >> > >> Thanks > >> > > > > I agree that action seems odd. Maybe you accidentally got hit by a > > recent audit. Your plugin does not appear to violate any of the rules > > though. > > > > Thanks for reporting, hopefully one of the repo managers will read this > > and look into fixing. > > This seems to have been fixed already, right? > All the best. > > -- > Paolo Cavallini - www.faunalia.eu > Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html > -- Albert Ferràs ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Fwd: request to revert "deprecated" tag for my plugin "SimpliPy"
Il 02/06/2014 22:09, Alex Mandel ha scritto: > On 06/01/2014 05:28 AM, Albert Ferràs wrote: >> My plugin http://plugins.qgis.org/plugins/simplipy/ has the tag "This >> plugin is deprecated" and I don't know why. What can I do to fix this? >> >> Thanks >> > > I agree that action seems odd. Maybe you accidentally got hit by a > recent audit. Your plugin does not appear to violate any of the rules > though. > > Thanks for reporting, hopefully one of the repo managers will read this > and look into fixing. This seems to have been fixed already, right? All the best. -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: 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] Fwd: request to revert "deprecated" tag for my plugin "SimpliPy"
On 06/01/2014 05:28 AM, Albert Ferràs wrote: > Hi, > > My plugin http://plugins.qgis.org/plugins/simplipy/ has the tag "This > plugin is deprecated" and I don't know why. What can I do to fix this? > > Thanks > I agree that action seems odd. Maybe you accidentally got hit by a recent audit. Your plugin does not appear to violate any of the rules though. Thanks for reporting, hopefully one of the repo managers will read this and look into fixing. Thanks, Alex ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Implemented break lines on intersections option during line layers editing
Hi, I was out for holidays. Ok Tim, I will follow your suggestion ;) I will split only the lines belonging to the same layer, unlike polygons' avoid intersections which operate on all the layers having the option turned on. giovanni Il 01/giu/2014 08:03 "Tim Sutton" ha scritto: > Hi > > > On Fri, May 30, 2014 at 11:53 PM, G. Allegri wrote: > >> I've implemented the option to break lines when a new line intersects >> existing lines on the same layer. >> I've added the option to the "snapping options" dialog. Having the "avoid >> intersections" option for polygons, I've added a new column to define the >> different meanings of the checkbox, in case it's a line layer or a polygon >> layer. See the image: >> http://cdn.img42.com/d77a446f9a52b9d0315c4b78cfce8141.png >> >> Is it ok to add the option over there? >> >> > Nice! Can you remove the abbreviation and change the text to say simply > "Split intersecting lines" (using 'spilt' will be more consistent with > other digitising tools and sounds less negative than break which sounds > like something gets damaged). > > Regards > > Tim > > >> giovanni >> >> -- >> Giovanni Allegri >> http://about.me/giovanniallegri >> Twitter: https://twitter.com/_giohappy_ >> blog: http://blog.spaziogis.it >> GEO+ geomatica in Italia http://bit.ly/GEOplus >> >> ___ >> Qgis-developer mailing list >> Qgis-developer@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/qgis-developer >> > > > > -- > Tim Sutton - QGIS Project Steering Committee Member > == > Please do not email me off-list with technical > support questions. Using the lists will gain > more exposure for your issues and the knowledge > surrounding your issue will be shared with all. > > Irc: timlinux on #qgis at freenode.net > == > ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Legend refactoring branch merged
Hi Hugo On Mon, Jun 2, 2014 at 10:13 PM, Hugo Mercier wrote: > Hi Martin, > > Le 21/05/2014 19:11, Martin Dobias a écrit : >> Hi everyone >> >> I have just merged the first part of the legend refactoring work to >> master [1]. It does not really bring any new features for the end >> user, the changes are mainly under the hood. Things should ideally >> work as before, if not then probably it is a bug. >> > > Thanks for all the great work. > > When adding a new layer, the behaviour used to be that the new layer was > placed on top of the active layer. It is not the case anymore if I am > correct. Works for me exactly as expected - new layer is placed on top of the active layer. > When passing a list of layers in a certain order to > QgsMapCanvas::setLayerSet(), the obtained order seems random (from > Python). Is it wanted ? (not sure if it was already the case before your > changes) I am not sure if I understand what you mean order obtained from where? from map canvas? > Is there a way to modify the order of layers in the legend (and in the > rendering) via the Python API ? Not yet, I am about to add python bindings very soon (tomorrow probably). Regards Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Query layers are bad layers when empty
Hi ! I love the "query layer" feature ! But there's something which makes it unusable : as soon as it returns an empty result set (which is absolutely valid), it is considered as a "bad layer" upon file opening, and the layer is destroyed. When working with spatialite, it triggers the "handle bad layers dialog", which unfortunately is of no help. When working with postgis, it shortly displays a message in the message bar, which I sometimes miss, and I also loose my layers. Here's what I found so far : - when "filtering" a regular spatialite/postgis layer, if the filter filters out every feature, the layer is still valid. (works as expected) - when a query layer returns an empty result set, the layer is considered bad (unexpected). - when a query layer returns an non-empty result set, but the query layer is filtered, the layer is considered bad (unexpected). - empty views work well, filtered or not (works as expected) So, views are a kind of workaround, but depending on the needs (for example if you need to change your query very often), it's not really usable either, because it's much longer to setup and it pollutes the database. Does anyone have a workaround for this ? Why does QGIS have to consider empty query layers as invalid, while they work perfectly well (as long as you don't reopen the file) ? I would definitely create a blocker issue for this (there are already linked issues, see below, but it seems they aren't considered as blockers) : it leads to loosing query layers very easily (and almost silently for postgis). It would be great if this could be fixed for 2.4 ! Thanks for reading ! Olivier PS1 A test setup : https://www.dropbox.com/sh/6jar5134pvqjbjj/AADx9WoUqh3CAAyKQoMAekXla PS2 Some related issues on the tracker : http://hub.qgis.org/issues/7039 (about using message bar for bad layers) http://hub.qgis.org/issues/9708 (WMS bad layers have similar problems) http://hub.qgis.org/issues/9743 (Oracle bad layers have similar problems) http://hub.qgis.org/issues/8718 (feature request which asks for solving this) ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Legend refactoring branch merged
Hi Martin, Le 21/05/2014 19:11, Martin Dobias a écrit : > Hi everyone > > I have just merged the first part of the legend refactoring work to > master [1]. It does not really bring any new features for the end > user, the changes are mainly under the hood. Things should ideally > work as before, if not then probably it is a bug. > Thanks for all the great work. When adding a new layer, the behaviour used to be that the new layer was placed on top of the active layer. It is not the case anymore if I am correct. When passing a list of layers in a certain order to QgsMapCanvas::setLayerSet(), the obtained order seems random (from Python). Is it wanted ? (not sure if it was already the case before your changes) Is there a way to modify the order of layers in the legend (and in the rendering) via the Python API ? ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Plugins without source code
Hi I have just found out there is a plugin "Vgi2Shp" in QGIS plugin repository, all of its functionality is in a .pyc file - compiled python module, with no source code (.py). Also the code repository on GitHub is completely empty. I believe this is not allowed under the terms of GNU GPL - and probably we do not want to allow such code in the repository (basically it is an opaque binary blob). What are your opinions? I think we could create a list of unwanted python extensions which should not be allowed, e.g.: - .pyc (compiled .py) - .pyo (optimized .pyc) - .pyd (compiled module) It is clear that this cannot serve as a real security measure as it is easy for malicious code to work that around anyway - I think it should be merely a warning to the developers that they may be doing something wrong. (Packaging a .pyc file is normally useless and just inflates package size - the .pyc will be created automatically by the interpreter). The question is whether to allow also other binary executables / libraries, such as: - .exe - .dll - .bat - .com - .scr (windows screensaver - same as .exe) - .so [1] https://plugins.qgis.org/plugins/Vgi2ShpConverter/ Regards Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Is there a way to access the GeoProcessing tools in QGIS, in code
Is there a way to access the GeoProcessing tools in QGIS, in code? I want to find the Difference between two layers and make a new shapefile with the result.It can be manually done by selecting vector->GeoProcessing Tools->Difference. But how to do it in my code? (I use python) Please help me to find a solution to this problem ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Plugin site policy
Hi Alex, On Mon, 02. Jun 2014 at 11:35:23 +0300, Alexander Bruy wrote: > Also I propose to ask authors of mentioned plugins to add English UI ASAP > and unapprove plugins after some time if this is not done. Asking would be a good thing. I'm not so sure about unapproving, as the plugin might still be perfectly usable, the developer might not be able to translate it to English or the plugin might have only local application and translating it might be of limited value. And English description should be feasible for anyone - at least something that describes why there is no localization. But IMHO the author should be open for contribution - if anyone else wants to help with localization that. Jürgen -- Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31 Dipl.-Inf. (FH) Rheinstraße 13Fax. +49-4931-918175-50 Software Engineer D-26506 Norden http://www.norbit.de QGIS PSC member (RM) Germany IRC: jef on FreeNode -- norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH Rheinstrasse 13, 26506 Norden GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Share some of my Processing Scripts
Hi all Victor, thanks for your review, I will modify the scripts as soon as possible. Sharing scripts raises some questions : * How can we categorize the scripts to help the users find one particular among the many potential scripts that will be shared ? The "group" can help, but any script writer can at present use the group he wants to. For example, I used "3liz - Database" or "3liz - Vector", etc which makes sense for me, but surely not for other users. * How do we assure that the user has got the last version of each script ? As proposed before, I think some "git magic" could help. * Because it is more easy to create or modifiy, I usually create "scripts". We could on the contrary "force" people who share scripts to use the capability of Processing to integrate external algo via "provider". This supposes to create a plugin for a set of scripts, which is more complicated. But this would answer some of the questions above, for example "how do we update the scripts", because QGIS plugin architecture would do the job. I would also allow the user to temporarilly disable a set of script (by disabling the corresponding plugin). IMHO we should not add more plugins for sharing scripts, but instead use the same architecture : we could have a new Processing sub-menu "Manage/Install external scripts and models" which would show a similar interface as the plugin manager, and similar features : tagging, vote, categories, descriptions, etc. I confess sharing my scripts had a double objective : * share them :) * begin a discussion about the future workflow to share scripts and algorithms. Cheers Michael 2014-06-02 1:27 GMT+02:00 Giovanni Manghi : > > - Contour : make contours around points at levels (based on the contour > plugin) > > - Buffer contour : make and merge circular buffer around points at levels > > - Points at crossing / touching lines : make a point layer where lines > cross or touch each other (2 scripts) > > - Fill holes : remove holes in polygons under a certain area > > - Remove parts : delete parts in multi polygons under a certain area > > - cut by field : cut one polygon layer by another when 2 polygons share > a field value > > > very nice both sets of scripts! why not adding them into processing? > > cheers! > > > -- G -- > ___ > 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
[Qgis-developer] Plugin site policy
Hi all, I found that we have some plugins in plugin repository that doesn't follow repository requirements but were approved by plugin site admins. For example: - Cxf_in (non English description and UI) - geovallecvc (non English description and UI) - vectorGeoref (non English UI) Maybe there are more. I think we should change policy about plugins: lift some requirements that doesn't affect plugin usability (e.g. requirement for plugin repository can be not mandatory) and make more strict requirements that directly affects plugin usage. >From user point of view plugin without information about repository is still useable and can be used without any problems. While plugin that doesn't have English UI is completely unusable if you don't know language used by plugin author. Also I propose to ask authors of mentioned plugins to add English UI ASAP and unapprove plugins after some time if this is not done. -- Alexander Bruy ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] have aggregate/window expressions ever been discussed?
Le 31/05/2014 02:33, Olivier Dalang a écrit : > Hi ! > > Great thread :-) > > Just a thought : if we are able to load shapefiles and other non-db > formats through spatialite, is there a point in still being able to load > them the old way ? Won't this just cause confusion, and force us to > maintain an artificial and less powerful query language ? In my mind, we must not disturb the current way of loading data. > > And what about database data providers, couldn't we load all of them > through spatialite's virtual ogr, so to allow an unified and full > featured spatial query language on ALL layers ? Wouldn't this also open > the door for caching data of distant servers ? Using the SQL dialect of SQLite/Spatialite could allow to add powerful features to poor data formats (shapefiles, csv, etc.) But as discussed, it should not be considered as the unifiying SQL for all SQL dialects (it is less powerful). However, you could use it to offer a unifying view on a set of data sources, including other DBRMS, if you really want to. As discussed elsewhere (http://osgeo-org.1560.x6.nabble.com/Postgis-Caching-Enhancement-td5132383.html), SQLite could also be used for caching. Not sure yet how it could be mixed with the virtual table feature ... ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
