Re: [Qgis-developer] Visualisation of relations

2016-11-01 Thread kimaidou 
Hi all,

Speaking about child tables, I would rather have them presented as table
and not forms by default (or have an option to decide this for QGIS
installation). Usually you only want to see the list of children for each
relation, which is more compact, and show very fast if there is zero or any
children.

Michaël

2016-10-31 14:58 GMT+01:00 Patrick Valsecchi <
patrick.valsec...@camptocamp.com>:

> 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
>
___
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] WFS strange network timeout error on localhost with latest master tests (but not on 127.0.0.1)

2016-11-01 Thread Alessandro Pasotti 
Hi,

I'm trying to solve a strange issue from a QGIS python test in master:

If I use "localhost" in the url, this times out:
assert QgsVectorLayer("version='auto' table='' url='
http://localhost/cgi-bin/qgis_mapserv.fcgi/?map=/home/dev/QGIS/tests/testdata/qgis_server/test_project.qgs'
typename='testlayer_èé' srsname='EPSG:4326'", 'wfs', 'WFS').isValid()

- If I point it to 127.0.0.1 it works normally.
- Both localhost and 127.0.0.1 work as expected from a web browser or for
curl/wget
- Using another server different from qgis shows the same behaviour (hence
it does not depend on qgis server but only on the hostname)
- The same Python code works fine if run from within QGIS master
- I have nothing strange in my /etc/hosts
- This does not depend on ctest: runnig the test directly from python shows
the same problem
- WMS is working fine with both localhost and 127.0.0.1, so far only WFS
shows this problem


Env:
- ubuntu xenial
- Qt 5.5.1

Any idea?

-- 
Alessandro Pasotti
w3:   www.itopen.it
___
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] Field mapper when pasting features

2016-11-01 Thread Denis Rouzaud 
Hi Arnaud,

I am really looking forward to seeing such feature implemented in QGIS,
thanks for bringing up the discussion.

I would also recommend going for a QEP, as it is a largely foreseen
feature, and I suppose everyone has its own definition and use-case...

From my point of view, we should go for a very generic field-mapping
mechanism which could be used in many places such as copy-paste. A way
of reading/saving configuration would be quite useful, like presets.

Best wishes,

Denis

On 10/27/2016 05:52 PM, Arnaud Morvan wrote:
> Hello QGIS devs,
>
> I want to add a field mapper dialog when pasting features to layers.
>
> For now when pasting features with attributes names that do not exists
> on the destination layer,
> those attributes values are lost.
>
> When clipboard fields and destination layer fields are not strictly
> the sames,
> In QGIS 3.0, I want to popup a new dialog with fields mapper
> configurator.
>
> Dialog UI could be similar to Refactor Fields Algorithm, showing a
> list of destination fields :
>
> source expression (expression widgets) => destination field
>
> For example, I often use this workflow :
> Open a shapefile or autocad file.
> Use the refactor fields to get temporary layer with same fields as
> destination.
> Paste to postgis database layer.
>
> I think having this dialog showing up when needed could really ease
> data manipulation from one layer to another.
> And I want to give the possibility to use expressions.
>
> Any remarks, do you think I need to open to open a QEP for that ?
>
> Regards
>

___
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

2016-11-01 Thread Matthias Kuhn 
Hi Richard,

Thanks for the feedback, very interesting.

We have been working on a plugin qgis2compat [1] that aims at being a
legacy layer, so you have to maintain only a single plugin.

1. Migrate to QGIS 3
2. Add some code to load the compatibility layer
3. Add missing compatibility fixes in the qgis2compat plugin

This way one has to manage only a single - QGIS 3 compatible - plugin
and incompatible calls are routed transparently to the appropriate QGIS
2 API. Without any if-version-branches inside your plugin code, so once
the day comes you can just drop the qgis2compat plugin.

Main advantage:
 * maintain a single codebase (!!)
 * the code is clean and targetted at QGIS 3
 * the load for writing versioned calls can be mutualized between
   plugin developers

https://github.com/opengisch/qgis2compat

Cheers
Matthias

On 11/01/2016 08:03 AM, Richard Duivenvoorde wrote:
> On 31-10-16 23:15, Nyall Dawson wrote:
>> 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?
> 
> One thing I learned:
> 
> - IF you make use of a plugin Makefile (if you created a plugin using
> the plugin builder), is to FIRST fix your make file (that is:
> - point to .qgis3 directory instead of .qgis2
> - change pyrcc4 an pyuic4 to pyrcc5 and pyuic5 in your makefile
> - make clean (to get rid of the Qt4-versions of your gui-py files and
> resources
> - run make again to have Qt5 versions of your gui-py's and resources
> - and THEN run [QGIS-repo]/scripts/2to3 
> 
> Else you end up wondering why just half of your python files are 'fixed'
> by the script :-)
> 
> Other point to make:
> - as a lot of deprecated QGIS code is removed: remove all the switches
> you had for < 2.0 (if you have an old plugin :-) ), <2.6 etc etc
> versions of QGIS, as this cleans up nicely
> 
> - FIX all signal slot stuff to use the 'connect'/new way
> 
> - I only had a couple of QGIS-api changes. But that is maybe still coming...
> 
> - Often you can clean __init_.py (as that was used for the 'old'
> waymetadata (which is now in metadata.txt), and I had to keep that for
> very old QGIS version (my plugin should work from 1.8 onwards)
> 
> - maybe some notes about the Qt-wrappers and the future script?
> 
> Some links to add: http://qgis.org/api/api_break.html
> And please add other api change links... I think we should put these on
> the frontpage of qgis.org.. I could not google them easy
> 
>> 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.
> 
> hear hear
> 
> Regards,
> 
> Richard
> ___
> 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] plugin for QGIS3 test

2016-11-01 Thread Richard Duivenvoorde 
On 31-10-16 23:15, Nyall Dawson wrote:
> 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?

One thing I learned:

- IF you make use of a plugin Makefile (if you created a plugin using
the plugin builder), is to FIRST fix your make file (that is:
- point to .qgis3 directory instead of .qgis2
- change pyrcc4 an pyuic4 to pyrcc5 and pyuic5 in your makefile
- make clean (to get rid of the Qt4-versions of your gui-py files and
resources
- run make again to have Qt5 versions of your gui-py's and resources
- and THEN run [QGIS-repo]/scripts/2to3 

Else you end up wondering why just half of your python files are 'fixed'
by the script :-)

Other point to make:
- as a lot of deprecated QGIS code is removed: remove all the switches
you had for < 2.0 (if you have an old plugin :-) ), <2.6 etc etc
versions of QGIS, as this cleans up nicely

- FIX all signal slot stuff to use the 'connect'/new way

- I only had a couple of QGIS-api changes. But that is maybe still coming...

- Often you can clean __init_.py (as that was used for the 'old'
waymetadata (which is now in metadata.txt), and I had to keep that for
very old QGIS version (my plugin should work from 1.8 onwards)

- maybe some notes about the Qt-wrappers and the future script?

Some links to add: http://qgis.org/api/api_break.html
And please add other api change links... I think we should put these on
the frontpage of qgis.org.. I could not google them easy

> 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.

hear hear

Regards,

Richard
___
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