Re: [QGIS-Developer] Unable to compile QGIS3 plugin

[KOHLMANN Hannes]

Hey Sophie!

There is one .bat file that does all the work of setting the Environment 
variables properly: /osgeo4w_root/bin/python-qgis-dev.bat
Call that file in the console and in the same console cd to the directory with 
the pyrcc.bat file (osgeo4w_root/apps/python36/scripts)

Here is the link to a gis.stackexchange question concerning that:
https://gis.stackexchange.com/questions/260743/how-to-compile-qtdesigner-user-interface-ui-and-resource-qrc-files-with-qg/264377#264377

Good luck and compiling ;)

Cheers,
Hannes
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Microstation DGN v8

[Nyall Dawson]

On 14 March 2018 at 00:46, Carlo A. Bertelli (Charta s.r.l.)
 wrote:
> Anyway, GDAL has a new driver based on the free (as in free speech as well
> as in free beer) Libopencad (https://github.com/sandyre/libopencad), it's
> called OpenCAD: http://www.gdal.org/drv_cad.html.
> Unfortunately it does not cover DGN v8. I think Alexandr Borzykh could
> extend his library to cover it as it is similar to DWG (it has no relation
> to previous "true" DGN format).

This would indeed be very valuable. I personally see it as a critical
risk for open source geo if we can't tighten our links to CAD (and
unfortunately, that means dealing with these proprietary formats).
Let's hope someone steps up and funds this development!

Nyall
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] QgsComposition in QGIS3

[Nyall Dawson]

On 15 March 2018 at 21:28, KOHLMANN Hannes  wrote:

> Since nothing is mentioned in the backwards incompatible changes 
> (https://qgis.org/api/api_break.html) I wanted to ask here, maybe I have just 
> overseen something or am searching for a wrong class (?)

For reference, this is listed in API breaks:
https://qgis.org/api/api_break.html#qgis_api_break_3_0_Composer

Nyall
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] [Qgis-user] QGIS 3 OS X/macOS

[William Kyngesburye]

Oops, accidentally removed QGIS 2 from the page.  Restored now.

> On Mar 15, 2018, at 3:54 PM, Mike Hyslop  wrote:
> 
> There is a “download archive” link on the left under Software Menu. You can 
> find the 2.18 installer there.
> 
> Best,
> Mike 
> 
> On Thu, Mar 15, 2018 at 4:48 PM, Etienne Trimaille 
> > wrote:
> Thanks a lot William for this work! Very very appreciated!
> 
> BTW, I noticed you removed the QGIS 2 installer from the webpage: 
> http://www.kyngchaos.com/software/qgis 
> 
> QGIS 2 is maintained until January 2019, can you put back at least the QGIS 
> 2.18.15 so users can download it again? Thanks.
> https://qgis.org/en/site/getinvolved/development/roadmap.html#release-schedule
>  
> 
> 
> Regards,
> Etienne
> 
> 2018-03-15 2:06 GMT+01:00 David Fawcett  >:
> Thank you William! You provide a very valuable services for all of us who do 
> GIS on a Mac. 
> 
> David.
> 
> On Tue, Mar 13, 2018 at 9:21 PM, Madry, Scott  > wrote:
> Scott Madry
> 
> and just FYI, I had to load matplotlib and scipy to get the Semi Automatic 
> Classification plugin to work.
> 
> S
> > On Mar 12, 2018, at 7:31 PM, Nyall Dawson  > > wrote:
> >
> > On 13 March 2018 at 04:29, William Kyngesburye  > > wrote:
> >> Sorry for the long wait.  It's been a hectic year - personal life changes 
> >> (marriage), but I'm finally getting back into gear.
> >>
> >> My QGIS 3 package for OS X/macOS is ready.
> >
> > Champion! I'm sure you've made a lot of people very happy with this
> > announcement.
> >
> > For those who know what you do, your work is very much valued! It's a
> > shame that packaging is somewhat underappreciated and under-supported
> > by the wider QGIS user community :(
> >
> > Nyall
> >
> >
> >  Besides the big QGIS release, there are a couple other big changes
> > in the packaging.
> >>
> >> - Minimum OS X 10.10 Yosemite
> >>
> >> - Requires Python 3.6 from python.org  (note it must 
> >> be this and not homebrew or other distribution).
> >>
> >> - except for what I include in the GDAL Complete package, all extra 
> >> necessary python modules are available from pypi with pip.  These are 
> >> installed by the QGIS installer and need an internet connection at that 
> >> time.
> >>
> >> Make sure to install Python 3 first, otherwise the GDAL Complete python 
> >> components will not be installed (these are also required by QGIS).
> >>
> >> Currently the globe plugin is not included, but I'll get that out in an 
> >> update soon.  The new QGIS 3D features are included.
> >>
> >> GDAL format plugins will follow soon (ECW, MrSID, GRASS).
> >>
> >> -
> >> William Kyngesburye 
> >> http://www.kyngchaos.com/ 
> >>
> >> The equator is so long, it could encircle the earth completely once.
> >>
> >> ___
> >> Qgis-user mailing list
> >> qgis-u...@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-u...@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-u...@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-u...@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-u...@lists.osgeo.org 
> List info: 

Re: [QGIS-Developer] [Qgis-user] QGIS 3 OS X/macOS

[Etienne Trimaille]

Thanks a lot William for this work! Very very appreciated!

BTW, I noticed you removed the QGIS 2 installer from the webpage:
http://www.kyngchaos.com/software/qgis
QGIS 2 is maintained until January 2019, can you put back at least the QGIS
2.18.15 so users can download it again? Thanks.
https://qgis.org/en/site/getinvolved/development/roadmap.html#release-schedule

Regards,
Etienne

2018-03-15 2:06 GMT+01:00 David Fawcett :

> Thank you William! You provide a very valuable services for all of us who
> do GIS on a Mac.
>
> David.
>
> On Tue, Mar 13, 2018 at 9:21 PM, Madry, Scott 
> wrote:
>
>> Scott Madry
>>
>> and just FYI, I had to load matplotlib and scipy to get the Semi
>> Automatic Classification plugin to work.
>>
>> S
>> > On Mar 12, 2018, at 7:31 PM, Nyall Dawson 
>> wrote:
>> >
>> > On 13 March 2018 at 04:29, William Kyngesburye 
>> wrote:
>> >> Sorry for the long wait.  It's been a hectic year - personal life
>> changes (marriage), but I'm finally getting back into gear.
>> >>
>> >> My QGIS 3 package for OS X/macOS is ready.
>> >
>> > Champion! I'm sure you've made a lot of people very happy with this
>> > announcement.
>> >
>> > For those who know what you do, your work is very much valued! It's a
>> > shame that packaging is somewhat underappreciated and under-supported
>> > by the wider QGIS user community :(
>> >
>> > Nyall
>> >
>> >
>> >  Besides the big QGIS release, there are a couple other big changes
>> > in the packaging.
>> >>
>> >> - Minimum OS X 10.10 Yosemite
>> >>
>> >> - Requires Python 3.6 from python.org (note it must be this and not
>> homebrew or other distribution).
>> >>
>> >> - except for what I include in the GDAL Complete package, all extra
>> necessary python modules are available from pypi with pip.  These are
>> installed by the QGIS installer and need an internet connection at that
>> time.
>> >>
>> >> Make sure to install Python 3 first, otherwise the GDAL Complete
>> python components will not be installed (these are also required by QGIS).
>> >>
>> >> Currently the globe plugin is not included, but I'll get that out in
>> an update soon.  The new QGIS 3D features are included.
>> >>
>> >> GDAL format plugins will follow soon (ECW, MrSID, GRASS).
>> >>
>> >> -
>> >> William Kyngesburye 
>> >> http://www.kyngchaos.com/
>> >>
>> >> The equator is so long, it could encircle the earth completely once.
>> >>
>> >> ___
>> >> Qgis-user mailing list
>> >> qgis-u...@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-u...@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-u...@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-u...@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Unable to compile QGIS3 plugin

[Jürgen E . Fischer]

Hi Sophie,

On Thu, 15. Mar 2018 at 16:54:45 +0100, Sophie Crommelinck wrote:
> Any further idea on what I could try?

run 

call qt5_env.bat
call py3_env.bat

from the OSGeo4W shell before calling pyrcc5.


Jürgen

-- 
Jürgen E. Fischer   norBIT GmbH Tel. +49-4931-918175-31
Dipl.-Inf. (FH) Rheinstraße 13  Fax. +49-4931-918175-50
Software Engineer   D-26506 Norden http://www.norbit.de
QGIS release manager (PSC)  GermanyIRC: jef on FreeNode


signature.asc
Description: PGP signature
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Unable to compile QGIS3 plugin

[Sophie Crommelinck]

Hello,

I would like to make a QGIS3 plugin. I have created the template with the
'Plugin Builder', which creates the plugin folder in
C:\Users\xxx\AppData\Roaming\QGIS\QGIS3\profiles\default\python\plugins.
When I then open the OSGeo4WShell, navigate to the folder and enter 'make',
the following error occurs:

When running 'pyrcc5 -o resources.py resources.qrc' (which should do the
same) the following error occurs:


I thought it might have something to do with Python3 not properly installed
or connected to QGIS3 and reinstalled QGIS and Python with the OSGeo4W
installer without success. I am a little confused by the many pythons
installed somewhere from OSGeo4W and my local Python 2 and 3. I will try
reinstalling all parts to get a better feeling for what comes from where.

Any further idea on what I could try?

Thanks in advance,

Sophie
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] only read name and group name of processing algorithms during startup

[Rashad Kanavath]

Hello,

On Wed, Mar 14, 2018 at 4:38 AM, Nyall Dawson 
wrote:

> On 13 March 2018 at 20:56, Rashad Kanavath  wrote:
> > if a provier is enabled then qgis reads all algorithm's during
> > startup. This involves reading descriptor files and doing all parsing
> > required to make gui when user actually open algorithm (click on
> > treeitem).
> > So If I have like three provider enabled it takes more time to start
> qgis than
> > usual. Even though, I might open one or two later at some point.
> >
> > It is not necessary here to parse "all" data during startup.  name and
> > group name is only needed to fill provider-algorithm tree. This is
> > true for any provider which uses descriptor files (OTB, GRASS, SAGA
> etc..).
>
> Actually it's a bit trickier here -- models make things more complex
> as they self-validate on creation, and need full knowledge of the
> dependent algorithm's parameters and outputs.
>

Yes. there are different cases like modeler, standard, batch, scripts.
I tried to utilize canExecute() in otb and seems to be working.
You already have a very flexible, strong API in qgis processing such
trickier feature like this one has become too easy!!.

I had to call alg.canExecute() in two places and that's it.
diff attached below. With this loading time will be hopefully improved for
OTB, SAGA, GRASS GIS.

index f5bdc40dc5..1cca57769a 100644
--- a/python/plugins/processing/modeler/ModelerParametersDialog.py
+++ b/python/plugins/processing/modeler/ModelerParametersDialog.py
@@ -70,6 +70,7 @@ class ModelerParametersDialog(QDialog):
 QDialog.__init__(self)
 self.setModal(True)
 # The algorithm to define in this dialog. It is an instance of
QgsProcessingModelAlgorithm
+alg.canExecute()
 self._alg = alg
 # The model this algorithm is going to be added to
 self.model = model
@@ -80,6 +81,9 @@ class ModelerParametersDialog(QDialog):
 settings = QgsSettings()
 self.restoreGeometry(settings.value("/Processing/
modelParametersDialogGeometry", QByteArray()))

+def algorithm(self):
+return self._alg
+
 def closeEvent(self, event):
 settings = QgsSettings()
 settings.setValue("/Processing/modelParametersDialogGeometry",
self.saveGeometry())
@@ -242,7 +246,6 @@ class ModelerParametersDialog(QDialog):
 outTypes = []
 elif not isinstance(outTypes, (tuple, list)):
 outTypes = [outTypes]
-
 return self.model.availableSourcesForChild(self.childId,
[p.typeName() for p in paramType if

 issubclass(p, QgsProcessingParameterDefinition)],
[o.typeName() for o in
outTypes if
diff --git a/src/core/processing/models/qgsprocessingmodelchildalgorithm.cpp
b/src/core/processing/models/qgsprocessingmodelchildalgorithm.cpp
index f5f8074c88..01906a7f62 100644
--- a/src/core/processing/models/qgsprocessingmodelchildalgorithm.cpp
+++ b/src/core/processing/models/qgsprocessingmodelchildalgorithm.cpp
@@ -58,7 +58,7 @@ QgsProcessingModelChildAlgorithm &
QgsProcessingModelChildAlgorithm::operator=( c

 const QgsProcessingAlgorithm *QgsProcessingModelChildAlgorithm::algorithm()
const
 {
-  return mAlgorithm.get();
+  return mAlgorithm && mAlgorithm->canExecute() ? mAlgorithm.get():
nullptr;
 }

 void QgsProcessingModelChildAlgorithm::setModelOutputs( const
QMap  )

test code for otb provider:
https://gitlab.orfeo-toolbox.org/orfeotoolbox/qgis-otb-plugin
I can add modification to SAGA and GRASS if you are okay to move this to PR.


> > Issue is more about calling defineDescriptorFile() in Algorithm's
> > __init__ method. And ofcourse, one cannot avoid init when adding
> > algorithm and tree need to add an instance of algorithm. what can be
> > done?
>
> What I've been thinking/planning is to take advantage of task manager
> here. So basically:
>
> - on processing startup, there's no providers added
> - when the qgis interface is fully loaded then we fire up a background
> task which loads the providers, allowing them to fully build their
> available algorithms and parameters without blocking the startup
> - after the task completes, the tree is populated
>

this is still loading all algorithm with parsing but things will be in
background to not block ui for users. correct?
In that case, you could include above diff and then add loading in
background task. IMHO that will be best.


> I'd like to see more plugins take this approach, so that qgis can load
> nice and quick and the slow stuff happens without annoying users...
>
> Nyall
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>



-- 
Regards,
   Rashad
___

Re: [QGIS-Developer] Documentation and algorithm news

[delazj]

Hi, 
Le 15 mars 2018 12:53 PM, matteo  a écrit :
>
> Hi Alexandre,
>
>
> > My suggestion is:
> > 
> > - Keep the branching as it is. That is, branch and release only for QGIS
> > 3.4 LTR
> > - Keep updating the master branch for all 3.x features (if possible giving
> > priority to 3.0 features)
> > - Backport anything missing on 2.18, if applicable.
> > - For changes (in processing or not) specific to 3.2 or 3.4 add a note
> > saying "New in QGIS 3.2" (we could use a substitution for easy tracking).
> > That way, a QGIS 3.0 user using Testing Documentation understands that the
> > feature/parameter or whatever is not yet available for him. (This is how
> > Sphinx documentation does)

This is exactly what i had in mind as a system

> > - Before the release of QGIS 3.4 Documentation, we clean up all those
> > messages.
> > 
> > IMHO, this methodology will keep the simplicity of the process, while
> > allows to document recent changes while they are still fresh.
> > 
Agreed. 

> > About the ALGCHANGE, it's a +0 for me. I would prefer to keep it as simple
> > as possible and try not to have too many tags, The processing one would
> > with the risk that Developers.
>

For information, I assigned all issues updating or creating an alg help to 
Matteo. Not all the Processing issues… yet ;) 

> always thinking aloud (really thinking aloud).. what about branching the
> docs but having a *dynamic* system based just on sphinx .. include:: ? I
> mean, branching the 3.2 release and having the correct index set up with
> just the Processing docs?
>
Fail to see the system but i'm not used to this Sphinx role. 

Regards, 
Harrissou


> Cheers
>
> Matteo
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Documentation and algorithm news

[matteo]

Hi Alexandre,

> I have to agree with Harrissou. Going back to branch documentation at each
> point release will not help, it will only create a bigger burden to a very
> small team of interested people, with lots of commits needing to be ported
> back or forward.
> 
> Although I have proposed to branch 3.0 documents from 2.18 before the
> release in the past, I think that was a different situation, where 2.18
> Docs were almost ready, and QGIS 3 release was yet undetermined.
> 
> I fail to see why Processing should be an exception regarding the rest of
> the documentation. Everywhere, in the document there will be parts that
> will be updated to 3.2 before the official release in QGIS 3.4 (hopefully).
> 
> Nevertheless, I am happy that someone is fully dedicated to it and I don't
> want to frustrate Matteo in his demand to keep everything updated.

no worries ;) I'm glad we are discussing about this topic

> My suggestion is:
> 
> - Keep the branching as it is. That is, branch and release only for QGIS
> 3.4 LTR
> - Keep updating the master branch for all 3.x features (if possible giving
> priority to 3.0 features)
> - Backport anything missing on 2.18, if applicable.
> - For changes (in processing or not) specific to 3.2 or 3.4 add a note
> saying "New in QGIS 3.2" (we could use a substitution for easy tracking).
> That way, a QGIS 3.0 user using Testing Documentation understands that the
> feature/parameter or whatever is not yet available for him. (This is how
> Sphinx documentation does)
> - Before the release of QGIS 3.4 Documentation, we clean up all those
> messages.
> 
> IMHO, this methodology will keep the simplicity of the process, while
> allows to document recent changes while they are still fresh.
> 
> About the ALGCHANGE, it's a +0 for me. I would prefer to keep it as simple
> as possible and try not to have too many tags, The processing one would
> with the risk that Developers.

always thinking aloud (really thinking aloud).. what about branching the
docs but having a *dynamic* system based just on sphinx .. include:: ? I
mean, branching the 3.2 release and having the correct index set up with
just the Processing docs?

Cheers

Matteo

___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] QgsComposition in QGIS3

[Alessandro Pasotti]

Hi,

QgsComposition is gone in favor of the new layout classes: see
https://qgis.org/api/classQgsLayout.html

Have a look to the tests for some usage examples:
https://github.com/qgis/QGIS/blob/master/tests/src/python/test_qgslayout.py

Hope this helps


On Thu, Mar 15, 2018 at 12:28 PM, KOHLMANN Hannes  wrote:

> Hello everyone!
>
>
>
> I have a short question concerning print composition, as I want to do that
> via PyQgis in QGIS3:
>
> I stumbled across the QgsComposition class (http://kartoza.com/en/blog/
> how-to-create-a-qgis-pdf-report-with-a-few-lines-of-python)
>
> I cannot find this class in the Qgis3 API. Usuallly, the Python console in
> QGIS will suggest me available classes as soon as I type the initials, but
> all Qgis shows me are some QgsCompound… classes
>
> Since nothing is mentioned in the backwards incompatible changes (
> https://qgis.org/api/api_break.html) I wanted to ask here, maybe I have
> just overseen something or am searching for a wrong class (?)
>
>
>
> QGIS-Version
>
> 3.0.0-Girona
>
> QGIS-Codeversion
>
> 001c80b0c3 
>
> Kompiliert gegen Qt
>
> 5.9.2
>
> Laufendes Qt
>
> 5.9.2
>
> Kompiliert mit GDAL/OGR
>
> 2.2.3
>
> Läuft mit GDAL/OGR
>
> 2.2.3
>
> Kompiliert mit GEOS
>
> 3.5.0-CAPI-1.9.0
>
> Läuft mit GEOS
>
> 3.5.0-CAPI-1.9.0 r4084
>
> PostgreSQL-Client-Version
>
> 9.2.4
>
> SpatiaLite-Version
>
> 4.3.0
>
> QWT-Version
>
> 6.1.3
>
> QScintilla2-Version
>
> 2.10.1
>
> PROJ.4-Version
>
> 493
>
>
>
> Thanks for help! J
>
>
>
> Best regards,
>
> Hannes K.
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>



-- 
Alessandro Pasotti
w3:   www.itopen.it
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] QgsComposition in QGIS3

[KOHLMANN Hannes]

Hello everyone!

I have a short question concerning print composition, as I want to do that via 
PyQgis in QGIS3:
I stumbled across the QgsComposition class 
(http://kartoza.com/en/blog/how-to-create-a-qgis-pdf-report-with-a-few-lines-of-python)
I cannot find this class in the Qgis3 API. Usuallly, the Python console in QGIS 
will suggest me available classes as soon as I type the initials, but all Qgis 
shows me are some QgsCompound... classes
Since nothing is mentioned in the backwards incompatible changes 
(https://qgis.org/api/api_break.html) I wanted to ask here, maybe I have just 
overseen something or am searching for a wrong class (?)


QGIS-Version


3.0.0-Girona


QGIS-Codeversion


001c80b0c3


Kompiliert gegen Qt


5.9.2


Laufendes Qt


5.9.2


Kompiliert mit GDAL/OGR


2.2.3


Läuft mit GDAL/OGR


2.2.3


Kompiliert mit GEOS


3.5.0-CAPI-1.9.0


Läuft mit GEOS


3.5.0-CAPI-1.9.0 r4084


PostgreSQL-Client-Version


9.2.4


SpatiaLite-Version


4.3.0


QWT-Version


6.1.3


QScintilla2-Version


2.10.1


PROJ.4-Version


493


Thanks for help! :)

Best regards,
Hannes K.
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Documentation and algorithm news

[Alexandre Neto]

Hello all,

I have to agree with Harrissou. Going back to branch documentation at each
point release will not help, it will only create a bigger burden to a very
small team of interested people, with lots of commits needing to be ported
back or forward.

Although I have proposed to branch 3.0 documents from 2.18 before the
release in the past, I think that was a different situation, where 2.18
Docs were almost ready, and QGIS 3 release was yet undetermined.

I fail to see why Processing should be an exception regarding the rest of
the documentation. Everywhere, in the document there will be parts that
will be updated to 3.2 before the official release in QGIS 3.4 (hopefully).

Nevertheless, I am happy that someone is fully dedicated to it and I don't
want to frustrate Matteo in his demand to keep everything updated.

My suggestion is:

- Keep the branching as it is. That is, branch and release only for QGIS
3.4 LTR
- Keep updating the master branch for all 3.x features (if possible giving
priority to 3.0 features)
- Backport anything missing on 2.18, if applicable.
- For changes (in processing or not) specific to 3.2 or 3.4 add a note
saying "New in QGIS 3.2" (we could use a substitution for easy tracking).
That way, a QGIS 3.0 user using Testing Documentation understands that the
feature/parameter or whatever is not yet available for him. (This is how
Sphinx documentation does)
- Before the release of QGIS 3.4 Documentation, we clean up all those
messages.

IMHO, this methodology will keep the simplicity of the process, while
allows to document recent changes while they are still fresh.

About the ALGCHANGE, it's a +0 for me. I would prefer to keep it as simple
as possible and try not to have too many tags, The processing one would
with the risk that Developers.

Best regards,

Alex Neto


matteo  escreveu no dia quinta, 15/03/2018 às
07:34:

> Hi Harrissou,
>
> > Does it mean that current testing becomes 3.0 and testing targets 3.2?
> > When will the doc branched? As soon as the application is released?
> > Because of the low level of man power in doc writing, we decided to have
> a LTR based release plan. Plan we struggle to follow. With the proposed
> system, we could end up with 3/4 branches (from 2.18/3.0 to 3.4) and i'm
> afraid that the only changes among them reside in some algs description.
> Because there are other areas in user manual (but also other docs in a
> branch - cookbook, training, guidelines), there will be an overhead on
> back/forward porting commits. Is syncing some alg description with the
> manual release name worth all this trouble (see below for more context
> explanation)?
>
> that is exactly the point: syncing only the Processing Help doc. As you
> well know currently Processing docs are landed (for 3.0), but for the
> current master some new algorithm is landed and some changes to existing
> algorithms have been made.
>
> > Another point related to quick releases is the "overload" of the doc
> landing page https://docs.qgis.org already crowded with some repetitive
> docs (dev or writers guidelines, GIS introduction in html and pdf +
> translations). For these docs, we can just keep a single version otherwise
> sooner we will kill our servers. See
> http://osgeo-org.1560.x6.nabble.com/Qgis-community-team-Management-of-release-independent-documents-td5318107.html
> for a discussion i fail to raise on this issue year ago.
> >
> >>> * having these branches allows doc writers to update QGIS but,
> >>> especially, Processing Help files
> >
> > Sorry. Even though i understand what you try to say, let me stress that
> there's currently room to update QGIS. There's already a lot to update in
> docs (336 issues in 3.0, 26 for 3.2). Master branch is desperately awaiting
> for writers to update QGIS. People should be aware of that.
> >
> > As i said above, i'm really afraid that it will become only a Processing
> help files branch.
> > Let's analyze the current organisation:
> > * Users (should) know that the latest released doc is 2.18 and the
> testing doc targets 3.4, hence could contain features in development.
> > * In the implemented help system, when you hit a help button in 3.0, 3.1
> (up to 3.4) it will lead you to a page in the testing manual
> >   * if the alg does not change since 3.0, all is good
> >   * if it's a 3.1 documented alg, it's also good: user will find it from
> the application. And if a 3.0 user wonders why this documented alg is not
> available to him, refer to meaning of testing doc.
> >   * if a 3.0 alg is updated (new parameters or changed behavior), here
> could be the issue. Instead of branching the whole doc, maybe we could find
> a system of tag or something like that to help readers identify the
> appropriate description? I guess this kind of system might exist (also it
> should allow to easily find concerned algs so that we regularise the
> description once the LTR is released and "a new master branched").
>
> This was also 

[QGIS-Developer] Plugin [1339] JapanElevation approval notification.

[noreply]

Plugin JapanElevation approval by zimbogisgeek.
The plugin version "[1339] JapanElevation 2.0" is now approved
Link: http://plugins.qgis.org/plugins/JapanElevation/
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Documentation and algorithm news

[matteo]

Hi Harrissou,

> Does it mean that current testing becomes 3.0 and testing targets 3.2?
> When will the doc branched? As soon as the application is released?
> Because of the low level of man power in doc writing, we decided to have a 
> LTR based release plan. Plan we struggle to follow. With the proposed system, 
> we could end up with 3/4 branches (from 2.18/3.0 to 3.4) and i'm afraid that 
> the only changes among them reside in some algs description. Because there 
> are other areas in user manual (but also other docs in a branch - cookbook, 
> training, guidelines), there will be an overhead on back/forward porting 
> commits. Is syncing some alg description with the manual release name worth 
> all this trouble (see below for more context explanation)?

that is exactly the point: syncing only the Processing Help doc. As you
well know currently Processing docs are landed (for 3.0), but for the
current master some new algorithm is landed and some changes to existing
algorithms have been made.

> Another point related to quick releases is the "overload" of the doc landing 
> page https://docs.qgis.org already crowded with some repetitive docs (dev or 
> writers guidelines, GIS introduction in html and pdf + translations). For 
> these docs, we can just keep a single version otherwise sooner we will kill 
> our servers. See 
> http://osgeo-org.1560.x6.nabble.com/Qgis-community-team-Management-of-release-independent-documents-td5318107.html
>  for a discussion i fail to raise on this issue year ago.
> 
>>> * having these branches allows doc writers to update QGIS but,
>>> especially, Processing Help files
> 
> Sorry. Even though i understand what you try to say, let me stress that 
> there's currently room to update QGIS. There's already a lot to update in 
> docs (336 issues in 3.0, 26 for 3.2). Master branch is desperately awaiting 
> for writers to update QGIS. People should be aware of that.
> 
> As i said above, i'm really afraid that it will become only a Processing help 
> files branch.
> Let's analyze the current organisation:
> * Users (should) know that the latest released doc is 2.18 and the testing 
> doc targets 3.4, hence could contain features in development. 
> * In the implemented help system, when you hit a help button in 3.0, 3.1 (up 
> to 3.4) it will lead you to a page in the testing manual
>   * if the alg does not change since 3.0, all is good
>   * if it's a 3.1 documented alg, it's also good: user will find it from the 
> application. And if a 3.0 user wonders why this documented alg is not 
> available to him, refer to meaning of testing doc.
>   * if a 3.0 alg is updated (new parameters or changed behavior), here could 
> be the issue. Instead of branching the whole doc, maybe we could find a 
> system of tag or something like that to help readers identify the appropriate 
> description? I guess this kind of system might exist (also it should allow to 
> easily find concerned algs so that we regularise the description once the LTR 
> is released and "a new master branched").

This was also the initial idea, "detach" in some way the Processing Help
files from the whole folder, what comes in my mind, just thinking aloud:

* having a separate repo (BAD IDEA! for a tons of reasons)
* make separated branches (one for each release) where we now we will
only update Processing files and only build that documentation. This
should not overload the server. Redirecting all the other doc link of
that release to the testing branch. So we will have for example:

https://docs.qgis.org/3.2/en/docs/user_manual/processing_algs/qgis/cartography.htm
that will be build and really exists

https://docs.qgis.org/3.2/en/docs/user_manual/introduction/getting_started.html

that won't be build and that will be redirected to:

https://docs.qgis.org/testing/en/docs/user_manual/introduction/getting_started.html


I think this solution needs a lot of redirecting work

*  other ideas?


>>> * if you devs change something that is linked to Processing algorithm
>>> (new algorithm OR changes to some parameter of existing algorithm) could
>>> you please add the tag "ALGCHANGE" (other name suggestions are welcome)
>>> in the commit message? This will open an issue in the doc repo with a
>>> correct label (and hopefully assign this to me)
>>>
> 
> Not sure it's either needed.
> Many months i'm cleaning the doc repo, and if there are issues i can say are 
> well tagged, it's the processing ones. 99% (to not say, ALL) of the issues 
> related to Processing have [Processing] tag in the commit title. Devs already 
> do that very well in QGIS repo so that i stopped applying the "Processing" 
> label to the generated issue report. It was a needless repetitive task.
> This to say that Processing issues are already easy to find in GitHub repo.
> 
> Now, do we need that someone points that the alg has changed (using an adhoc 
> new tag) to figure it out? If the alg is already documented and there's a new 
> issue report,