[Qgis-developer] Plugin [1188] MTOP Open Data approval notification.

[noreply]

Plugin MTOP Open Data approval by pcav.
The plugin version "[1188] MTOP Open Data 1.1 Experimental" is now approved
Link: http://plugins.qgis.org/plugins/MTOPOpenData/
___
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] Plugin [788] Space Syntax Toolkit approval notification.

[noreply]

Plugin Space Syntax Toolkit approval by pcav.
The plugin version "[788] Space Syntax Toolkit 0.1.6" is now approved
Link: http://plugins.qgis.org/plugins/esstoolkit/
___
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] Changing behaviour of "show selected features" mode for attribute table

[Denis Rouzaud]

What about dropping that option and just use the mode last used in the
table display?


Le mar. 7 mars 2017 à 08:46, Nathan Woodrow  a écrit :

Yeah I'm not really ok with a empty table as the default.  I understand the
point but users are going freak at that.

One option might be to ask users what they want when a table is first
opened for the first time.  E.g what default mode would you like with some
notes on each.  This is only asked once and never again but gives the user
the choice.

On Tue, 7 Mar 2017 5:43 pm Denis Rouzaud  wrote:

Thanks for the precision.

Then
+1 for showing nothing when no selection
+0 for "show only selected" as default mode.


Le mar. 7 mars 2017 à 08:30, Nyall Dawson  a écrit :

On 7 March 2017 at 17:23, Denis Rouzaud  wrote:
>
> I'm a bit confused here.
>
> At the moment, there is a global option for attribute table widget "show
> only selected".
> If you choose this option and have a selection, you won't have any mean to
> show all the layer unless you deselect and reopen the attribute table
(hence
> showing all). In other words, switching between show all and show selected
> only has no effect and shows only selected features.
>
> Does your work will fix this i.e. really show all features?

In current master and 2.18 branch if you set the attribute table to
show only selected, and then open the table and change the filter in
the bottom left to "show all", then ALL features will be loaded
(regardless of the current/original selection)

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
___
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] PyQgsServerTest :: test_wms_getprint_srs disabled

[Alessandro Pasotti]

On Tue, Mar 7, 2017 at 8:48 AM, Paul Blottiere 
wrote:

> Alessandro,
>
>
> > do you have clue if the multi-threading rendering could be the root
> cause of this issue?
>
> The test is failing on travis for 2.14 too. However, PR about the
> replacement of the QgsMapRenderer and the parallel rendering activation are
> not backported in 2.14. So, as it happens both on master and 2.14, it seems
> to be independent from the rendering step.
>
>
> Only unit tests on the getprint service has been backported and before
> that, there was none. So I think that the failing test is just underlying
> an old issue which was there even before we started to refactor the server.
>
>
> What do you think?
>

I'm afraid you are right ...

It will be difficult to spot it out, by the way I think that the test did a
good work to discover this issue.

It sounds strange to me that it was never observed in production, but I did
not search the hub for an existing ticket, it might have been reported.



> Paul
>
>
>
> On 03/07/2017 08:16 AM, Alessandro Pasotti wrote:
>
> On Mon, Mar 6, 2017 at 5:30 PM, Paul Blottiere 
> wrote:
>
>> Hi Alessandro,
>>
>>
>> can you please have a look?
>>
>> I'm afraid this failure is not a problem in the test itself but a symptom
>> of more serious issue: the map is completely missing from the generated
>> print.
>>
>> FYI, the same test also fails on 2.14 as discussed on the following
>> commit:
>>
>>
>> I took a look but I cannot reproduce the failing test
>> test_wms_getprint_srs.
>>
>> Actually, I have tested it within the next environment without issues:
>> - master on Debian
>> - release-2_14 on Ubuntu.
>>
>> Can anyone confirm?
>>
>> Paul
>>
>
>
> Paul,
>
> Thanks for looking into this, I'll do some local testing shortly, do you
> have clue if the multi-threading rendering could be the root cause of this
> issue?
>
> A s a side note, I would recommend to refactor the server test and split
> it in smaller dedicated tests for the different services.
>
>
>
> --
> Alessandro Pasotti
> w3:   www.itopen.it
>
>
> ___
> Qgis-developer mailing listqgis-develo...@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

Re: [Qgis-developer] 3.0 Documentation and branching

[yjacolin]

It seems we find a consensus here? Richard are you ok with this:* create 
release-2_18 branch* adapt features tracker if needed* made release-2_18 branch 
the default one* forward porting by contributor or by alexandre
I can't do this before the end of the week as I am on trip for QGIS training. 
Could someone create the branch?
Sorry if I am too fast to conclude. Feel free to give your opinion if necessary.
Thanks.
Y.


Envoyé depuis mon appareil Samsung

 Message d'origine 
De : DelazJ  
Date : 06/03/2017  15:26  (GMT+01:00) 
À : Matthias Kuhn  
Cc : qgis-developer  
Objet : Re: [Qgis-developer] 3.0 Documentation and branching 


2017-03-06 15:20 GMT+01:00 Matthias Kuhn :


Sorry, I explained badly. Pull requests are perfectly fine and desirable

and should be the standard way to contribute for everyone (including

devs). What I wanted to say is that commits (and therefore pull

requests) are preferable over issues because they are written in rst and

not md, unlike issues.


I can't disagree this time!
 

Matthias



___
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] PyQgsServerTest :: test_wms_getprint_srs disabled

[Paul Blottiere]

Alessandro,


> do you have clue if the multi-threading rendering could be the root
cause of this issue?

The test is failing on travis for 2.14 too. However, PR about the
replacement of the QgsMapRenderer and the parallel rendering activation
are not backported in 2.14. So, as it happens both on master and 2.14,
it seems to be independent from the rendering step.


Only unit tests on the getprint service has been backported and before
that, there was none. So I think that the failing test is just
underlying an old issue which was there even before we started to
refactor the server.


What do you think?


Paul



On 03/07/2017 08:16 AM, Alessandro Pasotti wrote:
> On Mon, Mar 6, 2017 at 5:30 PM, Paul Blottiere
> > wrote:
>
> Hi Alessandro,
>
>
>>> can you please have a look?
>>>
>>> I'm afraid this failure is not a problem in the test itself but
>>> a symptom of more serious issue: the map is completely missing
>>> from the generated print.
>> FYI, the same test also fails on 2.14 as discussed on the
>> following commit:
>
> I took a look but I cannot reproduce the failing test
> test_wms_getprint_srs.
>
> Actually, I have tested it within the next environment without issues:
> - master on Debian
> - release-2_14 on Ubuntu.
>
> Can anyone confirm?
>
> Paul
>
>
>
> Paul,
>
> Thanks for looking into this, I'll do some local testing shortly, do
> you have clue if the multi-threading rendering could be the root cause
> of this issue?
>
> A s a side note, I would recommend to refactor the server test and
> split it in smaller dedicated tests for the different services.
>
>
>
> -- 
> 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 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] Processing throws an error

[Paolo Cavallini]

Hi all,
suddenly Processing on 2.18.4 throws an error when right clicking on any
of the Molels > Tools:

"/usr/local/src/qgis/QGIS/build_qgis2/output/python/plugins/processing/gui/ProcessingToolbox.py",
line 208, in showPopupMenu
popupmenu.addSeparator()
UnboundLocalError: local variable 'popupmenu' 
referenced before
assignment

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: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Changing behaviour of "show selected features" mode for attribute table

[Nathan Woodrow]

Yeah I'm not really ok with a empty table as the default.  I understand the
point but users are going freak at that.

One option might be to ask users what they want when a table is first
opened for the first time.  E.g what default mode would you like with some
notes on each.  This is only asked once and never again but gives the user
the choice.

On Tue, 7 Mar 2017 5:43 pm Denis Rouzaud  wrote:

> Thanks for the precision.
>
> Then
> +1 for showing nothing when no selection
> +0 for "show only selected" as default mode.
>
>
> Le mar. 7 mars 2017 à 08:30, Nyall Dawson  a
> écrit :
>
> On 7 March 2017 at 17:23, Denis Rouzaud  wrote:
> >
> > I'm a bit confused here.
> >
> > At the moment, there is a global option for attribute table widget "show
> > only selected".
> > If you choose this option and have a selection, you won't have any mean
> to
> > show all the layer unless you deselect and reopen the attribute table
> (hence
> > showing all). In other words, switching between show all and show
> selected
> > only has no effect and shows only selected features.
> >
> > Does your work will fix this i.e. really show all features?
>
> In current master and 2.18 branch if you set the attribute table to
> show only selected, and then open the table and change the filter in
> the bottom left to "show all", then ALL features will be loaded
> (regardless of the current/original selection)
>
> 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
___
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] Changing behaviour of "show selected features" mode for attribute table

[Denis Rouzaud]

Thanks for the precision.

Then
+1 for showing nothing when no selection
+0 for "show only selected" as default mode.


Le mar. 7 mars 2017 à 08:30, Nyall Dawson  a écrit :

> On 7 March 2017 at 17:23, Denis Rouzaud  wrote:
> >
> > I'm a bit confused here.
> >
> > At the moment, there is a global option for attribute table widget "show
> > only selected".
> > If you choose this option and have a selection, you won't have any mean
> to
> > show all the layer unless you deselect and reopen the attribute table
> (hence
> > showing all). In other words, switching between show all and show
> selected
> > only has no effect and shows only selected features.
> >
> > Does your work will fix this i.e. really show all features?
>
> In current master and 2.18 branch if you set the attribute table to
> show only selected, and then open the table and change the filter in
> the bottom left to "show all", then ALL features will be loaded
> (regardless of the current/original selection)
>
> 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] Changing behaviour of "show selected features" mode for attribute table

[Nyall Dawson]

On 7 March 2017 at 17:23, Denis Rouzaud  wrote:
>
> I'm a bit confused here.
>
> At the moment, there is a global option for attribute table widget "show
> only selected".
> If you choose this option and have a selection, you won't have any mean to
> show all the layer unless you deselect and reopen the attribute table (hence
> showing all). In other words, switching between show all and show selected
> only has no effect and shows only selected features.
>
> Does your work will fix this i.e. really show all features?

In current master and 2.18 branch if you set the attribute table to
show only selected, and then open the table and change the filter in
the bottom left to "show all", then ALL features will be loaded
(regardless of the current/original selection)

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] Changing behaviour of "show selected features" mode for attribute table

[Richard Duivenvoorde]

On 07-03-17 08:08, Paolo Cavallini wrote:
> Il 07/03/2017 05:28, Nyall Dawson ha scritto:
> 
>> Does anyone object to this change landing for 3.0 and 2.18?
> 
> Of course it's a +1 from me.
> I wonder if it would be good to also:
> * set "show selected features" on by default
> * add a warning "no elemenent selected, please do a selection" or
> similar, to avoid the user to think the table is empty.

I'm in favour of this too, just because untill now, the behaviour worked
on small data, but as soon as you work with larger datasets it was bad...

BUT, it should be intuitive for users... people are used to see always a
filled table behaviour...

What about adding a msg+button after opening an empty table:
"Nothing selected so nothing shown" and a dropdown or button: "select
ALL" and "select ALL in current extent"

Setting 'show selected features' on by default...mmm as as it warns me
or is easily stoppable when I load the table for my 12,000,000
postgistable.
I would say: not on by default, but the state saved in the project
configuration, so as soon as user A has selected it for his project with
small tables... keep it like this for a project. For User R which works
with larger datasets, it just works :-)

Regards,

Richard
___
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] Changing behaviour of "show selected features" mode for attribute table

[Denis Rouzaud]

I'm a bit confused here.

At the moment, there is a global option for attribute table widget "show
only selected".
If you choose this option and have a selection, you won't have any mean to
show all the layer unless you deselect and reopen the attribute table
(hence showing all). In other words, switching between show all and show
selected only has no effect and shows only selected features.

Does your work will fix this i.e. really show all features?

In such case, I'm fine with Paolo's proposal (and yours!)
Otherwise I'm -1: opening the table will show nothing (i.e. no selection)
and you won't be able to show the features.

Please enlighten me!

Cheers,
Denis





Le mar. 7 mars 2017 à 08:08, Paolo Cavallini  a
écrit :

> Il 07/03/2017 05:28, Nyall Dawson ha scritto:
>
> > Does anyone object to this change landing for 3.0 and 2.18?
>
> Of course it's a +1 from me.
> I wonder if it would be good to also:
> * set "show selected features" on by default
> * add a warning "no elemenent selected, please do a selection" or
> similar, to avoid the user to think the table is empty.
> 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: 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] Changing behaviour of "show selected features" mode for attribute table

[Neumann, Andreas]

Hi Paolo, 

I am a -1 on having "show only selected features" on by default. I think
that huge/gigantic tables with performance issues are more an exception
than the rule. Of course in such cases the "show selected only" makes
sense and the project should probably retain this state. But in the
majority of other cases the tables are small enough that this is not an
issue and it would be annoying that one has to select features first for
seeing all the features. 

I also don't think we need any warnings. The top window bars clearly
shows the status of total / filtered / selected features. No need for
extra warnings. 

Andreas 

On 2017-03-07 08:08, Paolo Cavallini wrote:

> Il 07/03/2017 05:28, Nyall Dawson ha scritto:
> 
>> Does anyone object to this change landing for 3.0 and 2.18?
> 
> Of course it's a +1 from me.
> I wonder if it would be good to also:
> * set "show selected features" on by default
> * add a warning "no elemenent selected, please do a selection" or
> similar, to avoid the user to think the table is empty.
> All the best.

  ___
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] Changing behaviour of "show selected features" mode for attribute table

[Mathieu Pellerin]

Big +1 too. I always found the current behavior (show all of nothing is
selected) slightly counter-intuitive.

On Tue, Mar 7, 2017 at 11:28 AM, Nyall Dawson 
wrote:

> Hi all,
>
> I'd like to raise discussion about changing the behaviour of the "show
> selected features" mode in the attribute table.
>
> Over the last couple of weeks I've pushed fixes to both 3.0 and
> (shortly) 2.18 to improve the performance of the attribute table when
> this mode is selected (Thanks to Faunalia and ENEL for sponsoring
> this!). With these changes *only* the selected features are fetched
> from providers to show in the attribute table, vs the current
> behaviour of fetching *everything* and then filtering out to the
> selection. It makes a huge difference for working with large layers.
>
> Now - there's one last piece of this I'd like to land, but it changes
> the behaviour of this mode. Currently if you have the table set to
> "show selected features", but there's nothing selected, then ALL
> features are shown.
>
> This kills the benefit of setting the table to show in this mode. If
> you accidentally open the table for a large layer with no selection,
> it'll force every feature to be fetched again.
>
> I'd like to change this, so that no selection = nothing shows in the
> table. This means that users can safely set the attribute table to
> always show in "selected features" mode and be confident that they'll
> never hit the situation where every feature is fetched (unless of
> course they have selected *every* feature!).
>
> Does anyone object to this change landing for 3.0 and 2.18?
>
> 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
___
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] Changing behaviour of "show selected features" mode for attribute table

[Neumann, Andreas]

Hi Nyall, 

I am fine with your proposal. 

In fact, the current behaviour as you described it, can be regarded as a
bug. I agree with you. 

Andreas 

On 2017-03-07 05:28, Nyall Dawson wrote:

> Hi all,
> 
> I'd like to raise discussion about changing the behaviour of the "show
> selected features" mode in the attribute table.
> 
> Over the last couple of weeks I've pushed fixes to both 3.0 and
> (shortly) 2.18 to improve the performance of the attribute table when
> this mode is selected (Thanks to Faunalia and ENEL for sponsoring
> this!). With these changes *only* the selected features are fetched
> from providers to show in the attribute table, vs the current
> behaviour of fetching *everything* and then filtering out to the
> selection. It makes a huge difference for working with large layers.
> 
> Now - there's one last piece of this I'd like to land, but it changes
> the behaviour of this mode. Currently if you have the table set to
> "show selected features", but there's nothing selected, then ALL
> features are shown.
> 
> This kills the benefit of setting the table to show in this mode. If
> you accidentally open the table for a large layer with no selection,
> it'll force every feature to be fetched again.
> 
> I'd like to change this, so that no selection = nothing shows in the
> table. This means that users can safely set the attribute table to
> always show in "selected features" mode and be confident that they'll
> never hit the situation where every feature is fetched (unless of
> course they have selected *every* feature!).
> 
> Does anyone object to this change landing for 3.0 and 2.18?
> 
> 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

  ___
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] is QGIS supposed to build with Qt 5.8?

[G. Allegri]

Thanks Nyall, I will abandon the struggle for now.
I just wanted to try some new features from Qt3D that were added in the
last release.

giovanni

Il 7 mar 2017 01:47, "Nyall Dawson"  ha scritto:

> On 7 March 2017 at 10:41, G. Allegri  wrote:
> > Hi Nyall,
> > Ubuntu 16.04 + Qt Creator 5.8.0 (deb package).
> > Qt 5.8 come from Qt Creator (under /opt path).
> > Qt 5.5 from apt. Generating and building against these is ok.
>
> I'm not sure. I'm not aware of any platforms where QGIS is currently
> built against 5.8 (since 5.8 on homebrew is broken, and all stable
> distros are 5.7. Windows is 5.7 too), so there's possibly things we'll
> need to change.
>
> But last time I tried to build against any non-repo packages on Ubuntu
> I just couldn't get it to succeed either.
>
> 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] PyQgsServerTest :: test_wms_getprint_srs disabled

[Alessandro Pasotti]

On Mon, Mar 6, 2017 at 5:30 PM, Paul Blottiere 
wrote:

> Hi Alessandro,
>
>
> can you please have a look?
>
> I'm afraid this failure is not a problem in the test itself but a symptom
> of more serious issue: the map is completely missing from the generated
> print.
>
> FYI, the same test also fails on 2.14 as discussed on the following commit:
>
>
> I took a look but I cannot reproduce the failing test
> test_wms_getprint_srs.
>
> Actually, I have tested it within the next environment without issues:
> - master on Debian
> - release-2_14 on Ubuntu.
>
> Can anyone confirm?
>
> Paul
>


Paul,

Thanks for looking into this, I'll do some local testing shortly, do you
have clue if the multi-threading rendering could be the root cause of this
issue?

A s a side note, I would recommend to refactor the server test and split it
in smaller dedicated tests for the different services.



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

Re: [Qgis-developer] Changing behaviour of "show selected features" mode for attribute table

[Paolo Cavallini]

Il 07/03/2017 05:28, Nyall Dawson ha scritto:

> Does anyone object to this change landing for 3.0 and 2.18?

Of course it's a +1 from me.
I wonder if it would be good to also:
* set "show selected features" on by default
* add a warning "no elemenent selected, please do a selection" or
similar, to avoid the user to think the table is empty.
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: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] [Processing] Modeler widget wrapper

[Arnaud Morvan]

Hello all,

I've proposed a refactoring of the modeler algorithm dialog :

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

This would come with code simplification, more modularity and port all 
the functionnalities from the algorithm dialog to the modeler algorithm 
dialog.


But as this also has a side effect on the UI, I'd like to have more 
opinion before going deeper on this.


Best regards.

Arnaud Morvan

___
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] 3.0 Documentation and branching

[Paolo Cavallini]

Il 07/03/2017 05:58, Nyall Dawson ha scritto:

> I think a better solution is to hook into the current
> [FEATURE]/[NEEDS-DOCS] hooks which auto-open issues on the
> documentation repo. We could *require* that all developers who push a
> new feature commit have to post on the corresponding documentation
> auto-opened issue with at least very rough notes about how the feature
> is supposed to work. The documentation team could then polish these
> up, add screenshots, etc (and merge when the timing is right for the
> team). This would also keep things as easy as possible for devs so
> that they (*cough*... i mean me *cough*) have no excuse not to do it!

Agreed fully.
Thanks Nyall.
-- 
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: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS 3.0: Plans to support librttopo?

[Nyall Dawson]

On 7 March 2017 at 16:31, Mark Johnson  wrote:
>>> I'm confused - what is missing?
>
> The topic here is that when using MapUnits
> - where the MapUnits are degrees
> that a constant value (valid around the world) is not possible.
>
> If you set this to 5 (intended as meters on the map)
> - the further you zoom in, the circle will get bigger always showing an area
> of 5 meters
>
> If the Map is switched to WSG84
> - then you will get 5 degrees and not the desired area of 5 meters
> --> which for my area would be 0.75, at the equator 0,45 and in you
> area something different
>
> Since the source and destination crs are unknown when this attribute value
> is being set
> - one cannot assume that one or the other use meters and therefore cannot be
> used

It might be unknown at the time of setting that value - but it's
certainly known at the time that
QgsRenderContext::convertToPainterUnits or similar is called!

So you add a new QgsUnitTypes::RenderUnit enum value for
MapUnitMeters, and then if that unit is encountered by
QgsRenderContext::convertToPainterUnits you could do the calculation
from metres -> real map units -> painter units then. (The conversion
value could be cached in the render context to avoid multiple
coordinate transforms)

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 3.0: Plans to support librttopo?

[Mark Johnson]

>> I'm confused - what is missing?

The topic here is that when using MapUnits
- where the MapUnits are degrees
that a constant value (valid around the world) is not possible.

If you set this to 5 (intended as meters on the map)
- the further you zoom in, the circle will get bigger always showing an
area of 5 meters

If the Map is switched to WSG84
- then you will get 5 degrees and not the desired area of 5 meters
--> which for my area would be 0.75, at the equator 0,45 and in you
area something different

Since the source and destination crs are unknown when this attribute value
is being set
- one cannot assume that one or the other use meters and therefore cannot
be used

Mark
___
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 3.0: Plans to support librttopo?

[Nyall Dawson]

On 7 March 2017 at 15:37, Mark Johnson  wrote:
>>> Everything you need should already be encapsulated in QgsRenderContext
>>> (and the QgsMapToPixel member).
>
> For everything but degrees it is.
> But in the case of degrees is is not
> - there the (incorrect) assumption is being made that the world is flat
> The value being used for DEGREE_TO_METER 111319.49079327358
> - is only valid on the Equator
> In my area a degree is around 6,7 meters
> - and this is the value needed
>
>>> This shouldn't be implemented using an external dependency
> I understand the reluctance to adding a further dependency, but GEOS is also
> used
> - and librttopo is an extension of GEOS
>
> Unfortunately there are not many degree based functions that allows the
> combination with a distance as meters.

I'm confused - what is missing? You have the extent, map scale, and
source and destination crs with their corresponding map units. What
more is needed?

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 3.0: Plans to support librttopo?

[Mark Johnson]

>> Everything you need should already be encapsulated in QgsRenderContext
>> (and the QgsMapToPixel member).

For everything but degrees it is.
But in the case of degrees is is not
- there the (incorrect) assumption is being made that the world is flat
The value being used for DEGREE_TO_METER 111319.49079327358
- is only valid on the Equator
In my area a degree is around 6,7 meters
- and this is the value needed

>> This shouldn't be implemented using an external dependency
I understand the reluctance to adding a further dependency, but GEOS is
also used
- and librttopo is an extension of GEOS

Unfortunately there are not many degree based functions that allows the
combination with a distance as meters.

---
Looking at the code yesterday, the following could be a realistic
possiblity to implement this:

QgsMapRenderer:
- add double mMeterAsMapUnit [default 1.0 for meters distance unit]
QgsMapRenderer::setDestinationCrs
// before setExtent is called:
 
mMeterAsMapUnit=QgsUnitTypes::fromUnitToUnitFactor(QGis::Meters,crs.mapUnits());
mRenderContext.setMeterAsMapUnit( mMeterAsMapUnit ) ;

QgsMapRenderer::setExtent

  if ( mSettings.destinationCrs().isGeographic() )
  { // Retrieve realistic MapUnits for a meter based on result of
QgsMapCanvas::center()
   // meterAsMapUnit=
  }

QgsRenderContext
add:
/** 1 meter in Map-Unit*/
double mMeterAsMapUnit;
void setMeterAsMapUnit( double meterAsMapUnit ) {mMeterAsMapUnit =
meterAsMapUnit;}
double meterAsMapUnit() const {return mMeterAsMapUnit;}

QgsSymbolLayerV2Utils::convertToMapUnits:

  switch ( unit )
  {
case QgsSymbolV2::MetersUnit:
{ // Note: must fall through to QgsSymbolV2::MapUnit
 size=size*c.meterAsMapUnit();
}
case QgsSymbolV2::MapUnit:

I will try this out and see if it brings a reasonable result.

Mark Johnson, Berlin Germany
___
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] 3.0 Documentation and branching

[Nyall Dawson]

On 7 March 2017 at 00:26, DelazJ  wrote:
>
> 2017-03-06 15:20 GMT+01:00 Matthias Kuhn :
>>
>>
>> Sorry, I explained badly. Pull requests are perfectly fine and desirable
>> and should be the standard way to contribute for everyone (including
>> devs). What I wanted to say is that commits (and therefore pull
>> requests) are preferable over issues because they are written in rst and
>> not md, unlike issues.
>>
> I can't disagree this time!

Been thinking about this issue Here's what I'm thinking now:

For a while I've pondered whether we should require that all
developers who push a feature also push documentation for that
feature. But after careful thought, I don't think this is a good move.
Here's some reasons why:

- good developers arent necessarily good writers, nor have good English skells
- there's a time investment in learning the documentation setup. This
may detract developers.

I think a better solution is to hook into the current
[FEATURE]/[NEEDS-DOCS] hooks which auto-open issues on the
documentation repo. We could *require* that all developers who push a
new feature commit have to post on the corresponding documentation
auto-opened issue with at least very rough notes about how the feature
is supposed to work. The documentation team could then polish these
up, add screenshots, etc (and merge when the timing is right for the
team). This would also keep things as easy as possible for devs so
that they (*cough*... i mean me *cough*) have no excuse not to do it!

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

[Qgis-developer] Changing behaviour of "show selected features" mode for attribute table

[Nyall Dawson]

Hi all,

I'd like to raise discussion about changing the behaviour of the "show
selected features" mode in the attribute table.

Over the last couple of weeks I've pushed fixes to both 3.0 and
(shortly) 2.18 to improve the performance of the attribute table when
this mode is selected (Thanks to Faunalia and ENEL for sponsoring
this!). With these changes *only* the selected features are fetched
from providers to show in the attribute table, vs the current
behaviour of fetching *everything* and then filtering out to the
selection. It makes a huge difference for working with large layers.

Now - there's one last piece of this I'd like to land, but it changes
the behaviour of this mode. Currently if you have the table set to
"show selected features", but there's nothing selected, then ALL
features are shown.

This kills the benefit of setting the table to show in this mode. If
you accidentally open the table for a large layer with no selection,
it'll force every feature to be fetched again.

I'd like to change this, so that no selection = nothing shows in the
table. This means that users can safely set the attribute table to
always show in "selected features" mode and be confident that they'll
never hit the situation where every feature is fetched (unless of
course they have selected *every* feature!).

Does anyone object to this change landing for 3.0 and 2.18?

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] is QGIS supposed to build with Qt 5.8?

[Nyall Dawson]

On 7 March 2017 at 10:41, G. Allegri  wrote:
> Hi Nyall,
> Ubuntu 16.04 + Qt Creator 5.8.0 (deb package).
> Qt 5.8 come from Qt Creator (under /opt path).
> Qt 5.5 from apt. Generating and building against these is ok.

I'm not sure. I'm not aware of any platforms where QGIS is currently
built against 5.8 (since 5.8 on homebrew is broken, and all stable
distros are 5.7. Windows is 5.7 too), so there's possibly things we'll
need to change.

But last time I tried to build against any non-repo packages on Ubuntu
I just couldn't get it to succeed either.

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] is QGIS supposed to build with Qt 5.8?

[G. Allegri]

Hi Nyall,
Ubuntu 16.04 + Qt Creator 5.8.0 (deb package).
Qt 5.8 come from Qt Creator (under /opt path).
Qt 5.5 from apt. Generating and building against these is ok.

giovanni

Il 7 mar 2017 01:32, "Nyall Dawson"  ha scritto:

On 7 March 2017 at 10:28, G. Allegri  wrote:
> It builds fine with Qt 5.5, but I get tons of errors when building with Qt
> Creator's Qt 5.8 bundle (same cmake configuration except Qt's).
>
> Is it a problem of mine or isn't QGIS ready for Qt 5.8?

What platform? How did you get the libraries?

Nyall

>
> giovanni
>
> ___
> 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] QGIS 3.0: Plans to support librttopo?

[Nyall Dawson]

On 6 March 2017 at 23:45, Mark Johnson  wrote:
> The spatialite function 'ST_Project' is based on the librttopo functionality
> (formally LWGEOM)
> - and is only available when compiled with '--enable-rttopo'
>
> https://git.osgeo.org/gogs/rttopo/librttopo
>
> So if a support for 'Meters as Map units' was desired, in the case of
> degrees
> - the use the librttopo functionality as a part of the 'QgsGeos' would be
> the most effective way to deal with this
>
> This would be a new dependency, but would also offer many other
> functionalities (such as Topology).

Hi Mark,

This shouldn't be implemented using an external dependency -- instead
you'll need to use the existing QGIS classes like
QgsCoordinateTransform. You'd just need to modify:

QgsRenderContext::convertToPainterUnits
QgsRenderContext::convertToMapUnits
QgsRenderContext::convertFromMapUnits

Everything you need should already be encapsulated in QgsRenderContext
(and the QgsMapToPixel member).

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] is QGIS supposed to build with Qt 5.8?

[Nyall Dawson]

On 7 March 2017 at 10:28, G. Allegri  wrote:
> It builds fine with Qt 5.5, but I get tons of errors when building with Qt
> Creator's Qt 5.8 bundle (same cmake configuration except Qt's).
>
> Is it a problem of mine or isn't QGIS ready for Qt 5.8?

What platform? How did you get the libraries?

Nyall

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

[Qgis-developer] is QGIS supposed to build with Qt 5.8?

[G. Allegri]

It builds fine with Qt 5.5, but I get tons of errors when building with Qt
Creator's Qt 5.8 bundle (same cmake configuration except Qt's).

Is it a problem of mine or isn't QGIS ready for Qt 5.8?

giovanni
___
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] Requiring c++17 minimum

[G. Allegri]

Il 7 mar 2017 00:50, "Nathan Woodrow"  ha scritto:

Pro tip: This was a joke by Nyall :) Us Australians have a bad habit of
assuming people get the dry humour we have.

:D


I guessed that but it was too worrying!

The advantages didn't sound well balanced against disadvantages, but I'm
not a C++ pro dev so I wasn't sure if they were true, great, benefits :)

My heartbeat is slowing down again...

giovanni
___
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] Requiring c++17 minimum

[Worth Lutz]

I have customers who use Windows and QGIS. They will not be changing their OS 
as QGIS is not their major task. 
I have others who would be QGIS users if we could convince them to try it.  But 
they too have other tasks which are limited to Windows. 
Unfortunately not all users have the option to change. 

Sent from my iPhone

> On Mar 6, 2017, at 6:35 PM, Nyall Dawson  wrote:
> 
>> On 7 March 2017 at 09:32, Nathan Woodrow  wrote:
>> As a Mircosoft shill, I'm a super -1 on this.  How will I make my money from
>> Microsoft for making QGIS on Windows better?
>> 
>> :)
> 
> I dunno. But some guy blocked me on twitter a couple of weeks ago
> because QGIS is available on Windows. That hurt my feelings.
> 
> Nyall
> 
> 
> 
>> 
>>> On Tue, Mar 7, 2017 at 9:07 AM,  wrote:
>>> 
>>> Isn't it possible that g++ will also run on Windows with c++17 support or
>>> that MSVC will have the features too, or shortly will?  Why eliminate
>>> anyone?
>>> 
>>> Gordon
>>> 
>>> 
 On 2017-03-06 17:00, Nyall Dawson wrote:
 
 Hi all,
 
 I read on phoronix this morning that c++17 is nearly ready. I think
 it's time we made this the minimum build dependency for QGIS (3.0 and
 2.18.5, and maybe 2.14 (but not sure about 2.14 since it's the LTS -
 can someone file a QEP?)).
 
 Advantages:
 - has some neat stuff like parallel algorithms
 - can use std::variant instead of qvariant and std::optional instead
 of QgsOptional
 - 17 is bigger than 11
 
 Disadvantages:
 - I think we lose the Windows builds. That's a shame, but we need to
 move forward.
 - OSX users will need to build their own version of clang/llvm from
 git. That's ok - they are used to things that "just work" so I think
 they'll quickly adapt to this process.
 - Linux users will need to update to the next beta version of their
 distro. This is just a short-term inconvenience and I'm pretty sure
 no-one will lose productivity because of it.
 
 I'm certain this is the way forward, so I'll push a change later today
 requiring this.
 
 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
>>> 
>>> ___
>>> 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
> ___
> 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] Requiring c++17 minimum

[Nathan Woodrow]

Pro tip: This was a joke by Nyall :) Us Australians have a bad habit of
assuming people get the dry humour we have.

:D

On Tue, Mar 7, 2017 at 9:48 AM, Worth Lutz  wrote:

> I have customers who use Windows and QGIS. They will not be changing their
> OS as QGIS is not their major task.
> I have others who would be QGIS users if we could convince them to try
> it.  But they too have other tasks which are limited to Windows.
> Unfortunately not all users have the option to change.
>
> Sent from my iPhone
>
> > On Mar 6, 2017, at 6:35 PM, Nyall Dawson  wrote:
> >
> >> On 7 March 2017 at 09:32, Nathan Woodrow  wrote:
> >> As a Mircosoft shill, I'm a super -1 on this.  How will I make my money
> from
> >> Microsoft for making QGIS on Windows better?
> >>
> >> :)
> >
> > I dunno. But some guy blocked me on twitter a couple of weeks ago
> > because QGIS is available on Windows. That hurt my feelings.
> >
> > Nyall
> >
> >
> >
> >>
> >>> On Tue, Mar 7, 2017 at 9:07 AM,  wrote:
> >>>
> >>> Isn't it possible that g++ will also run on Windows with c++17 support
> or
> >>> that MSVC will have the features too, or shortly will?  Why eliminate
> >>> anyone?
> >>>
> >>> Gordon
> >>>
> >>>
>  On 2017-03-06 17:00, Nyall Dawson wrote:
> 
>  Hi all,
> 
>  I read on phoronix this morning that c++17 is nearly ready. I think
>  it's time we made this the minimum build dependency for QGIS (3.0 and
>  2.18.5, and maybe 2.14 (but not sure about 2.14 since it's the LTS -
>  can someone file a QEP?)).
> 
>  Advantages:
>  - has some neat stuff like parallel algorithms
>  - can use std::variant instead of qvariant and std::optional instead
>  of QgsOptional
>  - 17 is bigger than 11
> 
>  Disadvantages:
>  - I think we lose the Windows builds. That's a shame, but we need to
>  move forward.
>  - OSX users will need to build their own version of clang/llvm from
>  git. That's ok - they are used to things that "just work" so I think
>  they'll quickly adapt to this process.
>  - Linux users will need to update to the next beta version of their
>  distro. This is just a short-term inconvenience and I'm pretty sure
>  no-one will lose productivity because of it.
> 
>  I'm certain this is the way forward, so I'll push a change later today
>  requiring this.
> 
>  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
> >>>
> >>> ___
> >>> 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
> > ___
> > 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] Requiring c++17 minimum

[Nyall Dawson]

On 7 March 2017 at 09:32, Nathan Woodrow  wrote:
> As a Mircosoft shill, I'm a super -1 on this.  How will I make my money from
> Microsoft for making QGIS on Windows better?
>
> :)

I dunno. But some guy blocked me on twitter a couple of weeks ago
because QGIS is available on Windows. That hurt my feelings.

Nyall



>
> On Tue, Mar 7, 2017 at 9:07 AM,  wrote:
>>
>> Isn't it possible that g++ will also run on Windows with c++17 support or
>> that MSVC will have the features too, or shortly will?  Why eliminate
>> anyone?
>>
>> Gordon
>>
>>
>> On 2017-03-06 17:00, Nyall Dawson wrote:
>>>
>>> Hi all,
>>>
>>> I read on phoronix this morning that c++17 is nearly ready. I think
>>> it's time we made this the minimum build dependency for QGIS (3.0 and
>>> 2.18.5, and maybe 2.14 (but not sure about 2.14 since it's the LTS -
>>> can someone file a QEP?)).
>>>
>>> Advantages:
>>> - has some neat stuff like parallel algorithms
>>> - can use std::variant instead of qvariant and std::optional instead
>>> of QgsOptional
>>> - 17 is bigger than 11
>>>
>>> Disadvantages:
>>> - I think we lose the Windows builds. That's a shame, but we need to
>>> move forward.
>>> - OSX users will need to build their own version of clang/llvm from
>>> git. That's ok - they are used to things that "just work" so I think
>>> they'll quickly adapt to this process.
>>> - Linux users will need to update to the next beta version of their
>>> distro. This is just a short-term inconvenience and I'm pretty sure
>>> no-one will lose productivity because of it.
>>>
>>> I'm certain this is the way forward, so I'll push a change later today
>>> requiring this.
>>>
>>> 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
>>
>> ___
>> 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
___
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] Requiring c++17 minimum

[Nathan Woodrow]

As a Mircosoft shill, I'm a super -1 on this.  How will I make my money
from Microsoft for making QGIS on Windows better?

:)

On Tue, Mar 7, 2017 at 9:07 AM,  wrote:

> Isn't it possible that g++ will also run on Windows with c++17 support or
> that MSVC will have the features too, or shortly will?  Why eliminate
> anyone?
>
> Gordon
>
>
> On 2017-03-06 17:00, Nyall Dawson wrote:
>
>> Hi all,
>>
>> I read on phoronix this morning that c++17 is nearly ready. I think
>> it's time we made this the minimum build dependency for QGIS (3.0 and
>> 2.18.5, and maybe 2.14 (but not sure about 2.14 since it's the LTS -
>> can someone file a QEP?)).
>>
>> Advantages:
>> - has some neat stuff like parallel algorithms
>> - can use std::variant instead of qvariant and std::optional instead
>> of QgsOptional
>> - 17 is bigger than 11
>>
>> Disadvantages:
>> - I think we lose the Windows builds. That's a shame, but we need to
>> move forward.
>> - OSX users will need to build their own version of clang/llvm from
>> git. That's ok - they are used to things that "just work" so I think
>> they'll quickly adapt to this process.
>> - Linux users will need to update to the next beta version of their
>> distro. This is just a short-term inconvenience and I'm pretty sure
>> no-one will lose productivity because of it.
>>
>> I'm certain this is the way forward, so I'll push a change later today
>> requiring this.
>>
>> 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
>>
> ___
> 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] Requiring c++17 minimum

[Nyall Dawson]

On 7 March 2017 at 09:07,   wrote:
> Isn't it possible that g++ will also run on Windows with c++17 support or
> that MSVC will have the features too, or shortly will?  Why eliminate
> anyone?

Like Harrissou said - I'm pretty sure none of our users are on Windows
in any case.

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] Requiring c++17 minimum

[gordon]

Isn't it possible that g++ will also run on Windows with c++17 support 
or that MSVC will have the features too, or shortly will?  Why eliminate 
anyone?


Gordon

On 2017-03-06 17:00, Nyall Dawson wrote:

Hi all,

I read on phoronix this morning that c++17 is nearly ready. I think
it's time we made this the minimum build dependency for QGIS (3.0 and
2.18.5, and maybe 2.14 (but not sure about 2.14 since it's the LTS -
can someone file a QEP?)).

Advantages:
- has some neat stuff like parallel algorithms
- can use std::variant instead of qvariant and std::optional instead
of QgsOptional
- 17 is bigger than 11

Disadvantages:
- I think we lose the Windows builds. That's a shame, but we need to
move forward.
- OSX users will need to build their own version of clang/llvm from
git. That's ok - they are used to things that "just work" so I think
they'll quickly adapt to this process.
- Linux users will need to update to the next beta version of their
distro. This is just a short-term inconvenience and I'm pretty sure
no-one will lose productivity because of it.

I'm certain this is the way forward, so I'll push a change later today
requiring this.

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

___
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] Requiring c++17 minimum

[DelazJ]

Hi,
Nyall, +1 from me fwiw.
Actually, I've never understood why QGIS was made available on Windows. If
Windows users want to use QGIS, they just need to move away from that OS.
So easy.
Your plan is hence a good move imho.

Harrissou
Sent from my Windows phone

Le lundi 6 mars 2017, G. Allegri  a écrit :
> Hi Nyall,
> it's not the 1st of April right?
> In all seriousness are you really going to push such a strong requirement?
> What do you mean with "we lose the Windows builds"?!
> Giovanni
> 2017-03-06 23:00 GMT+01:00 Nyall Dawson :
>>
>> Hi all,
>>
>> I read on phoronix this morning that c++17 is nearly ready. I think
>> it's time we made this the minimum build dependency for QGIS (3.0 and
>> 2.18.5, and maybe 2.14 (but not sure about 2.14 since it's the LTS -
>> can someone file a QEP?)).
>>
>> Advantages:
>> - has some neat stuff like parallel algorithms
>> - can use std::variant instead of qvariant and std::optional instead
>> of QgsOptional
>> - 17 is bigger than 11
>>
>> Disadvantages:
>> - I think we lose the Windows builds. That's a shame, but we need to
>> move forward.
>> - OSX users will need to build their own version of clang/llvm from
>> git. That's ok - they are used to things that "just work" so I think
>> they'll quickly adapt to this process.
>> - Linux users will need to update to the next beta version of their
>> distro. This is just a short-term inconvenience and I'm pretty sure
>> no-one will lose productivity because of it.
>>
>> I'm certain this is the way forward, so I'll push a change later today
>> requiring this.
>>
>> 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
>
___
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] Requiring c++17 minimum

[G. Allegri]

Hi Nyall,
it's not the 1st of April right?
In all seriousness are you really going to push such a strong requirement?
What do you mean with "we lose the Windows builds"?!

Giovanni

2017-03-06 23:00 GMT+01:00 Nyall Dawson :

> Hi all,
>
> I read on phoronix this morning that c++17 is nearly ready. I think
> it's time we made this the minimum build dependency for QGIS (3.0 and
> 2.18.5, and maybe 2.14 (but not sure about 2.14 since it's the LTS -
> can someone file a QEP?)).
>
> Advantages:
> - has some neat stuff like parallel algorithms
> - can use std::variant instead of qvariant and std::optional instead
> of QgsOptional
> - 17 is bigger than 11
>
> Disadvantages:
> - I think we lose the Windows builds. That's a shame, but we need to
> move forward.
> - OSX users will need to build their own version of clang/llvm from
> git. That's ok - they are used to things that "just work" so I think
> they'll quickly adapt to this process.
> - Linux users will need to update to the next beta version of their
> distro. This is just a short-term inconvenience and I'm pretty sure
> no-one will lose productivity because of it.
>
> I'm certain this is the way forward, so I'll push a change later today
> requiring this.
>
> 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
___
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] Requiring c++17 minimum

[Nyall Dawson]

Hi all,

I read on phoronix this morning that c++17 is nearly ready. I think
it's time we made this the minimum build dependency for QGIS (3.0 and
2.18.5, and maybe 2.14 (but not sure about 2.14 since it's the LTS -
can someone file a QEP?)).

Advantages:
- has some neat stuff like parallel algorithms
- can use std::variant instead of qvariant and std::optional instead
of QgsOptional
- 17 is bigger than 11

Disadvantages:
- I think we lose the Windows builds. That's a shame, but we need to
move forward.
- OSX users will need to build their own version of clang/llvm from
git. That's ok - they are used to things that "just work" so I think
they'll quickly adapt to this process.
- Linux users will need to update to the next beta version of their
distro. This is just a short-term inconvenience and I'm pretty sure
no-one will lose productivity because of it.

I'm certain this is the way forward, so I'll push a change later today
requiring this.

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] Change numbers in Processing algorithms

[matteo]

sorry Alex, I checked better and found the issue

sorry for the noise

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] Change numbers in Processing algorithms

[Alexander Bruy]

Please check bugtracker before reporting an issue.
This bug was already reported and confirmed.

2017-03-06 19:32 GMT+02:00 matteo :
> Hi all,
>
> I noticed a strange behavior in Processing algorithms (all of them seem
> affected).
>
> When one parameter is a number and the algorithm provides some default
> values, if I change the number hitting TAB or even by clicking with the
> mouse on another field, the number is reseted to the default value.
>
> The only way to add the number seems to click on the ... and write the
> number in the Expression Box
>
> Someone else can confirm?
>
> Thanks
>
> 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



-- 
Alexander Bruy
___
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] Change numbers in Processing algorithms

[matteo]

Hi all,

I noticed a strange behavior in Processing algorithms (all of them seem
affected).

When one parameter is a number and the algorithm provides some default
values, if I change the number hitting TAB or even by clicking with the
mouse on another field, the number is reseted to the default value.

The only way to add the number seems to click on the ... and write the
number in the Expression Box

Someone else can confirm?

Thanks

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] PyQgsServerTest :: test_wms_getprint_srs disabled

[Matthias Kuhn]

Hi Paul,

On 03/06/2017 05:30 PM, Paul Blottiere wrote:
> Hi Alessandro,
> 
> 
>>> can you please have a look?
>>>
>>> I'm afraid this failure is not a problem in the test itself but a
>>> symptom of more serious issue: the map is completely missing from the
>>> generated print.
>> FYI, the same test also fails on 2.14 as discussed on the following
>> commit:
> 
> I took a look but I cannot reproduce the failing test
> test_wms_getprint_srs.
> 
> Actually, I have tested it within the next environment without issues:
> - master on Debian
> - release-2_14 on Ubuntu.

The test also only failed one out of 30 times on travis, so I guess it's
a tricky one to get a lead.

I'd recommend to run it in a loop locally and see if you can reproduce
it this way.

If you really don't find a way to reproduce this locally but have some
suspicion, you can also introduce some additional tests or debug output
that might help to assess the problem and re-enable the test on travis.

This way at least we have more information on travis the next time it fails.

Bests
Matthias
___
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] Plugin with custom QGIS-Qt Widget for master

[matteo]

> Yes you can place it manually

done I can see them now in Qt designer 5 ;) thanks!

still don't loaded in QGIS
___
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] Plugin [1187] Split Polygon Showing Areas approval notification.

[noreply]

Plugin Split Polygon Showing Areas approval by pcav.
The plugin version "[1187] Split Polygon Showing Areas 0.1" is now approved
Link: http://plugins.qgis.org/plugins/SplitPolygonShowingAreas/
___
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] Plugin with custom QGIS-Qt Widget for master

[matteo]

I think I don't have the plugins for qt5:

matteo@matteo-computer:~$ locate libqgis_customwidgets.so
/home/matteo/lavori/QGIS/build-qgis3/output/lib/libqgis_customwidgets.so
/home/matteo/lavori/QGIS/build-qgis3/output/lib/libqgis_customwidgets.so.2.99.0
/home/matteo/lavori/QGIS/build-qgis33/output/lib/libqgis_customwidgets.so
/home/matteo/lavori/QGIS/build-qgis33/output/lib/libqgis_customwidgets.so.2.99.0
/usr/lib/x86_64-linux-gnu/qt4/plugins/designer/libqgis_customwidgets.so
/usr/lib/x86_64-linux-gnu/qt4/plugins/designer/libqgis_customwidgets.so.2.18.4

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] Plugin with custom QGIS-Qt Widget for master

[Denis Rouzaud]

Le lun. 6 mars 2017 à 16:32, matteo  a écrit :

> Hi Denis,
>
> > I think you should either use "make install" which will take care of this
> > or either define properly the python path.
>
> it is so comfortable to load directly from the output directory without
> writing on the disk. ;)
>
>
> > That is because you are still using a Qt4 designer with the Qt5 custom
> > widget library.
> > You have to use a Qt5 designer.
> > Then, you have either to use "make install" to properly place the files
> or
> > manually place the customwidget lib in the Qt5 designer path + run
> designer
> > with path to build qgis core + gui.
>
> OK.. so by placing the file of above in the python3 directory
> (/usr/lib/.) and by loading Qt Designer 5 I should be ready to use
> just the correct widgets for QGIS3?
>

on my computer (fedora), I have
/usr/lib64/qt5/plugins/designer/libqgis_customwidgets.so

then just make sure it finds the proper core + gui libs (run
ldd /usr/lib64/qt5/plugins/designer/libqgis_customwidgets.so and see if no
error is raised)

>
>
> > You should be able to keep both installation of QGIS 2 and 3, and the
> > corresponding custom widget (Qt4 and Qt5). (don't start mixing QGIS 2 +
> Qt5
> > ;) )
>
> ahha for sure not! I have QGIS2 and QGIS3 installed but I don't want to
> mix stuff in there!
>
> Thanks!
>
> 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] Plugin with custom QGIS-Qt Widget for master

[Denis Rouzaud]

Well,

just use qgis.PyQt.uic, it will use automatically the proper version.
It would be a good test to see if your path is set up properly.

Le lun. 6 mars 2017 à 16:11, matteo  a écrit :

> Hi Gino,
>
> >> pyuic4 -o Bar.py Bar.ui
>
> mmm pyuic4 or pyuic5?
>
> Thanks!
>
> 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] Plugin with custom QGIS-Qt Widget for master

[Luigi Pirelli]

the error depend on the content of ui file not how it is loaded,

you can check what is loaded compiling Bar.ui with:

> pyuic4 -o Bar.py Bar.ui

there you'll find what are the include used and than what whould be
the elements you need to configure in you custom widget in QtCreator
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 2nd Edition:
* 
https://www.packtpub.com/big-data-and-business-intelligence/mastering-qgis-second-edition
**


On 6 March 2017 at 15:57, matteo  wrote:
> Hi Denis,
>
> this the code that loads the UI:
>
> FORM_CLASS, _ = uic.loadUiType(os.path.join(
> os.path.dirname(__file__), '../ui/Bar.ui'))
>
> class BarPlotDialog(QtWidgets.QDialog, FORM_CLASS):
> def __init__(self, parent=None):
> """Constructor."""
> super(BarPlotDialog, self).__init__(parent)
>
>
> should be the standard one to load them right?
>
> Thanks!
>
> 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] Plugin with custom QGIS-Qt Widget for master

[matteo]

Hi Gino,

>> pyuic4 -o Bar.py Bar.ui

mmm pyuic4 or pyuic5?

Thanks!

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] Plugin with custom QGIS-Qt Widget for master

[matteo]

bindugfhTDQGT.bin
Description: PGP/MIME version identification


encrypted.asc
Description: OpenPGP encrypted message
___
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] Plugin with custom QGIS-Qt Widget for master

[matteo]

Hi Denis,

this the code that loads the UI:

FORM_CLASS, _ = uic.loadUiType(os.path.join(
os.path.dirname(__file__), '../ui/Bar.ui'))

class BarPlotDialog(QtWidgets.QDialog, FORM_CLASS):
def __init__(self, parent=None):
"""Constructor."""
super(BarPlotDialog, self).__init__(parent)


should be the standard one to load them right?

Thanks!

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] p.write() throws an error

[Paolo Cavallini]

Il 06/03/2017 15:33, kimaidou ha scritto:
> Can anyone else test and report there is no pbm ? Paolo, could you give
> more information on QGIS Version / Platform and status of project file (
> new not saved, saved, etc.)

Thanks Michaël for following this up.
QGIS both 2.14 and 2.18, latest version
OS both Debian Testing and Windows 10 (on other PC with Win it did not
happen)
It seems to happen (only?) when there are unsaved changes to the project.
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: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] p.write() throws an error

[kimaidou]

Hi Paolo,

As you tested, this is not related to Lizmap plugin, because you told me
you tested the following python code inside your Python console and got the
same error

p = QgsProject.instance()
if p.isDirty():
p.write()


Can anyone else test and report there is no pbm ? Paolo, could you give
more information on QGIS Version / Platform and status of project file (
new not saved, saved, etc.)

Cheers
Michaël

2017-03-03 9:33 GMT+01:00 Paolo Cavallini :

> Hi all,
> while using the latest version of Lizmap plugin, I get an error on some
> machines;
> ===
> 2017-03-01T16:50:09 1   Traceback (most recent call last):
>   File 
> "/home/paolo/.qgis2/python/plugins/lizmap/lizmap.py",
> line
> 2718, in run
> if not self.dlg.isVisible() and self.
> checkGlobalProjectOptions():
>   File 
> "/home/paolo/.qgis2/python/plugins/lizmap/lizmap.py",
> line
> 2377, in checkGlobalProjectOptions
> p.write()
> TypeError: write() takes exactly 2 arguments (1
> given)
> ===
> So apparently sip bindings have a problem here.
>
> 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: 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] 3.0 Documentation and branching

[DelazJ]

2017-03-06 15:20 GMT+01:00 Matthias Kuhn :

>
> Sorry, I explained badly. Pull requests are perfectly fine and desirable
> and should be the standard way to contribute for everyone (including
> devs). What I wanted to say is that commits (and therefore pull
> requests) are preferable over issues because they are written in rst and
> not md, unlike issues.
>
> I can't disagree this time!


> Matthias
>
___
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] 3.0 Documentation and branching

[John Hawkinson]

Good documentation processes encourage documentation to land when
features land. If the process doesn't do that, QGIS will always be
falling behind.

--jh...@mit.edu
  John Hawkinson
___
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] 3.0 Documentation and branching

[Matthias Kuhn]

> I do not understand your 1, 2, 3 points (actually I have some subtle
> disagreement i think :-) ) but yes, the end would be to have
> manual_en_2.14, manual_en_2.18 and master which will become
> manual_en_3.2 when released.

Please do disagree!

> And I prefer the term of forwardporting from 2.18 to master than
> backporting to avoid misunderstanding about the direction of the port.

Totally no preference from my side, commits can be ported whatever way
you prefer.

> The advantage of this is, that new features can immediately be
> documented in rst (and not only md as in the issue tracker) as soon as
> someone wants.
> 
> I still prefer pull requests (because PRs are a good way to avoid
> breakage/typos and also a kind of "what's new in QGIS?") but yes direct
> contribution from devs to doc will be possible.

Sorry, I explained badly. Pull requests are perfectly fine and desirable
and should be the standard way to contribute for everyone (including
devs). What I wanted to say is that commits (and therefore pull
requests) are preferable over issues because they are written in rst and
not md, unlike issues.

Matthias
___
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] 3.0 Documentation and branching

[DelazJ]

Tom, I agree with you that not having a documentation uptodate is a big
fail of the project. But I think it would not be that big if users were
aware of any strategy about documentation.
I think that:
- if we can release a doc concurrently with the application release (and
that's a huge target!)
- AND if users are aware that only LTR releases will be documented
- AND that there's a testing doc for non-LTR release
we would cover some gaps.

I'm not sure that the release cycle is a big problem. QGIS has gained
maturity and many features with this system. However I recall few years ago
discussion about integrating documentation as a part of any new features
from sponsors. Was that rejected? Is it followed?

Anyway, would be nice if a grant proposal could come on this side of the
project... _Harrissou dreaming..._

Harrissou

2017-03-06 14:01 GMT+01:00 Tom Chadwin :

> A quick, sweeping, unhelpful but important opinion from me (non-dev,
> non-doc-writer).
>
> Please don't think that retrospective documentation, and lack of docs for
> current release (not master, but current non-LTR release) is good, just
> because that's how it is now. This is the *biggest* failing of the QGIS
> project when stacked up against commercial alternatives. Can you imagine a
> professional software package being released without full docs?
>
> I know that we just don't have the resources to improve this to where it
> should be, but perhaps this would be an argument to slow down the release
> cycle.
>
> To make it absolutely clear: that fact that current latest release of QGIS
> doesn't have docs is a huge failure.
>
> 
>
>
>
> -
> Buy Pie Spy: Adventures in British pastry 2010-11 on Amazon
> --
> View this message in context: http://osgeo-org.1560.x6.
> nabble.com/3-0-Documentation-and-branching-tp5306770p5310924.html
> Sent from the QGIS - Developer mailing list archive at Nabble.com.
> ___
> 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] 3.0 Documentation and branching

[DelazJ]

2017-03-06 13:41 GMT+01:00 Matthias Kuhn :

> Hello Alexandre,
>
> If I interpret your message correctly, you propose to
>
> 1. Match the branch names on QGIS-Documentation with the branch names
>of the QGIS repository
>
> 2. Only create branches for "documentation target" (read LTR) releases
>
> 3. Define one of the branches as "current translation target"
>
> For now we would therefore have
>
>  release-2_14 (translation target)
>  release-2_18
>  master (will become release-3.0 or release-3.2)
>
> Main work will be on master but backporting should be done whenever
> possible.
> Branches can be end-of-lifed as soon as LTR-period ends and branched off
> of master in parallel to the main QGIS repo.
>
> I do not understand your 1, 2, 3 points (actually I have some subtle
disagreement i think :-) ) but yes, the end would be to have
manual_en_2.14, manual_en_2.18 and master which will become manual_en_3.2
when released.
And I prefer the term of forwardporting from 2.18 to master than
backporting to avoid misunderstanding about the direction of the port.

The advantage of this is, that new features can immediately be
> documented in rst (and not only md as in the issue tracker) as soon as
> someone wants.
>
> I still prefer pull requests (because PRs are a good way to avoid
breakage/typos and also a kind of "what's new in QGIS?") but yes direct
contribution from devs to doc will be possible.

Harrissou

If we run into major merge troubles in the worst case, text can still be
> copy-pasted. That's actually the same amount than it is copying text
> from issues.
>
> Did I forget something?
>
> I think this sounds like a very good approach, I actually can't see any
> downsides.
>
> Bests
> Matthias
>
> On 03/06/2017 01:15 PM, Alexandre Neto wrote:
> > Hello all,
> >
> > This will be my last arguments in this thread. After these arguments, if
> > I fail to make myself clear, or you guys simply disagree with my point
> > of view, let's just carry on with our lives. I don't want to waste
> > people's time (at least not documenting time :-P)
> >
> > Richard Duivenvoorde >
> > escreveu no dia segunda, 6/03/2017 às 07:33:
> >
> > On 06-03-17 00:32, Alexandre Neto wrote:
> > > A dom, 5/03/2017, 21:56, Richard Duivenvoorde  > 
> > > >>
> escreveu:
> > >
> > > So do I understand correct that people want to write docs for
> > 3.0 in a
> > > 'fake'-3.0 branch, and the plan is then when master becomes
> > really 3.0
> > > all these changes will be cherry picked from that branch?
> > > Because I think that will be hard to do given those
> > branches will
> > > divert from each other, and it is already pretty hard to have
> > a good
> > > overview as of where to place pieces of info.
> > >
> > > Not sure if I followed your idea when you mention a "fake" 3.0
> branch.
> > > My idea would be to have a 2.18 branch and a master branch
> > (effectively
> > > aiming at 2.99 development).
> > > When a documenter work in a new feature description, he would do it
> > > directly on master and, if that feature was already available on
> qgis
> > > 2.18, backport that description to the 2.18 branch. If it's a
> feature
> > > that will only available on 3.0, there is no backporting to do.
> >
> > But... I do not understand. Currently we are writing 2.18 in master
> > isn't it? 2.16 is currently being translated.
> >
> >
> > Right now, master is being used to write documentation both for 2.16 and
> > 2.18 feaures. 2.14 is the version being translated in transifex. Right?
> >
> >
> > Next release of
> > documentation master will be 2.18 (as that is the next LTR according
> to
> > current QGIS release plans).
> >
> > So both (undocumented) 2.16 and (new) 2.18 features can go in
> > documentation master now (by working away the 2.16 and 2.18 milestone
> > features)
> >
> >
> > So far so good. It's true. This is our current situation.
> >
> >
> > 3.0 has to wait or be documented in the issue tracker.
> >
> >
> > This is where, IMHO, it starts to fail. Having to wait for 2.18 to be
> > released (we have no estimate for that documentation release), or
> > writting it down in the bug tracker with no sure that the work will be
> > mergeble in the future may refrain people to documenting 3.0 new
> > features now (and probably won't do it later).
> >
> >
> > BUT.. but if it
> > is back-ported to 2.18 as you say... then it isn't a 3.0 feature
> anymore
> > is it? So can go in master now.
> >
> >
> > This would only be the case if we would have a 2.18 branch and 3.0
> > branch (which I was calling master).
> >
> >
> >
> > What I mend with a '3.0 fake branch' is that if people really really
> do
> > 

Re: [Qgis-developer] Moving Processing options?

[Paolo Cavallini]

Hi all,

Il 20/02/2017 10:20, Victor Olaya ha scritto:
> +1. I like the idea, and I hnk that, if it is possible to add options
> from plugins in the settings dialog, it should be mandatory for
> plugins to do so, for the sake of homogeneity, instead of creating
> their own.
> 
> 2017-02-20 10:16 GMT+01:00 Matthias Kuhn :
>> I once did that for vector layers (globe uses this) and Nathan reworked
>> it a bit for the styling dock IIRC, it probably wouldn't be hard to copy
>> this code.
>>
>> On 02/20/2017 09:57 AM, Paolo Cavallini wrote:
>>> Il 20/02/2017 09:55, Nyall Dawson ha scritto:
 I've thought this too.

 We'd need a way for plugins to embed panels inside the general options
 first though. This would also allow us to move the python console
 options here too. In general it might help reduce UI clutter though
 plugins creating menu items just for a config dialog (i.e. the Win95
 style menus "Plugins - > Super Team Pty Ltd -> Super Team Awesome
 Plugin -> Super Team Awesome Plugin v1.0 settings" )

has this been addressed somehow? Better note it down somewhere,
presumably in a ticket, not to forget about?
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: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] QGIS 3.0: Plans to support librttopo?

[Mark Johnson]

The spatialite function 'ST_Project' is based on the librttopo functionality
(formally LWGEOM)
- and is only available when compiled with '--enable-rttopo'

https://git.osgeo.org/gogs/rttopo/librttopo

So if a support for 'Meters as Map units' was desired, in the case of
degrees
- the use the librttopo functionality as a part of the 'QgsGeos' would be
the most effective way to deal with this

This would be a new dependency, but would also offer many other
functionalities (such as Topology).

Mark Johnson, Berlin Germany
___
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] 3.0 Documentation and branching

[Tom Chadwin]

A quick, sweeping, unhelpful but important opinion from me (non-dev,
non-doc-writer).

Please don't think that retrospective documentation, and lack of docs for
current release (not master, but current non-LTR release) is good, just
because that's how it is now. This is the *biggest* failing of the QGIS
project when stacked up against commercial alternatives. Can you imagine a
professional software package being released without full docs?

I know that we just don't have the resources to improve this to where it
should be, but perhaps this would be an argument to slow down the release
cycle.

To make it absolutely clear: that fact that current latest release of QGIS
doesn't have docs is a huge failure.





-
Buy Pie Spy: Adventures in British pastry 2010-11 on Amazon 
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/3-0-Documentation-and-branching-tp5306770p5310924.html
Sent from the QGIS - Developer mailing list archive at Nabble.com.
___
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] 3.0 Documentation and branching

[DelazJ]

Hi all,

Hummm Alexandre.. By replying to Richard points, you made me rewrite the
message I was about to send :'(

So in short: I'm ok with the double branches and had already suggested it
in january (
https://lists.osgeo.org/pipermail/qgis-psc/2017-January/005047.html) for
many reasons you already exposed.
If we do not begin to fix 3.0 issues (currently 180) in parallel to 2.x
last branch, we'll NEVER have 3.2 doc released in 2018. I'm pretty sure!
For the recall, since 2.14 release in july (august?), we have closed around
105 issues for 2.16 and 2.18 (remains 49 issues open i.e 1/3). I let you do
the calculation even though I know it's not linear.

Another advantage is that there are new writers knocking at the door and
the remaining issues for 2.x are imho not enough sexy and easy to begin
contributing. And these people are energy we should not let go.

Btw, Alexandre, thank you to remind me that I need to revert Victor's
commit (for compliance with 2.x) :)

Harrissou


2017-03-06 13:15 GMT+01:00 Alexandre Neto :

> Hello all,
>
> This will be my last arguments in this thread. After these arguments, if I
> fail to make myself clear, or you guys simply disagree with my point of
> view, let's just carry on with our lives. I don't want to waste people's
> time (at least not documenting time :-P)
>
> Richard Duivenvoorde  escreveu no dia segunda,
> 6/03/2017 às 07:33:
>
>> On 06-03-17 00:32, Alexandre Neto wrote:
>> > A dom, 5/03/2017, 21:56, Richard Duivenvoorde > > > escreveu:
>> >
>> > So do I understand correct that people want to write docs for 3.0
>> in a
>> > 'fake'-3.0 branch, and the plan is then when master becomes really
>> 3.0
>> > all these changes will be cherry picked from that branch?
>> > Because I think that will be hard to do given those branches
>> will
>> > divert from each other, and it is already pretty hard to have a good
>> > overview as of where to place pieces of info.
>> >
>> > Not sure if I followed your idea when you mention a "fake" 3.0 branch.
>> > My idea would be to have a 2.18 branch and a master branch (effectively
>> > aiming at 2.99 development).
>> > When a documenter work in a new feature description, he would do it
>> > directly on master and, if that feature was already available on qgis
>> > 2.18, backport that description to the 2.18 branch. If it's a feature
>> > that will only available on 3.0, there is no backporting to do.
>>
>> But... I do not understand. Currently we are writing 2.18 in master
>> isn't it? 2.16 is currently being translated.
>
>
> Right now, master is being used to write documentation both for 2.16 and
> 2.18 feaures. 2.14 is the version being translated in transifex. Right?
>
>
>> Next release of
>> documentation master will be 2.18 (as that is the next LTR according to
>> current QGIS release plans).
>>
> So both (undocumented) 2.16 and (new) 2.18 features can go in
>> documentation master now (by working away the 2.16 and 2.18 milestone
>> features)
>>
>
> So far so good. It's true. This is our current situation.
>
>
>> 3.0 has to wait or be documented in the issue tracker.
>
>
> This is where, IMHO, it starts to fail. Having to wait for 2.18 to be
> released (we have no estimate for that documentation release), or writting
> it down in the bug tracker with no sure that the work will be mergeble in
> the future may refrain people to documenting 3.0 new features now (and
> probably won't do it later).
>
>
>> BUT.. but if it
>> is back-ported to 2.18 as you say... then it isn't a 3.0 feature anymore
>> is it? So can go in master now.
>>
>
> This would only be the case if we would have a 2.18 branch and 3.0 branch
> (which I was calling master).
>
>
>>
>> What I mend with a '3.0 fake branch' is that if people really really do
>> want to write 3.0 documentation, we could do a 3.0 branch in which then
>> only new features available in 3.0 could come (while master hopefully
>> still grows and maybe splits pages with 2.18 features). When we have to
>> create the branch 2.18 then to start translating, and master will become
>> 3.0 that 'fake 3.0 branch' should be merged back in 3.0, OR 'fake 3.0'
>> becomes master and we have to merge all changes from old master in that
>> one... both a considerable amount of work I think.
>>
>
> My proposal would be to do this backporting continuasly, keeping the two
> branches in sync as much as possible (except for 3.X features ofc). That
> is, any 2.16 or 2.18 feature added to documentation, would be added also,
> at the same time, to the 3.X documentation.
>
>
>>
>> > But given that every new feature (which is commited with a 'FEATURE'
>> > tag) has it's issue in the documentation issue tracker [0], why not
>> add
>> > information there? You can write full RST there, you can attache
>> > images/screendumps etc etc.
>> >
>> > If people (be it dev's or doc writers who 

[Qgis-developer] Plugin [1163] Plugin Load Times approval notification.

[noreply]

Plugin Plugin Load Times approval by pcav.
The plugin version "[1163] Plugin Load Times 1.2.1" is now approved
Link: http://plugins.qgis.org/plugins/PluginLoadTimes/
___
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] 3.0 Documentation and branching

[Matthias Kuhn]

Hello Alexandre,

If I interpret your message correctly, you propose to

1. Match the branch names on QGIS-Documentation with the branch names
   of the QGIS repository

2. Only create branches for "documentation target" (read LTR) releases

3. Define one of the branches as "current translation target"

For now we would therefore have

 release-2_14 (translation target)
 release-2_18
 master (will become release-3.0 or release-3.2)

Main work will be on master but backporting should be done whenever
possible.
Branches can be end-of-lifed as soon as LTR-period ends and branched off
of master in parallel to the main QGIS repo.

The advantage of this is, that new features can immediately be
documented in rst (and not only md as in the issue tracker) as soon as
someone wants.

If we run into major merge troubles in the worst case, text can still be
copy-pasted. That's actually the same amount than it is copying text
from issues.

Did I forget something?

I think this sounds like a very good approach, I actually can't see any
downsides.

Bests
Matthias

On 03/06/2017 01:15 PM, Alexandre Neto wrote:
> Hello all,
> 
> This will be my last arguments in this thread. After these arguments, if
> I fail to make myself clear, or you guys simply disagree with my point
> of view, let's just carry on with our lives. I don't want to waste
> people's time (at least not documenting time :-P)
> 
> Richard Duivenvoorde >
> escreveu no dia segunda, 6/03/2017 às 07:33:
> 
> On 06-03-17 00:32, Alexandre Neto wrote:
> > A dom, 5/03/2017, 21:56, Richard Duivenvoorde  
> > >> escreveu:
> >
> > So do I understand correct that people want to write docs for
> 3.0 in a
> > 'fake'-3.0 branch, and the plan is then when master becomes
> really 3.0
> > all these changes will be cherry picked from that branch?
> > Because I think that will be hard to do given those
> branches will
> > divert from each other, and it is already pretty hard to have
> a good
> > overview as of where to place pieces of info.
> >
> > Not sure if I followed your idea when you mention a "fake" 3.0 branch.
> > My idea would be to have a 2.18 branch and a master branch
> (effectively
> > aiming at 2.99 development).
> > When a documenter work in a new feature description, he would do it
> > directly on master and, if that feature was already available on qgis
> > 2.18, backport that description to the 2.18 branch. If it's a feature
> > that will only available on 3.0, there is no backporting to do.
> 
> But... I do not understand. Currently we are writing 2.18 in master
> isn't it? 2.16 is currently being translated.
> 
> 
> Right now, master is being used to write documentation both for 2.16 and
> 2.18 feaures. 2.14 is the version being translated in transifex. Right?
>  
> 
> Next release of
> documentation master will be 2.18 (as that is the next LTR according to
> current QGIS release plans).
> 
> So both (undocumented) 2.16 and (new) 2.18 features can go in
> documentation master now (by working away the 2.16 and 2.18 milestone
> features)
> 
> 
> So far so good. It's true. This is our current situation.
>  
> 
> 3.0 has to wait or be documented in the issue tracker.
> 
> 
> This is where, IMHO, it starts to fail. Having to wait for 2.18 to be
> released (we have no estimate for that documentation release), or
> writting it down in the bug tracker with no sure that the work will be
> mergeble in the future may refrain people to documenting 3.0 new
> features now (and probably won't do it later).
>  
> 
> BUT.. but if it
> is back-ported to 2.18 as you say... then it isn't a 3.0 feature anymore
> is it? So can go in master now.
> 
> 
> This would only be the case if we would have a 2.18 branch and 3.0
> branch (which I was calling master).
>  
> 
> 
> What I mend with a '3.0 fake branch' is that if people really really do
> want to write 3.0 documentation, we could do a 3.0 branch in which then
> only new features available in 3.0 could come (while master hopefully
> still grows and maybe splits pages with 2.18 features). When we have to
> create the branch 2.18 then to start translating, and master will become
> 3.0 that 'fake 3.0 branch' should be merged back in 3.0, OR 'fake 3.0'
> becomes master and we have to merge all changes from old master in that
> one... both a considerable amount of work I think.
> 
> 
> My proposal would be to do this backporting continuasly, keeping the two
> branches in sync as much as possible (except for 3.X features ofc). That
> is, any 2.16 or 2.18 feature added to documentation, would be added
> also, at the same time, to the 3.X documentation.
>  
> 
> 
> > But given 

Re: [Qgis-developer] 3.0 Documentation and branching

[Alexandre Neto]

Hello all,

This will be my last arguments in this thread. After these arguments, if I
fail to make myself clear, or you guys simply disagree with my point of
view, let's just carry on with our lives. I don't want to waste people's
time (at least not documenting time :-P)

Richard Duivenvoorde  escreveu no dia segunda,
6/03/2017 às 07:33:

> On 06-03-17 00:32, Alexandre Neto wrote:
> > A dom, 5/03/2017, 21:56, Richard Duivenvoorde  > > escreveu:
> >
> > So do I understand correct that people want to write docs for 3.0 in
> a
> > 'fake'-3.0 branch, and the plan is then when master becomes really
> 3.0
> > all these changes will be cherry picked from that branch?
> > Because I think that will be hard to do given those branches will
> > divert from each other, and it is already pretty hard to have a good
> > overview as of where to place pieces of info.
> >
> > Not sure if I followed your idea when you mention a "fake" 3.0 branch.
> > My idea would be to have a 2.18 branch and a master branch (effectively
> > aiming at 2.99 development).
> > When a documenter work in a new feature description, he would do it
> > directly on master and, if that feature was already available on qgis
> > 2.18, backport that description to the 2.18 branch. If it's a feature
> > that will only available on 3.0, there is no backporting to do.
>
> But... I do not understand. Currently we are writing 2.18 in master
> isn't it? 2.16 is currently being translated.


Right now, master is being used to write documentation both for 2.16 and
2.18 feaures. 2.14 is the version being translated in transifex. Right?


> Next release of
> documentation master will be 2.18 (as that is the next LTR according to
> current QGIS release plans).
>
So both (undocumented) 2.16 and (new) 2.18 features can go in
> documentation master now (by working away the 2.16 and 2.18 milestone
> features)
>

So far so good. It's true. This is our current situation.


> 3.0 has to wait or be documented in the issue tracker.


This is where, IMHO, it starts to fail. Having to wait for 2.18 to be
released (we have no estimate for that documentation release), or writting
it down in the bug tracker with no sure that the work will be mergeble in
the future may refrain people to documenting 3.0 new features now (and
probably won't do it later).


> BUT.. but if it
> is back-ported to 2.18 as you say... then it isn't a 3.0 feature anymore
> is it? So can go in master now.
>

This would only be the case if we would have a 2.18 branch and 3.0 branch
(which I was calling master).


>
> What I mend with a '3.0 fake branch' is that if people really really do
> want to write 3.0 documentation, we could do a 3.0 branch in which then
> only new features available in 3.0 could come (while master hopefully
> still grows and maybe splits pages with 2.18 features). When we have to
> create the branch 2.18 then to start translating, and master will become
> 3.0 that 'fake 3.0 branch' should be merged back in 3.0, OR 'fake 3.0'
> becomes master and we have to merge all changes from old master in that
> one... both a considerable amount of work I think.
>

My proposal would be to do this backporting continuasly, keeping the two
branches in sync as much as possible (except for 3.X features ofc). That
is, any 2.16 or 2.18 feature added to documentation, would be added also,
at the same time, to the 3.X documentation.


>
> > But given that every new feature (which is commited with a 'FEATURE'
> > tag) has it's issue in the documentation issue tracker [0], why not
> add
> > information there? You can write full RST there, you can attache
> > images/screendumps etc etc.
> >
> > If people (be it dev's or doc writers who are eager to dive into a
> new
> > feature) write there stuff there, it can be copied from there into
> the
> > rst of the docs as soon as we open up for 3.0 features.
> >
> > This (or having a waiting PR) is precisely what I would like to avoid,
> > because if we wait for 2.18 documentation to be finished before starting
> > document 3.0, those hanging contributions can be difficult to integrate
> > later. Besides, it will be easy for other documenters to miss those
> > contributions and do some overlapping.
> >
> > IMHO, the master branch version of documentation should (almost) always
> > match the master branch version of QGIS.
>
> Agreed... and normally this is the case.. we should not hold back adding
> features for newer versions in between LTR's. But we are in a strange
> situation currently: 2 LTR's pretty soon next to each other and a lot of
> work going into a future LTR while next LTR is already being developed
> while not yet to be released.
>
> Or do I just miss your point?
>
> Who or what makes us so eager to document the 3.0 features? Going into
> the issue tracker I see devs are using that (more or less) to write down
> some lines or 

Re: [Qgis-developer] Processing params always n meters?

[Mark Johnson]

> Are you referring to symbology here? Ie adding a new "map length (metres)"
Yes, where the combo-box show
- millimeter
- pixels
- Map units

one could add
- Meters to Map units

Presently definded in QgsSymbolV2 and calulated in
QgsSymbolLayerV2Utils::convertToMapUnits
and
QgsSymbolLayerV2Utils::convertToPainterUnits

Mark
___
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] Plugin with custom QGIS-Qt Widget for master

[Denis Rouzaud]

There should be no need to manual editing of the file.

In the described example, one issue could be the 3.0 API change:
QgsColorButtonV2 doesn't exist anymore  in 3.0. So one needs to use the
proper library of custom widgets (Qt5) to be compatible.

If you compile the UI, it is import to add QGIS to the python path so it
can find the custom widgets while compiling.



Le lun. 6 mars 2017 à 10:31, Luigi Pirelli  a écrit :

> Hi Raymond
>
> in Qt (AFAIR) you can specify the include of the custom UI, so the
> overwrite will be avoided.
> 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 2nd Edition:
> *
> https://www.packtpub.com/big-data-and-business-intelligence/mastering-qgis-second-edition
>
> **
>
>
> On 6 March 2017 at 08:42, Raymond Nijssen  wrote:
> > Hi Matteo,
> >
> > I ran into this last week. The solution, or workaround, is here:
> >
> > https://lists.osgeo.org/pipermail/qgis-developer/2016-August/044138.html
> >
> > You need to manually change the output of QtDesigner.
> >
> > Good luck!
> > Raymond
> >
> >
> >
> > On 06-03-17 07:07, Denis Rouzaud wrote:
> >>
> >>
> >> Hi Matteo,
> >>
> >> Are you using a compiled UI file or the UI directly?
> >> Can you point to the source online?
> >>
> >> Denis
> >>
> >>
> >> Le dim. 5 mars 2017 à 22:35, matteo  >> > a écrit :
> >>
> >> sorry, the error related to the widget is:
> >>
> >>   File
> >> "/home/matteo/lavori/QGIS/build-qgis33/output/python/qgis/utils.py",
> >> line 647, in _import
> >> mod = _builtin_import(name, globals, locals, fromlist, level)
> >> ImportError: No module named 'qgsmaplayercombobox'
> >>
> >> Matteo
> >> ___
> >> Qgis-developer mailing list
> >> Qgis-developer@lists.osgeo.org  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
> >>
> >
> > --
> > Terglobo
> > Fahrenheitstraat 1
> > 5223 BJ 's-Hertogenbosch
> > 06 25 31 49 83
> >
> > ___
> > 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
___
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] Housekeeping in the (Qgs)Settings

[Alessandro Pasotti]

Hi,

the current keys naming for the settings is not very consistent, what do
you guys think about cleaning it a bit?

I was thinking at:

1. adding an 'app' section to QgsSettings::Section enum, to store
namespaced settings for the application
2. remove the '/' at the beginning of the keys (it's completely unuseful)
3. enforce namespacing with the use of Sections on all keys used in the
'/src/*' folders

This is a quick grep|sort|uniq of the setting keys:


allowGeometrylessTables
/BetterAttributeTable/geometry
/browser/favourites
/browser/hiddenPaths
cache/directory
cache/size
/colors/palettecolors
/colors/palettelabels
/colors/recent
/ColorWidgets/textWidgetFormat
/Composer/defaultFont
/Composer/defaultSnapGridOffsetX
/Composer/defaultSnapGridOffsetY
/Composer/defaultSnapGridResolution
/Composer/defaultSnapTolerancePixels
/Composer/geometry
composer/searchPathsForTemplates
/ComposerUI/state
CptCity/archiveName
CptCity/baseDir
crs
database
/dataitem/directoryHiddenColumns
/Db2/connections/selected
dboptions
dbworkspace
Digitizing
/digitizing/simplify_tolerance
/digitizing/simplify_tolerance_units
dpiMode
/Error/dialog/detail
estimatedMetadata
/eVis/browser-geometry
/eVis/db-geometry
fontFamily
/fontFamily
fontPointSize
/fontPointSize
geometryColumnsOnly
/gps/lastPort
/GradientEditor/plotAlpha
/GradientEditor/plotHue
/GradientEditor/plotLightness
/GradientEditor/plotSaturation
/GRASS/browser/import/crsTransform
/GRASS/browser/import/external
/GRASS/gidbase/custom
/GRASS/gidbase/customDir
/GRASS/lastDirectOutputDir
/GRASS/lastGisdbase
/GRASS/lastLocation
/GRASS/lastMapset
/GRASS/modules/config/custom
/GRASS/modules/config/customDir
/GRASS/modules/debug
/GRASS/newMapsetWizard/openMapset
/GRASS/region/color
/GRASS/region/on
/GRASS/region/width
/GRASS/showTopoLayers
/GRASS/windows/tools/geometry
groupBoxCustom
help/helpSearchPath
/HelpViewer/geometry
/HistogramWidget/showMean
/HistogramWidget/showStdev
host
iconSize
/IconSize
ignoreAxisOrientation
ignoreGetFeatureInfoURI
ignoreGetMapURI
invertAxisOrientation
lastColorMapDir
locale
locale/overrideFlag
locale/userLocale
/Map/highlight/buffer
/Map/highlight/color
/Map/highlight/colorAlpha
/Map/highlight/minWidth
/Map/identifyMode
/Map/logCanvasRefreshEvent
Map/scales
/Map/searchRadiusMM
/MSSQL/connections/selected
/ogr/connections/selectedtype
/osm/lastDir
password
path
/Plugin-GeoReferencer/lastcompression
/Plugin-GeoReferencer/lastPDFReportDir
/Plugin-GeoReferencer/lastresampling
/Plugin-GeoReferencer/lasttransformation
/Plugin-GeoReferencer/loadinqgis
/Plugin-GeoReferencer/targetsrs
/Plugin-GeoReferencer/TransformSettingsWindow/geometry
/Plugin-Georeferencer/user_specified_resolution
/Plugin-GeoReferencer/user_specified_resx
/Plugin-GeoReferencer/user_specified_resy
/Plugin-Georeferencer/word_file_checkbox
/Plugin-GeoReferencer/zeroastrans
/Plugin-GPS/devicelist
/Plugin-GPS/geometry
/Plugin-GPS/gpsbabelpath
/Plugin-GPS/gpxdirectory
/Plugin-GPS/importdirectory
/Plugin-GPS/lastdldevice
/Plugin-GPS/lastdlport
/Plugin-GPS/lastImportFilter
/Plugin-GPS/lastTab
/Plugin-GPS/lastuldevice
/Plugin-GPS/lastulport
Plugin-OfflineEditing/geometry
Plugin-OfflineEditing/offline_data_path
plugins/searchPathsForPlugins
port
/PostgreSQL/connections/selected
previewImage
/Projections/defaultBehavior
/Projections/layerDefaultCrs
/Projections/otfTransformEnabled
/Projections/projectDefaultCrs
/Projections/showDatumTransformDialog
proxy/proxyEnabled
proxy/proxyExcludedUrls
proxy/proxyHost
proxy/proxyPassword
proxy/proxyPort
proxy/proxyType
proxy/proxyUser
pythonConsole/fontfamilytextEditor
pythonConsole/fontsizeEditor
/qgis/addDb2DC
/qgis/addMSSQLDC
/qgis/addPostgisDC
qgis/askToSaveProjectChanges
/qgis/attributeTableBehavior
/qgis/attributeTableLastView
/qgis/attributeTableRowCache
/qgis/attributeTableView
/qgis/capitalizeLayerName
/qgis/checkVersion
/Qgis/connections-wms/selected
/qgis/copyFeatureFormat
/qgis/copyGeometryAsWKT
/qgis/default_canvas_color_blue
/qgis/default_canvas_color_green
/qgis/default_canvas_color_red
/qgis/default_measure_color_blue
/qgis/default_measure_color_green
/qgis/default_measure_color_red
/qgis/default_selection_color_alpha
/qgis/default_selection_color_blue
/qgis/default_selection_color_green
/qgis/default_selection_color_red
/qgis/digitizing/default_snap_enabled
/qgis/digitizing/default_snap_mode
/qgis/digitizing/default_snapping_tolerance
/qgis/digitizing/default_snapping_tolerance_unit
/qgis/digitizing/disable_enter_attribute_values_dialog
/qgis/digitizing/fill_color_alpha
/qgis/digitizing/fill_color_blue
/qgis/digitizing/fill_color_green
/qgis/digitizing/fill_color_red
/qgis/digitizing/line_color_alpha
/qgis/digitizing/line_color_alpha_scale
/qgis/digitizing/line_color_blue
/qgis/digitizing/line_color_green
/qgis/digitizing/line_color_red
/qgis/digitizing/line_ghost
/qgis/digitizing/line_width
/qgis/digitizing/marker_only_for_selected
/qgis/digitizing/marker_size
/qgis/digitizing/marker_style
/qgis/digitizing/reuseLastValues

Re: [Qgis-developer] QEP: intregrating Lessons plugin into QGIS

[Alexander Bruy]

If it is included as core plugin, users will be able to run lessons
(for example,
shipped with QGIS or with 3rd party plugin) immediately without need to install
additional plugins.

2017-03-06 11:48 GMT+02:00 Nathan Woodrow :
> Hmm cool idea. Is there benefit to including it as core vs outside plugin?
>
>
> On Mon, 6 Mar 2017 7:46 pm Alexander Bruy  wrote:
>>
>> Sorry for raising this again.
>>
>> I've added plugin package to the QEP (will work with QGIS 2.14.x/2.18.x).
>> Two sample (and very basic) lessons already included in the package, so
>> you can test it and get the idea.
>>
>> Will be glad to hear any comments about this QEP and plugin itself.
>>
>> Thanks
>>
>> 2017-02-27 13:22 GMT+02:00 Alexander Bruy :
>> > Hi devs,
>> >
>> > Boundless is willing to contribute Lessons plugin [0] to the QGIS
>> > project. I have
>> > written a QEP for this [0] and will be happy to hear your feedback.
>> >
>> > We (Boundless) will continue with development of the Lessons plugin
>> > regardless of the decision on this QEP. But we believe that it will be
>> > great and useful addition to QGIS core.
>> >
>> > [0] https://github.com/boundlessgeo/qgis-lessons-plugin
>> > [1] https://github.com/qgis/QGIS-Enhancement-Proposals/issues/92
>>
>>
>>
>>
>> --
>> Alexander Bruy
>> ___
>> 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



-- 
Alexander Bruy
___
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] QEP: intregrating Lessons plugin into QGIS

[Nathan Woodrow]

Hmm cool idea. Is there benefit to including it as core vs outside plugin?

On Mon, 6 Mar 2017 7:46 pm Alexander Bruy  wrote:

> Sorry for raising this again.
>
> I've added plugin package to the QEP (will work with QGIS 2.14.x/2.18.x).
> Two sample (and very basic) lessons already included in the package, so
> you can test it and get the idea.
>
> Will be glad to hear any comments about this QEP and plugin itself.
>
> Thanks
>
> 2017-02-27 13:22 GMT+02:00 Alexander Bruy :
> > Hi devs,
> >
> > Boundless is willing to contribute Lessons plugin [0] to the QGIS
> > project. I have
> > written a QEP for this [0] and will be happy to hear your feedback.
> >
> > We (Boundless) will continue with development of the Lessons plugin
> > regardless of the decision on this QEP. But we believe that it will be
> > great and useful addition to QGIS core.
> >
> > [0] https://github.com/boundlessgeo/qgis-lessons-plugin
> > [1] https://github.com/qgis/QGIS-Enhancement-Proposals/issues/92
>
>
>
>
> --
> Alexander Bruy
> ___
> 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] QEP: intregrating Lessons plugin into QGIS

[Alexander Bruy]

Sorry for raising this again.

I've added plugin package to the QEP (will work with QGIS 2.14.x/2.18.x).
Two sample (and very basic) lessons already included in the package, so
you can test it and get the idea.

Will be glad to hear any comments about this QEP and plugin itself.

Thanks

2017-02-27 13:22 GMT+02:00 Alexander Bruy :
> Hi devs,
>
> Boundless is willing to contribute Lessons plugin [0] to the QGIS
> project. I have
> written a QEP for this [0] and will be happy to hear your feedback.
>
> We (Boundless) will continue with development of the Lessons plugin
> regardless of the decision on this QEP. But we believe that it will be
> great and useful addition to QGIS core.
>
> [0] https://github.com/boundlessgeo/qgis-lessons-plugin
> [1] https://github.com/qgis/QGIS-Enhancement-Proposals/issues/92




-- 
Alexander Bruy
___
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] Plugin with custom QGIS-Qt Widget for master

[Luigi Pirelli]

Hi Raymond

in Qt (AFAIR) you can specify the include of the custom UI, so the
overwrite will be avoided.
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 2nd Edition:
* 
https://www.packtpub.com/big-data-and-business-intelligence/mastering-qgis-second-edition
**


On 6 March 2017 at 08:42, Raymond Nijssen  wrote:
> Hi Matteo,
>
> I ran into this last week. The solution, or workaround, is here:
>
> https://lists.osgeo.org/pipermail/qgis-developer/2016-August/044138.html
>
> You need to manually change the output of QtDesigner.
>
> Good luck!
> Raymond
>
>
>
> On 06-03-17 07:07, Denis Rouzaud wrote:
>>
>>
>> Hi Matteo,
>>
>> Are you using a compiled UI file or the UI directly?
>> Can you point to the source online?
>>
>> Denis
>>
>>
>> Le dim. 5 mars 2017 à 22:35, matteo > > a écrit :
>>
>> sorry, the error related to the widget is:
>>
>>   File
>> "/home/matteo/lavori/QGIS/build-qgis33/output/python/qgis/utils.py",
>> line 647, in _import
>> mod = _builtin_import(name, globals, locals, fromlist, level)
>> ImportError: No module named 'qgsmaplayercombobox'
>>
>> 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
>>
>
> --
> Terglobo
> Fahrenheitstraat 1
> 5223 BJ 's-Hertogenbosch
> 06 25 31 49 83
>
> ___
> 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

[Qgis-developer] [GSoC 2017] Call for mentors

[Alexander Bruy]

Hi devs,

as you may know, OSGeo has been accepted as mentoring organization this year.
As QGIS is an OSGeo project we are also will take part in GSoC this year.

QGIS project already has three students (random order):
 - Eurico Nicacio with the idea "Integrating PySAL tools into Processing" [0]
 - Akbar Gumbira with the idea "Resource sharing plugin improvements" [1]
 - Ruoyun Jing with the idea "Improve vector geoprocessing tools" [2]

If you want to be a mentor this year, please add yourself to the mentors
list at [3]. Also note that according to the program rules each student should
have two mentors otherwise application won't be accepted.

Program timeline can be found at
https://developers.google.com/open-source/gsoc/timeline

[0] https://lists.osgeo.org/pipermail/qgis-developer/2017-February/047273.html
[1] https://lists.osgeo.org/pipermail/qgis-developer/2017-March/047309.html
[2] https://lists.osgeo.org/pipermail/qgis-developer/2017-February/047269.html
[3] 
https://wiki.osgeo.org/wiki/Google_Summer_of_Code_2017_Administrative#Mentors

-- 
Alexander Bruy
___
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