Re: [QGIS-Developer] Export PDFs from the processing modeler
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:
[QGIS-Developer] Plugin [598] Swap Vector Direction approval notification.
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
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
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
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
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?
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?
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
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
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
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.
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.
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?
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
