If the code snippets are not suitable for the cookbook (because they are
too odd cases and/or they do not match the cookbook chapters) and you
decide to put them anywhere else, it would be good practice to add the
QGIS version number somewhere.
Raymond
On 20-10-2020 11:20, Charles Dixon-Paver wrote:
I agree that the cookbook is a great resource (which is why I put it
first on my list), but I think it's better suited to general examples
and giving a solid outline of the best practices. If it's not kept
concise, it could become a bit of a convoluted mess, in addition to all
the broken code issues Richard raises.
As much as it provides a place for scripts that have common use cases,
there are some scripts I feel are useful to the community that have no
place there, nor do they warrant their own plugin.
For example, if you wanted to print out a list of all the typefaces used
in a project, AFAIK there's a fair number of nested attributes you have
to loop through which I expect a novice would find rather challenging.
At the same time, this hardly seems a relevant use case for the
cookbook. In GIS, I find a lot of people who aren't developers find
themselves with a need to leverage code, so having a way to support
copy-paste programmers is beneficial in my view, but maybe that's just me.
On Tue, 20 Oct 2020 at 10:59, Richard Duivenvoorde <rdmaili...@duif.net
<mailto:rdmaili...@duif.net>> wrote:
On 10/20/20 10:48 AM, Jorge Gustavo Rocha wrote:
> Hi,
>
> I think the PyQGIS Cookbook is the perfect place to share these
scripts. The Cookbook is not the API reference documentation. It is
the place to share solutions for common problems using the QGIS API.
While I agree with this, note that it currently is not 'simple' to
paste some scripts in the cookbook.
Because the cookbook became ... uh a mess, because there were
non-running old examples in it, the cookbook is now build in a way
that the examples IN the cookbook are actually ran/tested
(against/in a Docker QGIS instance). This means that if some api
changes, the build of the cookbook of the examples using that api
would make the build fail. Which is a good check.
But... it also means that 'just copy pasting' some handy examples is
not so easy. You have to make sure that there is data to work with,
or make some mockup first to be able an example etc etc...
So: yes, the cookbook is a good place to showoff use of PyQGIS
examples (and to show the use of (sometimes not so intuitive) PyQGIS
api)... but for practical examples, it takes (for an average PyQGIS
user) maybe too much energy?
OR (not sure if that is possible) we should add some 'sketchy' page
where indeed people can add working examples and which are not
tested... (and which will probably become stale and nobody cares to
fix them... like the old cookbook examples)
Not sure what others think about this though...
Regards,
Richard Duivenvoorde
_______________________________________________
Qgis-user mailing list
Qgis-user@lists.osgeo.org <mailto:Qgis-user@lists.osgeo.org>
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
_______________________________________________
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
_______________________________________________
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
