Re: [QGIS-Developer] Export PDFs from the processing modeler

2018-09-06 Thread Nyall Dawson
On Thu, 6 Sep 2018 at 14:16, Olivier Dalang  wrote:
>
> Dear List,
>
> (I took the liberty to CC in some of you that I thought may be interested by 
> this)

Count me in too -- I'm very interested here, given my history with
both Print Layout and Processing work!

> I'm dreaming of using the QGIS graphical modeler to output PDFs using print 
> composers. This would allow to build very interesting report generators using 
> our favorite tool. As far as I understand, currently, it is not possible.
>
> I'd be interested in working to implement it, to start with as a plugin 
> (prototype), and once this works see if we can integrate into core.
>
> What I thought of so far is to be able to specify as inputs :
> - a QGIS project [file] (using the current project if empty - esp. useful in 
> conjunction with the great new embedded models feature)
> - a composer name [string] (use the first one if empty)

I've got (Python) code which allows Print Layout parameter choices
(exposed as a combo box showing layouts within the current project),
and a layout "map item" parameter (links to the print layout
parameter, and shows a nice combo box of map items in the selected
layout). I can clean this up and share, but honestly my preference
would be to get this in to master as c++ code.

I think ideally the "print layout" parameter would expose both layouts
in the current project + a "..." file selector allowing choice of a
Print Layout template file (.qpt) (this should be relatively
straightforward -- basically a new temporary layout would be created
using the selected qpt). Possibly we could/should have an option in
that drop down to allow selection of a layout from a different project
file too, but this would add considerable complexity, and I'm unsure
if there's a concrete use case for this which couldn't be handled by
qpt template files alone.

> - N layers [layer] (I don't think we can support variable inputs count, so 
> could be 5)
> - N layer ids [string] (id of the layer in the project to be replaced by 
> corresponding input)

There's already multi layer parameters available for algorithms (which
also support layer order), so these could be reused here.

> Do you have some ideas about implementation ?

I'd see a number of ways we could expose print layouts/atlas to
Processing. Some potential algorithms could be:

Exporting algorithms
---
- Export layout. Just does a direct export of the selected layout to a
specified file. Nice and easy! [1]
- Export atlas. As above, but for a pre-existing atlas and selected
folder/file destination.
- Something like "export layout as atlas", where users select and
existing layout/qpt, map item, and "coverage layer", and the algorithm
iterates over the features in that layer just like an atlas, but using
a map layer generated elsewhere in the model as the coverage layer.

Utility algorithms
--
- Create layer from layout map item extent. Creates a new polygon
layer with a polygon feature of the are currently visible within a
selected layout map item. Handy for quickly creating a polygon layer
with the exact coverage of a map item for styling or atlas creation
purposes. (I've implemented this one already as a PyQGIS alg)
- Create atlas feature template: After selecting a layout map item and
specifying a desired "scale" and "origin point", the algorithm creates
a new polygon layer with a single feature of the required size which
makes the map item match the given scale [2]. The use case here is to
create the feature, then "copy and move" it multiple times over the
area of interest for an atlas.
- Some equivalent of the ESRI "Create strip map index"  tool/QGIS
PolyStrip plugin. Select a map item, desired scale, and line feature
layer and the algorithm creates rotated template features along the
lines to allow an atlas following the line. Options for overlap
margins, max map rotation, etc.

Layout creation algorithms
---

We could also have algorithms for assisting with editing/creating
layouts themselves, e.g. algorithms which created grids of guides,
grided layouts, etc. I'd LOVE LOVE LOVE a layout "spell check" tool!

Anyway, count me in here. I'm interested in helping in whatever way
desired - I can either mentor someone else to code this, or would be
interested in doing it directly if there's a sponsor available.
Alternatively we could write up all the desired specs and run a crowd
funding campaign to raise funds!

Nyall

[1] Would work super-well with a potential "QGIS variable" parameter,
which displays as the QGIS variable editor and which would allow
tweaking of expression variables to inflence the map render
[2] I'd also like to see a proper parameter widget for "scale"
parameters, which uses the nice QGIS scale widget instead of just
direct number entry.
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman

[QGIS-Developer] Plugin [598] Swap Vector Direction approval notification.

2018-09-06 Thread noreply

Plugin Swap Vector Direction approval by pcav.
The plugin version "[598] Swap Vector Direction 0.9" is now approved
Link: http://plugins.qgis.org/plugins/SwapVectorDirection/
___
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] Handle Bad Layers - DISABLE instead of DELETE

2018-09-06 Thread Worth Lutz

Hi All,

I have created QGIS Feature request #19790, "Handle Bad Layers - DISABLE 
instead of DELETE" about this problem.  Change it to a BUG if it should 
be classified that way.


I've summarized my ideas there. Please add your suggestions so this can 
be solved in the best way possible.


Thanks,

*Worth Lutz*


On 9/6/2018 10:18 AM, Matthias Kuhn wrote:

On 09/05/2018 11:49 PM, Nyall Dawson wrote:

On Thu, 6 Sep 2018 at 05:42, Worth Lutz  wrote:

Hi Devs,

I have a question about the "Handle Bad Layers" dialog. My scenario is working offline 
and loading a project with WMS layers defined. As the WMS is unreachable, the layers are marked as 
"bad". Since the layers are not fixable while offline, they get deleted from the project.

I would like to continue to edit the layers locally stored on my laptop and not 
lose the definitions of the WMS layers when saving the project.

I would like to see the "bad" layers marked as "disabled because bad" and not 
deleted from the project. This would keep the stored information about the layer in the project. 
When the project is next opened while connected to the internet these layers would be available 
without having to enter them again.

Is there currently a way to do this?  Or should I add an enhancement request 
issue for this idea?

I think this is a widely desired feature, and something I'd very much
like to see available "out of the box".

For 2.x there is a plugin "changeDataSource" which allows this
behavior. I don't think that plugin is available for 3.x yet.

Nyall

Just to second this statement: any contribution that works towards this
goal (especially for QGIS core) gets my full support! (for a long time
already ;)
https://gis.stackexchange.com/questions/200138/how-to-ignore-handle-bad-layers-in-qgis).

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


___
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] Feature freeze / exemptions

2018-09-06 Thread Régis Haubourg
Well, my point is that in exceptional cases, that could be of course
discussed, but not at every release.
Régis

Le jeu. 6 sept. 2018 à 18:38, Paolo Cavallini  a
écrit :

> Hi Regis,
> so in short your proposal is no exemption?
> All the best.
>
> Il 6 settembre 2018 18:21:29 CEST, "Régis Haubourg" <
> regis.haubo...@gmail.com> ha scritto:
>>
>> Hi all,
>> maybe from a voter point of view, this is uncomfortable to vote for last
>> minute exemptions, as this does not have such sense from a democratic
>> perspective.
>> Voting is essential on strategic issues, but voting on "do you want this
>> now, or within 4 months" may not appear so important - except if you funded
>> the feature yourself.
>>
>> As a user, I'd really want the two mentioned features for the next LTR,
>> I've wanted them for so long. But in the other hand, I think we should
>> really not end into a systematic feature freeze exemption process.
>>
>> I know QGIS is a do-ocraty, and we owe so much to our top contributors
>> that we can't refuse them anything, hum... professionally speaking I mean:-)
>>
>> However having work still going on while in feature freeze does not help
>> in dedicating fully to bugfixing and testing.
>>
>> Last point, some teams have been rescheduling hard and sometimes
>> canceling deserved vacations to respect feature freeze deadline. Just to be
>> clear, this doesn't concern Oslandia this time, but this happened in the
>> past.
>> Seen from this perspective, I'd like we don't repeat this at every
>> release. Customer usually can wait for 4 months more.
>>
>> Regards,
>> Régis
>>
>>
>> Le mer. 5 sept. 2018 à 09:13, Matthias Kuhn  a
>> écrit :
>>
>>> Thanks Paolo
>>>
>>> On 09/05/2018 09:02 AM, Paolo Cavallini wrote:
>>> > Hi Matthias
>>> >
>>> >
>>> > Il 09/05/2018 08:35 AM, Matthias Kuhn ha scritto:
>>> >> I think the approach to let voting members decide as we did last time
>>> >> (https://www.loomio.org/d/38Aiya0q/3-0-soft-freeze-exemptions) works
>>> fine.
>>> >>
>>> >>  * This committee includes several technical members
>>> >>  * Everyone is free to vote or not, based on self-evaluation of
>>> knowledge
>>> > it makes sense to me - perhaps this should be particularly stressed in
>>> > the voting question, otherwise people will feel obliged to vote (which
>>> > often means +1) even when they cannot grasp the implication.
>>>
>>> Yes, we can state that explicitly.
>>>
>>> In the past, e.g. here
>>> https://www.loomio.org/p/BPc3Wj6l/duplicate-feature-redigitized we had
>>> 33% participation. Not sure what the reason for abstaining was, one
>>> assumption would be that many did not feel comfortable enough to make a
>>> decision. Or pure lazyness or disinterest ;P
>>>
>>> Regards
>>>
>>>
>>> ___
>>> 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
>>
>>
> --
> Sorry for being short
>
___
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] Feature freeze / exemptions

2018-09-06 Thread Paolo Cavallini
Hi Regis,
so in short your proposal is no exemption?
All the best.

Il 6 settembre 2018 18:21:29 CEST, "Régis Haubourg"  
ha scritto:
>Hi all,
>maybe from a voter point of view, this is uncomfortable to vote for
>last
>minute exemptions, as this does not have such sense from a democratic
>perspective.
>Voting is essential on strategic issues, but voting on "do you want
>this
>now, or within 4 months" may not appear so important - except if you
>funded
>the feature yourself.
>
>As a user, I'd really want the two mentioned features for the next LTR,
>I've wanted them for so long. But in the other hand, I think we should
>really not end into a systematic feature freeze exemption process.
>
>I know QGIS is a do-ocraty, and we owe so much to our top contributors
>that
>we can't refuse them anything, hum... professionally speaking I mean:-)
>
>However having work still going on while in feature freeze does not
>help in
>dedicating fully to bugfixing and testing.
>
>Last point, some teams have been rescheduling hard and sometimes
>canceling
>deserved vacations to respect feature freeze deadline. Just to be
>clear,
>this doesn't concern Oslandia this time, but this happened in the past.
>Seen from this perspective, I'd like we don't repeat this at every
>release.
>Customer usually can wait for 4 months more.
>
>Regards,
>Régis
>
>
>Le mer. 5 sept. 2018 à 09:13, Matthias Kuhn  a
>écrit :
>
>> Thanks Paolo
>>
>> On 09/05/2018 09:02 AM, Paolo Cavallini wrote:
>> > Hi Matthias
>> >
>> >
>> > Il 09/05/2018 08:35 AM, Matthias Kuhn ha scritto:
>> >> I think the approach to let voting members decide as we did last
>time
>> >> (https://www.loomio.org/d/38Aiya0q/3-0-soft-freeze-exemptions)
>works
>> fine.
>> >>
>> >>  * This committee includes several technical members
>> >>  * Everyone is free to vote or not, based on self-evaluation of
>> knowledge
>> > it makes sense to me - perhaps this should be particularly stressed
>in
>> > the voting question, otherwise people will feel obliged to vote
>(which
>> > often means +1) even when they cannot grasp the implication.
>>
>> Yes, we can state that explicitly.
>>
>> In the past, e.g. here
>> https://www.loomio.org/p/BPc3Wj6l/duplicate-feature-redigitized we
>had
>> 33% participation. Not sure what the reason for abstaining was, one
>> assumption would be that many did not feel comfortable enough to make
>a
>> decision. Or pure lazyness or disinterest ;P
>>
>> Regards
>>
>>
>> ___
>> 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

-- 
Sorry for being short___
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] Feature freeze / exemptions

2018-09-06 Thread Régis Haubourg
Hi all,
maybe from a voter point of view, this is uncomfortable to vote for last
minute exemptions, as this does not have such sense from a democratic
perspective.
Voting is essential on strategic issues, but voting on "do you want this
now, or within 4 months" may not appear so important - except if you funded
the feature yourself.

As a user, I'd really want the two mentioned features for the next LTR,
I've wanted them for so long. But in the other hand, I think we should
really not end into a systematic feature freeze exemption process.

I know QGIS is a do-ocraty, and we owe so much to our top contributors that
we can't refuse them anything, hum... professionally speaking I mean:-)

However having work still going on while in feature freeze does not help in
dedicating fully to bugfixing and testing.

Last point, some teams have been rescheduling hard and sometimes canceling
deserved vacations to respect feature freeze deadline. Just to be clear,
this doesn't concern Oslandia this time, but this happened in the past.
Seen from this perspective, I'd like we don't repeat this at every release.
Customer usually can wait for 4 months more.

Regards,
Régis


Le mer. 5 sept. 2018 à 09:13, Matthias Kuhn  a écrit :

> Thanks Paolo
>
> On 09/05/2018 09:02 AM, Paolo Cavallini wrote:
> > Hi Matthias
> >
> >
> > Il 09/05/2018 08:35 AM, Matthias Kuhn ha scritto:
> >> I think the approach to let voting members decide as we did last time
> >> (https://www.loomio.org/d/38Aiya0q/3-0-soft-freeze-exemptions) works
> fine.
> >>
> >>  * This committee includes several technical members
> >>  * Everyone is free to vote or not, based on self-evaluation of
> knowledge
> > it makes sense to me - perhaps this should be particularly stressed in
> > the voting question, otherwise people will feel obliged to vote (which
> > often means +1) even when they cannot grasp the implication.
>
> Yes, we can state that explicitly.
>
> In the past, e.g. here
> https://www.loomio.org/p/BPc3Wj6l/duplicate-feature-redigitized we had
> 33% participation. Not sure what the reason for abstaining was, one
> assumption would be that many did not feel comfortable enough to make a
> decision. Or pure lazyness or disinterest ;P
>
> Regards
>
>
> ___
> 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] Anyone using QGIS with high resolution screen?

2018-09-06 Thread Alessandro Pasotti
On Thu, Sep 6, 2018 at 5:28 PM Denis Rouzaud 
wrote:

> Thank you for replies.
> Alessandro, on Mac, how did you installed/compiled QGIS? Homebrew,
> MacPorts or KyngChaos ?
>
>
>
Hi Denis,

Sorry if I wasn't clear: I wiped out the hard disk completely, put a QGIS
sticker on the Apple logo and I'm happily running Ubuntu on my MacBook Pro
15'' :)

-- 
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] Anyone using QGIS with high resolution screen?

2018-09-06 Thread Denis Rouzaud
Thank you for replies.
Alessandro, on Mac, how did you installed/compiled QGIS? Homebrew, MacPorts
or KyngChaos ?

Cheers,
Denis

Le jeu. 6 sept. 2018 à 03:07, Alessandro Pasotti  a
écrit :

>
> On Wed, Sep 5, 2018 at 11:52 PM Nyall Dawson 
> wrote:
>
>> On Thu, 6 Sep 2018 at 03:39, Denis Rouzaud 
>> wrote:
>> >
>> > Hi list,
>> >
>> > There is a persistent issue of slowness of QGIS on Mac.
>> > https://issues.qgis.org/issues/19546
>> >
>> > The last comments led to think that this comes from high resolution.
>> Starting from 2560x1440, it starts to be less and less usable. And
>> completly unsuable at 5120x2880.
>>
>> 3840x2160 here, on Linux/Win, and perfectly usable. That's the highest
>> res I've got available to test with.
>>
>
>
> Me too: I've been using a 4k 3840x2160 screen on Linux for 3 years now
> without any slowness problem.
> MacBook Pro 15'' retina with Ubuntu Xenial also works very well.
>
>
> --
> 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

-- 

Denis Rouzaud
de...@opengis.ch  
+41 76 370 21 22
___
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] Handle Bad Layers

2018-09-06 Thread Matthias Kuhn
On 09/05/2018 11:49 PM, Nyall Dawson wrote:
> On Thu, 6 Sep 2018 at 05:42, Worth Lutz  wrote:
>> Hi Devs,
>>
>> I have a question about the "Handle Bad Layers" dialog. My scenario is 
>> working offline and loading a project with WMS layers defined. As the WMS is 
>> unreachable, the layers are marked as "bad". Since the layers are not 
>> fixable while offline, they get deleted from the project.
>>
>> I would like to continue to edit the layers locally stored on my laptop and 
>> not lose the definitions of the WMS layers when saving the project.
>>
>> I would like to see the "bad" layers marked as "disabled because bad" and 
>> not deleted from the project. This would keep the stored information about 
>> the layer in the project. When the project is next opened while connected to 
>> the internet these layers would be available without having to enter them 
>> again.
>>
>> Is there currently a way to do this?  Or should I add an enhancement request 
>> issue for this idea?
> I think this is a widely desired feature, and something I'd very much
> like to see available "out of the box".
>
> For 2.x there is a plugin "changeDataSource" which allows this
> behavior. I don't think that plugin is available for 3.x yet.
>
> Nyall

Just to second this statement: any contribution that works towards this
goal (especially for QGIS core) gets my full support! (for a long time
already ;)
https://gis.stackexchange.com/questions/200138/how-to-ignore-handle-bad-layers-in-qgis).

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] Handle Bad Layers

2018-09-06 Thread Enrico Ferreguti
Bad layer handling is not currently supported under QGIS3. for now.

Best Regards.
Enrico

Il mer 5 set 2018, 23:49 Nyall Dawson  ha scritto:

> On Thu, 6 Sep 2018 at 05:42, Worth Lutz  wrote:
> >
> > Hi Devs,
> >
> > I have a question about the "Handle Bad Layers" dialog. My scenario is
> working offline and loading a project with WMS layers defined. As the WMS
> is unreachable, the layers are marked as "bad". Since the layers are not
> fixable while offline, they get deleted from the project.
> >
> > I would like to continue to edit the layers locally stored on my laptop
> and not lose the definitions of the WMS layers when saving the project.
> >
> > I would like to see the "bad" layers marked as "disabled because bad"
> and not deleted from the project. This would keep the stored information
> about the layer in the project. When the project is next opened while
> connected to the internet these layers would be available without having to
> enter them again.
> >
> > Is there currently a way to do this?  Or should I add an enhancement
> request issue for this idea?
>
> I think this is a widely desired feature, and something I'd very much
> like to see available "out of the box".
>
> For 2.x there is a plugin "changeDataSource" which allows this
> behavior. I don't think that plugin is available for 3.x yet.
>
> Nyall
>
> >
> > --
> > Worth Lutz
> >
> >
> > ___
> > 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] RES: Handle Bad Layers

2018-09-06 Thread Jorge Almerio
Hi devs,

About the changeDataSource plugin, there is a testing working version (it can 
be downloaded and installed from zip) for Qgis 3.x on 
https://github.com/enricofer/changeDataSource/tree/qgis3-migration-test still 
not on oficial repository.

Regards,

Jorge Almerio

-Mensagem original-
De: QGIS-Developer [mailto:qgis-developer-boun...@lists.osgeo.org] Em nome de 
Nyall Dawson
Enviada em: quarta-feira, 5 de setembro de 2018 18:50
Para: w...@mindspring.com
Cc: qgis-developer
Assunto: Re: [QGIS-Developer] Handle Bad Layers

On Thu, 6 Sep 2018 at 05:42, Worth Lutz  wrote:
>
> Hi Devs,
>
> I have a question about the "Handle Bad Layers" dialog. My scenario is 
> working offline and loading a project with WMS layers defined. As the WMS is 
> unreachable, the layers are marked as "bad". Since the layers are not fixable 
> while offline, they get deleted from the project.
>
> I would like to continue to edit the layers locally stored on my laptop and 
> not lose the definitions of the WMS layers when saving the project.
>
> I would like to see the "bad" layers marked as "disabled because bad" and not 
> deleted from the project. This would keep the stored information about the 
> layer in the project. When the project is next opened while connected to the 
> internet these layers would be available without having to enter them again.
>
> Is there currently a way to do this?  Or should I add an enhancement request 
> issue for this idea?

I think this is a widely desired feature, and something I'd very much
like to see available "out of the box".

For 2.x there is a plugin "changeDataSource" which allows this
behavior. I don't think that plugin is available for 3.x yet.

Nyall

>
> --
> Worth Lutz
>
>
> ___
> 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] Plugin [1535] Cartographic Line Generalization approval notification.

2018-09-06 Thread noreply

Plugin Cartographic Line Generalization approval by pcav.
The plugin version "[1535] Cartographic Line Generalization 0.4" is now approved
Link: http://plugins.qgis.org/plugins/cartolinegen/
___
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 [1535] Cartographic Line Generalization approval notification.

2018-09-06 Thread noreply

Plugin Cartographic Line Generalization approval by pcav.
The plugin version "[1535] Cartographic Line Generalization 3.0" is now approved
Link: http://plugins.qgis.org/plugins/cartolinegen/
___
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] Anyone using QGIS with high resolution screen?

2018-09-06 Thread Alessandro Pasotti
On Wed, Sep 5, 2018 at 11:52 PM Nyall Dawson  wrote:

> On Thu, 6 Sep 2018 at 03:39, Denis Rouzaud 
> wrote:
> >
> > Hi list,
> >
> > There is a persistent issue of slowness of QGIS on Mac.
> > https://issues.qgis.org/issues/19546
> >
> > The last comments led to think that this comes from high resolution.
> Starting from 2560x1440, it starts to be less and less usable. And
> completly unsuable at 5120x2880.
>
> 3840x2160 here, on Linux/Win, and perfectly usable. That's the highest
> res I've got available to test with.
>


Me too: I've been using a 4k 3840x2160 screen on Linux for 3 years now
without any slowness problem.
MacBook Pro 15'' retina with Ubuntu Xenial also works very well.


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