Re: [Qgis-developer] plugin for QGIS3 test

[gordon]

How does one change 2.99 to 3.00 in the development version obtained 
from GitHub because obviously there is a big break between 2.xx and 
3.xx?


I believe the 3.00 version necessary for plugin development with Python 
3.5.2 and Qt5.7.  Or is that a mis-impression?  Something that only 
happens to people who have both version of Python 2.7.x and Python 3.5.x 
and Qt4 and Qt5?


I am still not sure if Qt5.7 has the code fixed for some kind of issue 
that isn't present in Qt4 and that maybe the reason for the delay in 
QGIS.  Is that another mis-impression?  Or has Qt5.7 got the fix 
necessary and there are still some other reasons?


Also, GDAL 2.0 is now required to build the development version, unless 
I am mistaken.  Something the install  documentation clearly didn't 
indicate.


The PyQt issue regarding API version (1 is Qt4 and 2 is Qt5), which 
popped up in debugging with Eclipse, seemed to be fixed by moving 'from 
qgis.core import *' before 'from PyQt4.QtCore *' and 'from PyQt4.QtGui 
import *'.  A fix fortunately documented by someone making more progress 
than me.



___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] QEP #77 accepted - please use new style connect in master

[Nyall Dawson]

Hi all,

Just a heads-up that QEP #77 - "Require use of new style Qt
connections for newly added signals/slots" has been accepted.

This means that ALL newly introduced signals and slots MUST use the
new c++11/qt5 style connection syntax.

You can read more about this requirement at the QEP:

https://github.com/qgis/QGIS-Enhancement-Proposals/issues/77


Executive summary for non-devs:
QGIS will be even more stable and bug-free from now on.

Nyall
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] plugin for QGIS3 test

[Nyall Dawson]

On 1 November 2016 at 07:37, Richard Duivenvoorde  wrote:
> Hi (plugin-) devs,
>
> after upgrading my QGIS 2.18 plugin, I thought to try what I had to do
> to make it a QGIS3 version.
>
> - running scripts/2to3 on the plugin
> - tweaking and fixing untill it worked :-)
>
> it was more work then I hoped, but after setting
>
> qgisMinimumVersion=2.99
> qgisMaximumVersion=3.0
>
> it 'just works' even without my PR [1] which make the list in the plugin
> manager shorter:
> https://plugins.qgis.org/plugins/plugins.xml?qgis=2.99
> vs
> https://plugins.qgis.org/plugins/plugins.xml?qgis=3.0
>
> I observe also that having two version of the same plugin works: the old
> 0.12 version is visible in 2.18
> The new 3.0 version is visible in 3.0
> And I could download/install both in both versions.
>
> Anyway: I think good news to share :-)
>
> NOTE: we should be aware that 3.0 api is still not fixed, so creating a
> 3.0 version is not guaranteed to work with the final 3.0 versions

This is great news!

Given that you're probably the first to go through this process, I'm
very keen to hear any further feedback you have on the porting
process. What did you find hardest? Is the available api break
documentation useful? Could we make it better? Do you have any
suggestions on how we can make this process easier for plugin
developers?

I'd also like to echo your disclaimer that it's premature for general
plugin developers to start porting their plugins yet (unless they
enjoy redoing changes!). There's still many more changes planned
before 3.0 is finalised.

Nyall






>
> and I do not think it is doable to make a plugin working for both 2.x
> and 3.0. But feel free to find out yourself :-)
>
> Regards,
>
> Richard Duivenvoorde
>
> [0] https://github.com/rduivenvoorde/pdokservicesplugin/tree/qgis3branch
> [1] https://github.com/qgis/QGIS/pull/3689
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] plugin for QGIS3 test

[Richard Duivenvoorde]

Hi (plugin-) devs,

after upgrading my QGIS 2.18 plugin, I thought to try what I had to do
to make it a QGIS3 version.

- running scripts/2to3 on the plugin
- tweaking and fixing untill it worked :-)

it was more work then I hoped, but after setting

qgisMinimumVersion=2.99
qgisMaximumVersion=3.0

it 'just works' even without my PR [1] which make the list in the plugin
manager shorter:
https://plugins.qgis.org/plugins/plugins.xml?qgis=2.99
vs
https://plugins.qgis.org/plugins/plugins.xml?qgis=3.0

I observe also that having two version of the same plugin works: the old
0.12 version is visible in 2.18
The new 3.0 version is visible in 3.0
And I could download/install both in both versions.

Anyway: I think good news to share :-)

NOTE: we should be aware that 3.0 api is still not fixed, so creating a
3.0 version is not guaranteed to work with the final 3.0 versions

and I do not think it is doable to make a plugin working for both 2.x
and 3.0. But feel free to find out yourself :-)

Regards,

Richard Duivenvoorde

[0] https://github.com/rduivenvoorde/pdokservicesplugin/tree/qgis3branch
[1] https://github.com/qgis/QGIS/pull/3689
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS setup with Qt 5 on mac

[Matthias Kuhn]

Hi Diane and welcome aboard,

I also didn't manage to compile master on osx yet.

Some more information can be found here also:

https://github.com/OSGeo/homebrew-osgeo4mac/pull/146#issuecomment-254011621

I think most of the dependencies should meanwhile be available on
homebrew (but not sure).

Regards
Matthias

On 10/31/2016 06:56 PM, David Marteau wrote:
> Hi
> 
> I will speak with my own experience using and compiling Qgis on Mac (El 
> capitan and Maverick):
> 
> First I use Macport: MacPort use clang/libc++ by default (at least with XCode 
> 5.3 on Maverick, 7.3 on El capitan) so this should solve one of your problems.
> I have installed qt5 from MacPort without problems. 
> 
> The problems arise with some ports that do not fully support qt5 variants and 
> you need to tweak some portfiles: qscintilla and py-qscintilla are one of 
> them and are required by Qgis. 
> If you are interested I can give you my diff files for portfiles.
> 
> I had to build qwt directly from sources because tweaking Macport portfiles 
> was too painful, but I did not encounter any serious problems as far as I can 
> remember.
> 
> No source code was needed to be patched, only compilation configurations. 
> 
> Once you get all dependencies you need to set the cmake options accordingly 
> to the path of your installation:
> 
> Here is my defines:
> 
> »   »   -DCMAKE_INSTALL_PREFIX:PATH=/Applications \
> »   »   -DWITH_SERVER=ON \
> »   »   -DWITH_PYSPATIALITE=ON \
> »   »   
> -DPYTHON_CUSTOM_FRAMEWORK:PATH=/opt/local/Library/Frameworks/Python.framework 
>  \
> »   »   -DEXPAT_INCLUDE_DIR:PATH=/opt/local/include \
> »   »   -DEXPAT_LIBRARY:FILEPATH=/opt/local/lib/libexpat.dylib \
> »   »   -DSQLITE3_INCLUDE_DIR:PATH=/opt/local/include \
> »   »   -DSQLITE3_LIBRARY:FILEPATH=/opt/local/lib/libsqlite3.dylib \
> »   »   -DQT_QMAKE_EXECUTABLE:FILEPATH=/opt/local/libexec/qt5/bin/qmake \
> »   »   
> -DQWT_INCLUDE_DIR:PATH=/usr/local/qwt-6.1.3/lib/qwt.framework/Versions/6/Headers
>  \
> »   »   
> -DQWT_LIBRARY:FILEPATH=/usr/local/qwt-6.1.3/lib/qwt.framework/Versions/6/qwt \
> »   »   -DQCA_INCLUDE_DIR:PATH=/opt/local/include/qca \
> »   »   -DQCA_LIBRARY:FILEPATH=/opt/local/lib/libqca.dylib \
> »   »   -DQSCINTILLA_INCLUDE_DIR:PATH=/opt/local/libexec/qt5/include \
> »   »   
> -DQSCINTILLA_LIBRARY:FILEPATH=/opt/local/libexec/qt5/lib/libqscintilla2.dylib 
> \
> »   »   -DQT_LRELEASE_EXECUTABLE:FILEPATH=/opt/local/libexec/qt5/bin/lrelease 
> \
> 
> I hope that full support for qt5 will be available from Macport soon, but for 
> now I have managed to compile Qgis from the master branch without struggling 
> too much. 
> 
> Best,
> David 
> 
>> Le 31 oct. 2016 à 16:12, Diane Perez  a écrit :
>>
>> Dear QGIS developers,
>>
>> First of all, thank you very much for the great job, I have been a very 
>> happy user for years !
>>
>> I would like to contribute now to the development, but I found myself stuck 
>> at the installation of dependencies.
>>
>> According to the instructions of the INSTALL file provided with the source 
>> code, mac users should use Qt 4 and compile and install a bunch of 
>> dependencies for which binaries are not available (mainly Spatialindex, SIP, 
>> QScintilla2, PyQt, Qwt and bison) before being able to compile QGIS. I 
>> followed the instructions and got stuck at compiling QGIS as the master now 
>> requires Qt 5.
>>
>> Now as I actually started by installing Qt 5 by mistake, I had the 
>> opportunity to see that it leads to a lot of problems to compile the 
>> dependencies. As far as I understand, Qt 5 requires C++11, which means one 
>> must use the new libc++ library instead of the old libstdc++ (at least on my 
>> configuration, with El Capitan and clang/llvm). Some modifications are such 
>> that mixing both is not possible, so everything must be compiled from start 
>> with C++11 and libc++. Unfortunately most of the dependencies I mention 
>> above do not compile without tweaking, and I stopped doing it when it 
>> started meaning not only modifying the Makefiles but the code itself...
>>
>> I guess some of you work on mac, and have a far better understanding of all 
>> this than me. So my question is : how did you install those dependencies to 
>> compile the last version of QGIS with Qt 5 ? 
>>
>> Did you have to compile again all of them or only a subset using Qt 5 and 
>> C++11 ? If so, how did you do it ? I got stuck at Qwt (6.1.3) which uses 
>> lots of functions deprecated in Qt 5.
>>
>> I hope someone can give me pointers, as I would really like to contribute to 
>> QGIS (and hopefully fix a few bugs bugging me) !
>>
>> Best regards,
>> Diane
>>
>> ___
>> Qgis-developer mailing list
>> Qgis-developer@lists.osgeo.org
>> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> 
> ___
> Qgis-developer 

Re: [Qgis-developer] QGIS setup with Qt 5 on mac

[David Marteau]

Hi

I will speak with my own experience using and compiling Qgis on Mac (El capitan 
and Maverick):

First I use Macport: MacPort use clang/libc++ by default (at least with XCode 
5.3 on Maverick, 7.3 on El capitan) so this should solve one of your problems.
I have installed qt5 from MacPort without problems. 

The problems arise with some ports that do not fully support qt5 variants and 
you need to tweak some portfiles: qscintilla and py-qscintilla are one of them 
and are required by Qgis. 
If you are interested I can give you my diff files for portfiles.

I had to build qwt directly from sources because tweaking Macport portfiles was 
too painful, but I did not encounter any serious problems as far as I can 
remember.

No source code was needed to be patched, only compilation configurations. 

Once you get all dependencies you need to set the cmake options accordingly to 
the path of your installation:

Here is my defines:

»   »   -DCMAKE_INSTALL_PREFIX:PATH=/Applications \
»   »   -DWITH_SERVER=ON \
»   »   -DWITH_PYSPATIALITE=ON \
»   »   
-DPYTHON_CUSTOM_FRAMEWORK:PATH=/opt/local/Library/Frameworks/Python.framework  \
»   »   -DEXPAT_INCLUDE_DIR:PATH=/opt/local/include \
»   »   -DEXPAT_LIBRARY:FILEPATH=/opt/local/lib/libexpat.dylib \
»   »   -DSQLITE3_INCLUDE_DIR:PATH=/opt/local/include \
»   »   -DSQLITE3_LIBRARY:FILEPATH=/opt/local/lib/libsqlite3.dylib \
»   »   -DQT_QMAKE_EXECUTABLE:FILEPATH=/opt/local/libexec/qt5/bin/qmake \
»   »   
-DQWT_INCLUDE_DIR:PATH=/usr/local/qwt-6.1.3/lib/qwt.framework/Versions/6/Headers
 \
»   »   
-DQWT_LIBRARY:FILEPATH=/usr/local/qwt-6.1.3/lib/qwt.framework/Versions/6/qwt \
»   »   -DQCA_INCLUDE_DIR:PATH=/opt/local/include/qca \
»   »   -DQCA_LIBRARY:FILEPATH=/opt/local/lib/libqca.dylib \
»   »   -DQSCINTILLA_INCLUDE_DIR:PATH=/opt/local/libexec/qt5/include \
»   »   
-DQSCINTILLA_LIBRARY:FILEPATH=/opt/local/libexec/qt5/lib/libqscintilla2.dylib \
»   »   -DQT_LRELEASE_EXECUTABLE:FILEPATH=/opt/local/libexec/qt5/bin/lrelease \

I hope that full support for qt5 will be available from Macport soon, but for 
now I have managed to compile Qgis from the master branch without struggling 
too much. 

Best,
David 

> Le 31 oct. 2016 à 16:12, Diane Perez  a écrit :
> 
> Dear QGIS developers,
> 
> First of all, thank you very much for the great job, I have been a very happy 
> user for years !
> 
> I would like to contribute now to the development, but I found myself stuck 
> at the installation of dependencies.
> 
> According to the instructions of the INSTALL file provided with the source 
> code, mac users should use Qt 4 and compile and install a bunch of 
> dependencies for which binaries are not available (mainly Spatialindex, SIP, 
> QScintilla2, PyQt, Qwt and bison) before being able to compile QGIS. I 
> followed the instructions and got stuck at compiling QGIS as the master now 
> requires Qt 5.
> 
> Now as I actually started by installing Qt 5 by mistake, I had the 
> opportunity to see that it leads to a lot of problems to compile the 
> dependencies. As far as I understand, Qt 5 requires C++11, which means one 
> must use the new libc++ library instead of the old libstdc++ (at least on my 
> configuration, with El Capitan and clang/llvm). Some modifications are such 
> that mixing both is not possible, so everything must be compiled from start 
> with C++11 and libc++. Unfortunately most of the dependencies I mention above 
> do not compile without tweaking, and I stopped doing it when it started 
> meaning not only modifying the Makefiles but the code itself...
> 
> I guess some of you work on mac, and have a far better understanding of all 
> this than me. So my question is : how did you install those dependencies to 
> compile the last version of QGIS with Qt 5 ? 
> 
> Did you have to compile again all of them or only a subset using Qt 5 and 
> C++11 ? If so, how did you do it ? I got stuck at Qwt (6.1.3) which uses lots 
> of functions deprecated in Qt 5.
> 
> I hope someone can give me pointers, as I would really like to contribute to 
> QGIS (and hopefully fix a few bugs bugging me) !
> 
> Best regards,
> Diane
> 
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Combo boxes for raster bands

[Denis Rouzaud]

Hi,

As far as I know there is no such thing planned.

The plugin should still be working with 2.x versions.

Otherwise, there might be a developer willing to provide this in 3.x ?

Best regards,

Denis


On 10/27/2016 02:31 PM, EFTAS Fabian Wilske wrote:
> Hello,
>
> in my plugin I successfully connected a QgsFieldComboBox with a 
> QgsMapLayerComboBox to let my user select a field of an already selected 
> vector layer.
>
> Now I want to give my user the opportunity to select a band of an 
> already selected raster layer. How to achieve this?
>
> I guess it should be possible with the QGIS Combo Manager module by 
> Denis Rouzaud which supports band combo boxes 
> (http://3nids.github.io/qgiscombomanager/). But its README tells me that 
> the module is deprecated now because its functionality has been merged 
> into QGIS core. Unfortunately, I couldn't find a QgsBandComboBox (or 
> something like this) class in the QGIS core API and QgsFieldComboBox 
> doesn't work for me with raster layers.
>
> Any idea for combo boxes for raster layer bands using the core API?
>
> Best regards,
> Fabian
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] QGIS setup with Qt 5 on mac

[Diane Perez]

Dear QGIS developers,

First of all, thank you very much for the great job, I have been a very happy 
user for years !

I would like to contribute now to the development, but I found myself stuck at 
the installation of dependencies.

According to the instructions of the INSTALL file provided with the source 
code, mac users should use Qt 4 and compile and install a bunch of dependencies 
for which binaries are not available (mainly Spatialindex, SIP, QScintilla2, 
PyQt, Qwt and bison) before being able to compile QGIS. I followed the 
instructions and got stuck at compiling QGIS as the master now requires Qt 5.

Now as I actually started by installing Qt 5 by mistake, I had the opportunity 
to see that it leads to a lot of problems to compile the dependencies. As far 
as I understand, Qt 5 requires C++11, which means one must use the new libc++ 
library instead of the old libstdc++ (at least on my configuration, with El 
Capitan and clang/llvm). Some modifications are such that mixing both is not 
possible, so everything must be compiled from start with C++11 and libc++. 
Unfortunately most of the dependencies I mention above do not compile without 
tweaking, and I stopped doing it when it started meaning not only modifying the 
Makefiles but the code itself...

I guess some of you work on mac, and have a far better understanding of all 
this than me. So my question is : how did you install those dependencies to 
compile the last version of QGIS with Qt 5 ? 

Did you have to compile again all of them or only a subset using Qt 5 and C++11 
? If so, how did you do it ? I got stuck at Qwt (6.1.3) which uses lots of 
functions deprecated in Qt 5.

I hope someone can give me pointers, as I would really like to contribute to 
QGIS (and hopefully fix a few bugs bugging me) !

Best regards,
Diane

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Visualisation of relations

[Patrick Valsecchi]

OK, I've created a PR for auto-detecting N-1 relations and pick the
RelationReference widget for the foreign key fields.
https://github.com/qgis/QGIS/pull/3699

For the deep relations UX problem, I really don't know. Do we have UX
experts among the QGIS devs?

Thanks.

On Mon, Oct 31, 2016 at 1:51 PM, Matthias Kuhn  wrote:

> On 10/31/2016 01:26 PM, Patrick Valsecchi wrote:
> > Matthias,
> >
> > Hummm... I don't know about the tabs. Initially I was thinking it would
> > be a good idea, then I tried to imagine how it would look like for
> > linked layers within linked layers. We would have two choices:
> >
> >   * Have QTabWidget within QTabWidget: tabs within tabs is a UX nightmare
> >   * Switch to the current way of representing relations for
> > sub-relations: that would lead to user confusion because we have two
> > ways of representing relations.
> >
> > What do you think? To me, tabs is not a good idea.
>
> I think the (current) groupbox within groupbox approach suffers from the
> same UX defficiencies. At least I get confused regularly.
>
> Maybe
>
> * toplevel tabs
> * first sublevel groupbox
> * second sublevel ...
>   groupbox again?
>   skip?
>   button to open in separate window?
>
> Matthias
>
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Visualisation of relations

[Matthias Kuhn]

On 10/31/2016 01:26 PM, Patrick Valsecchi wrote:
> Matthias,
> 
> Hummm... I don't know about the tabs. Initially I was thinking it would
> be a good idea, then I tried to imagine how it would look like for
> linked layers within linked layers. We would have two choices:
> 
>   * Have QTabWidget within QTabWidget: tabs within tabs is a UX nightmare
>   * Switch to the current way of representing relations for
> sub-relations: that would lead to user confusion because we have two
> ways of representing relations.
> 
> What do you think? To me, tabs is not a good idea.

I think the (current) groupbox within groupbox approach suffers from the
same UX defficiencies. At least I get confused regularly.

Maybe

* toplevel tabs
* first sublevel groupbox
* second sublevel ...
  groupbox again?
  skip?
  button to open in separate window?

Matthias
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Documentation proposals - Was: Discussion on the QGIS grant proposals

[DelazJ]

Hi,

I'd like to resurrect this discussion, particularly about the PyCookbook
doc part.

It'd be nice if someone more aware of what's worth putting in the PyQGIS
doc can go through the issues reports in the doc repository and tag the
issues accordingly. Currently tickets are automatically created and not
labeled and the risk is that we document them in the user manual and
automatically close them ignoring they could/should be documented in the
cookbook.

So if any dev interested in the cookbook content can give it a look, it
will be a good step to the upcoming update of this doc (either for 2.18 or
3.x)

Thanks,
Harrissou

2016-10-16 8:48 GMT+02:00 Tim Sutton :

> Hi
>
> On 10 Oct 2016, at 11:22 AM, Luigi Pirelli  wrote:
>
> 3) LTR will will terminate afgter 3.0 release and it's documentation
> will become strongly obsolete with 3.0 transition.
> For this reason I wouldn't invest in ltr pyqgis doc.
>
>
> Just a note that as I recall, our plan was for 3.2 to be the next LTR (so
> 2.14 will probably have a 16month life as LTR).
>
> Regards
>
> Tim
>
>
> Luigi Pirelli
>
> 
> **
> * Boundless QGIS Support/Development: lpirelli AT boundlessgeo DOT com
> * LinkedIn: https://www.linkedin.com/in/luigipirelli
> * Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
> * GitHub: https://github.com/luipir
> * Mastering QGIS:
> https://www.packtpub.com/application-development/mastering-qgis
> 
> **
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
>
>
> ---
>
> *Tim Sutton*
> QGIS Project Steering Committee Chair
> t...@qgis.org
>
>
>
>
>
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Visualisation of relations

[Patrick Valsecchi]

Matthias,

Hummm... I don't know about the tabs. Initially I was thinking it would be
a good idea, then I tried to imagine how it would look like for linked
layers within linked layers. We would have two choices:

   - Have QTabWidget within QTabWidget: tabs within tabs is a UX nightmare
   - Switch to the current way of representing relations for sub-relations:
   that would lead to user confusion because we have two ways of representing
   relations.

What do you think? To me, tabs is not a good idea.

Thanks

On Mon, Oct 31, 2016 at 10:06 AM, Matthias Kuhn  wrote:

> Hi Patrick,
>
> for the side that contains the foreign key, there is the "relation
> reference" widget which has a configuration option "show embedded form"
> (I haven't used it in years and a quick check on it didn't work, so
> maybe it needs fixing).
>
> Agreed, collapsed by default makes sense for huge models. For small ones
> it's a bit strange though. Another approach would be to put them on
> separate tabs by default, I think that could look quite nice also. What
> do you think?
>
> Regards
> Matthias
>
> On 10/31/2016 09:54 AM, Patrick Valsecchi wrote:
> > Hi Matthias,
> >
> > My screenshot shows only 1:N links. N:1 links are not supported. By N:1,
> > I mean the relations from the side that contains the foreign key. If I
> > open the form for the "appart" layer, it doesn't show the linked
> "maison".
> >
> > Yes, the collapsed state is remembered, but the default should be
> > collapsed. If the default is to open everything, the GUI is going to
> > explode if we have hundreds of linked tables.
> >
> > Thanks and CU.
> >
> > On Sun, Oct 16, 2016 at 8:57 AM, Matthias Kuhn  > > wrote:
> >
> > Hi Patrick,
> >
> > Making forms and relations more usable is always welcome.
> >
> > What exactly are the problems you have with the current solution?
> > I see that you mentioned the lack of the N:1 side which is available
> > including add feature, add link, remove feature, remove link pretty
> much
> > the way you describe it. On [1] there is some explanation I wrote on
> the
> > first implementation.
> >
> > I think you should have found that since it's shown on the screenshot
> > which is attached to your mail.
> >
> > Also lazy loading (load when first visible) was introduced once for
> > performance reasons and the collapsed state of the group boxes
> > containing the QgsRelationEditor widget is remembered.
> >
> > So I think that functionality-wise, most of it should be there
> already.
> > With a lot of air left for improvement on the usability side.
> >
> > Cheers
> > Matthias
> >
> > [1] http://blog.vitu.ch/10112013-1201/qgis-relations
> > 
> >
> >
> > On 10/07/2016 09:27 AM, Patrick Valsecchi wrote:
> > > Hi,
> > >
> > > I'm tasked with making QGIS a bit more usable with complex database
> > > schemas having a lot of relations (up to hundreds of linked
> tables). The
> > > INSPIRE people were a bit too inspired when creating their data
> schemas
> > > and now we have to try to make QGIS able to cope with that.
> > >
> > > My concerns with the current situation (as of QGIS master) are:
> > >
> > >   * We can specify the relations between the layers at the project
> > level
> > > (it's now easier with the auto-discover feature for PostGIS and
> > > Spatialite). But those are only showing in the
> QgsAttributeForm for
> > > the 1-N side (the side that doesn't have the foreign key). Why
> not
> > > on the N-1 side?
> > >   * For showing the N-1 side in the QgsAttributeForm, one can
> define a
> > > Join in the layer's properties, but I don't see the point of
> having
> > > to define it here as well when we have already the relations
> info at
> > > the project level. I see a use for special joins, but for
> relations,
> > > I don't see why we have to define it twice. And the way it's
> > > displayed is not allowing to create joins or edit the joined
> fields.
> > >   * I let you imagine the look of the feature attribute form when
> > there
> > > are hundreds of directly and indirectly linked tabled. This is
> just
> > > not usable if we display all of them directly like that. Just
> look
> > > at the attached screen shot that shows what happens by default
> with
> > > only 3 tables. It's already a mess.
> > >
> > > Now, what I propose is:
> > >
> > >   * Not expand the relation widget (QgsCollapsibleGroupBox) by
> default
> > > and build it's content only when it is expanded the first time
> > > (think of what would happen when you have loops in the schema).
> > >   * Show N-1 relations as well, in a collapsed by default
> > > 

Re: [Qgis-developer] New Geometry checker: frequent, unpredictable crashes

[geodrinx]

Inviato da iPhone

> Il giorno 31 ott 2016, alle ore 08:57, Paolo Cavallini 
>  ha scritto:
> 
> Hi all,
> during a recent course, we got what seemed random crashes in Geometry
> chacker, difficult to replicate reliably. Is this a know issue? Can I
> help tracking it down?

Question:  do you tested starting without any plugin ?
... somehow it woks !
;)


> All the best, and thanks.
> -- 
> Paolo Cavallini - www.faunalia.eu
> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
> https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Visualisation of relations

[Matthias Kuhn]

Hi Patrick,

for the side that contains the foreign key, there is the "relation
reference" widget which has a configuration option "show embedded form"
(I haven't used it in years and a quick check on it didn't work, so
maybe it needs fixing).

Agreed, collapsed by default makes sense for huge models. For small ones
it's a bit strange though. Another approach would be to put them on
separate tabs by default, I think that could look quite nice also. What
do you think?

Regards
Matthias

On 10/31/2016 09:54 AM, Patrick Valsecchi wrote:
> Hi Matthias,
> 
> My screenshot shows only 1:N links. N:1 links are not supported. By N:1,
> I mean the relations from the side that contains the foreign key. If I
> open the form for the "appart" layer, it doesn't show the linked "maison".
> 
> Yes, the collapsed state is remembered, but the default should be
> collapsed. If the default is to open everything, the GUI is going to
> explode if we have hundreds of linked tables.
> 
> Thanks and CU.
> 
> On Sun, Oct 16, 2016 at 8:57 AM, Matthias Kuhn  > wrote:
> 
> Hi Patrick,
> 
> Making forms and relations more usable is always welcome.
> 
> What exactly are the problems you have with the current solution?
> I see that you mentioned the lack of the N:1 side which is available
> including add feature, add link, remove feature, remove link pretty much
> the way you describe it. On [1] there is some explanation I wrote on the
> first implementation.
> 
> I think you should have found that since it's shown on the screenshot
> which is attached to your mail.
> 
> Also lazy loading (load when first visible) was introduced once for
> performance reasons and the collapsed state of the group boxes
> containing the QgsRelationEditor widget is remembered.
> 
> So I think that functionality-wise, most of it should be there already.
> With a lot of air left for improvement on the usability side.
> 
> Cheers
> Matthias
> 
> [1] http://blog.vitu.ch/10112013-1201/qgis-relations
> 
> 
> 
> On 10/07/2016 09:27 AM, Patrick Valsecchi wrote:
> > Hi,
> >
> > I'm tasked with making QGIS a bit more usable with complex database
> > schemas having a lot of relations (up to hundreds of linked tables). The
> > INSPIRE people were a bit too inspired when creating their data schemas
> > and now we have to try to make QGIS able to cope with that.
> >
> > My concerns with the current situation (as of QGIS master) are:
> >
> >   * We can specify the relations between the layers at the project
> level
> > (it's now easier with the auto-discover feature for PostGIS and
> > Spatialite). But those are only showing in the QgsAttributeForm for
> > the 1-N side (the side that doesn't have the foreign key). Why not
> > on the N-1 side?
> >   * For showing the N-1 side in the QgsAttributeForm, one can define a
> > Join in the layer's properties, but I don't see the point of having
> > to define it here as well when we have already the relations info at
> > the project level. I see a use for special joins, but for relations,
> > I don't see why we have to define it twice. And the way it's
> > displayed is not allowing to create joins or edit the joined fields.
> >   * I let you imagine the look of the feature attribute form when
> there
> > are hundreds of directly and indirectly linked tabled. This is just
> > not usable if we display all of them directly like that. Just look
> > at the attached screen shot that shows what happens by default with
> > only 3 tables. It's already a mess.
> >
> > Now, what I propose is:
> >
> >   * Not expand the relation widget (QgsCollapsibleGroupBox) by default
> > and build it's content only when it is expanded the first time
> > (think of what would happen when you have loops in the schema).
> >   * Show N-1 relations as well, in a collapsed by default
> > QgsCollapsibleGroupBox, including a way to add a new linked entry,
> > remove the link (put the FK to NULL) and delete it.
> >   * Add a button to open a related feature in a new window.
> >
> > What do you guys think?
> >
> > Thanks.
> >
> >
> >
> > ___
> > Qgis-developer mailing list
> > Qgis-developer@lists.osgeo.org 
> > List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> 
> > Unsubscribe:
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> 
> >
> ___
> 

Re: [Qgis-developer] Visualisation of relations

[Patrick Valsecchi]

Hi Matthias,

My screenshot shows only 1:N links. N:1 links are not supported. By N:1, I
mean the relations from the side that contains the foreign key. If I open
the form for the "appart" layer, it doesn't show the linked "maison".

Yes, the collapsed state is remembered, but the default should be
collapsed. If the default is to open everything, the GUI is going to
explode if we have hundreds of linked tables.

Thanks and CU.

On Sun, Oct 16, 2016 at 8:57 AM, Matthias Kuhn  wrote:

> Hi Patrick,
>
> Making forms and relations more usable is always welcome.
>
> What exactly are the problems you have with the current solution?
> I see that you mentioned the lack of the N:1 side which is available
> including add feature, add link, remove feature, remove link pretty much
> the way you describe it. On [1] there is some explanation I wrote on the
> first implementation.
>
> I think you should have found that since it's shown on the screenshot
> which is attached to your mail.
>
> Also lazy loading (load when first visible) was introduced once for
> performance reasons and the collapsed state of the group boxes
> containing the QgsRelationEditor widget is remembered.
>
> So I think that functionality-wise, most of it should be there already.
> With a lot of air left for improvement on the usability side.
>
> Cheers
> Matthias
>
> [1] http://blog.vitu.ch/10112013-1201/qgis-relations
>
>
> On 10/07/2016 09:27 AM, Patrick Valsecchi wrote:
> > Hi,
> >
> > I'm tasked with making QGIS a bit more usable with complex database
> > schemas having a lot of relations (up to hundreds of linked tables). The
> > INSPIRE people were a bit too inspired when creating their data schemas
> > and now we have to try to make QGIS able to cope with that.
> >
> > My concerns with the current situation (as of QGIS master) are:
> >
> >   * We can specify the relations between the layers at the project level
> > (it's now easier with the auto-discover feature for PostGIS and
> > Spatialite). But those are only showing in the QgsAttributeForm for
> > the 1-N side (the side that doesn't have the foreign key). Why not
> > on the N-1 side?
> >   * For showing the N-1 side in the QgsAttributeForm, one can define a
> > Join in the layer's properties, but I don't see the point of having
> > to define it here as well when we have already the relations info at
> > the project level. I see a use for special joins, but for relations,
> > I don't see why we have to define it twice. And the way it's
> > displayed is not allowing to create joins or edit the joined fields.
> >   * I let you imagine the look of the feature attribute form when there
> > are hundreds of directly and indirectly linked tabled. This is just
> > not usable if we display all of them directly like that. Just look
> > at the attached screen shot that shows what happens by default with
> > only 3 tables. It's already a mess.
> >
> > Now, what I propose is:
> >
> >   * Not expand the relation widget (QgsCollapsibleGroupBox) by default
> > and build it's content only when it is expanded the first time
> > (think of what would happen when you have loops in the schema).
> >   * Show N-1 relations as well, in a collapsed by default
> > QgsCollapsibleGroupBox, including a way to add a new linked entry,
> > remove the link (put the FK to NULL) and delete it.
> >   * Add a button to open a related feature in a new window.
> >
> > What do you guys think?
> >
> > Thanks.
> >
> >
> >
> > ___
> > Qgis-developer mailing list
> > Qgis-developer@lists.osgeo.org
> > List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> > Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> >
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Processing test coverage

[Paolo Cavallini]

Il 24/10/2016 17:38, Paolo Cavallini ha scritto:
> Il 23/10/2016 19:15, Paolo Cavallini ha scritto:
>> Il 23/10/2016 19:07, Matthias Kuhn ha scritto:
>>> Something like this?
>>>
>>> https://github.com/qgis/QGIS/blob/master/python/plugins/processing/tests/README.md
>>
>> Thanks Matthias. IMHO implementing a comprehensive set of tests is of
>> high priority, as well as fixing some crucial issues.
> 
> Hi all,
> from the lack of responses, and of tests created, it appears evident
> that either the interest is not high, or the fruit is hanging too high.
> I'd be in favour of sponsoring the effort, either directly through QGIS
> or indirectly through a crowdfunding effort. Opinions?

Hi all,
I've been thinking about this, and I think a two stages approach would
be more effective. The problems are essentially two:
* algs not producing an output with default params
* algs producing incorrect results, with various combination of parameters.
Problem #1 is far more frequent and important than #2, especially
because of changes in the backends, and far easier to spot.
How difficult would it be just to check whether an output (possibly of
the correct type: vector/raster/html) is produced?
This alone would make the environment far more reliable (someone may
have notices the string of tickets raised by our latest analysis course).
All the best.
-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] New Geometry checker: frequent, unpredictable crashes

[Paolo Cavallini]

Hi all,
during a recent course, we got what seemed random crashes in Geometry
chacker, difficult to replicate reliably. Is this a know issue? Can I
help tracking it down?
All the best, and thanks.
-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer