[Qgis-developer] Geometry type conversion of 2.6
Hi, I just found size of .shp file increases more than twice (2900 bytes - 6500 bytes when it has 100 points) when I saved a point layer as a shapefile. I didn't edit the layer anything, but the geometry type was converted from Point to Multipoint. Maybe this must not expected behavior. Is this a big bug of 2.6? See also #11542 and #11597. Regards, Minoru ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QGIS 3.0?
Hi Nyall - geometry rework, where an api break would result in a better foundation moving forward For the geometry rework, it is not a problem to keep compatibility with 2. It is even an advantage, as there is more time to adapt the numerous pieces of code that work with QgsGeometry. I think it is to early to go for version 3, 2 has been released a bit more than a year ago. Regards, Marco On 08.11.2014 07:11, Nyall Dawson wrote: Hi all, I'm just wondering - given a few large changes coming up, including: - qt5 support, possibly breaking plugins - potential composer redesign, breaking api - geometry rework, where an api break would result in a better foundation moving forward ... is it worth exploring the idea of making the next release QGIS 3.0 and breaking API? I know the original plan was for 3.0 to coincide with python 3 support, but that doesn't appear to be anywhere on the horizon yet. Nyall ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Dr. Marco Hugentobler Sourcepole - Linux Open Source Solutions Weberstrasse 5, CH-8004 Zürich, Switzerland marco.hugentob...@sourcepole.ch http://www.sourcepole.ch Technical Advisor QGIS Project Steering Committee ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Installin IntraMaps Roam
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all. I built and installed https://github.com/DMS-Aus/Roam on my Debian box, but I see a blank screen when I click on Projects: any suggestion on how to debug it? All the best, and thanks. - -- Paolo Cavallini - www.faunalia.eu QGIS PostGIS courses: http://www.faunalia.eu/training.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlRh2iMACgkQ/NedwLUzIr4r+ACfTz8wQD415Kq+7OKlnUePBh8R v4kAniCfxRIg4tq/JiCHmuoD0XMmSgxn =QiME -END PGP SIGNATURE- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Composer... current status and the way forward?
Hi, It would be very awesome to have live-linked templates! I would very much need them. I have a lot of operational projects and it is my fear that some day some details would change and I need to go into all of the projects and adopt things like logo, fonts, headers, etc. It would either require a script to process the .qgs files or a lot of manual work. So +1 for having live templates. Nyall, maybe you can plan the redesign in a way to make it possible? I would also participate in financing the development of these live templates. Andreas On 07.11.2014 20:10, Olivier Dalang wrote: Hi, I don't get the point in keeping the old classes if we upgrade the composers to layouts at opening ? Doesn't migration happen at XML level ? Maybe while thinking about reworking the composer, we could think about a new feature : real templates (aka masters in Indesign). All elements added to a master appear on all the page that apply it. This is very handy: you can always edit the master (move some elements, change the fonts/colors, etc.), and the changes are reflected on all the layouts. The challenging part from an UI point of view is the required ability to override the content of templates elements (for instance the extent of a map, the text of a textbox, etc.) I thought of making a plugin for this, but got discouraged because of the problem you exposed... So it would be a good test case to see if the future API for the layouts allows to implement this easily ;) Thanks ! Olivier 2014-11-07 16:26 GMT+01:00 Andreas Neumann a.neum...@carto.net mailto:a.neum...@carto.net: Hi Nyall, I also think that option 2 would work best. Option one would be very confusing (I remember the days when we had two labeling versions, 2 symbology versions, etc. - awful!). Thanks, Andreas On 07.11.2014 16:16, G. Allegri wrote: Hi Nyall, as I already told you privately, I agree with the second approach: remove the current Composer and guarantee transparent auto-upgrade of existing layouts in projects. The improvements to the composer worth the effort, and the consequent visual impact for users. The important thing is to guarantee old projects to provide the same results (layouts) though, without re-designing them from the ground. Having both the old Composer and the new GUI tools would be misleading and confusing to the users, and I imagine it would double the effort to mantain both the tools. giovanni 2014-11-07 12:37 GMT+01:00 Nyall Dawson nyall.daw...@gmail.com mailto:nyall.daw...@gmail.com: Hi all, I'm seeking feedback about the best way to move forward with QGIS' map composer. I'm currently running up against some large issues with the current design and API of composer which are holding back important features and fixes. Some of these issues include: - there's too much composer logic tied up in app and gui. This makes it very difficult for plugins to manipulate and export compositions without duplicating large blocks of code - there's too much item-specific logic and handling scattered through QgsComposition, QgsComposerView and QgsComposer. This makes it impossible to have features like plugin generated item types, and makes maintenance difficult. - everything is coded to expect measurements and sizes in mm. I can't (nicely) add support for other units without breaking api or resorting to a lot of hacks - same for mixed page sizes and orientations within a single composition, this requires an api break to implement cleanly - I need to totally break composer api in order to fix the instability in undo/redo commands (see http://hub.qgis.org/issues/11371) - QgsComposition should not require a QgsMapSettings/QgsMapRenderer. This should instead be set individually for map items. Doing so would pave the way for features such as reprojection support for individual map items. - the composer is full is deprecated methods and legacy api I've slowly come to the conclusion that the way forward is to move to a bunch of new classes, much like what was done with symbologyV2. If https://github.com/qgis/QGIS-Enhancement-Proposals/pull/9 passes then these would be named QgsLayout, QgsLayoutDesigner, etc. If not, well, I'll have to resort to QgsCompositionV2, etc. The potential problem with this approach is how to handle the GUI and existing projects. As far as I can see, there's a few options: 1. Expose both the existing composer and the new layout designer to users. Composers aren't automatically upgraded to layouts.
Re: [Qgis-developer] Installin IntraMaps Roam
Hey Paolo, Did you build a project using the config manager first? Roam itself is just the viewer there is a different application to make the projects. - Nathan On Tue Nov 11 2014 at 7:43:11 PM Paolo Cavallini cavall...@faunalia.it wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all. I built and installed https://github.com/DMS-Aus/Roam on my Debian box, but I see a blank screen when I click on Projects: any suggestion on how to debug it? All the best, and thanks. - -- Paolo Cavallini - www.faunalia.eu QGIS PostGIS courses: http://www.faunalia.eu/training.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlRh2iMACgkQ/NedwLUzIr4r+ACfTz8wQD415Kq+7OKlnUePBh8R v4kAniCfxRIg4tq/JiCHmuoD0XMmSgxn =QiME -END PGP SIGNATURE- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Composer... current status and the way forward?
Hi, Another thing which deserves some work IMO is the text boxes : either you have to write HTML, or you're limited to 1 font/color/size per text box. Even if it's not really linked to the global structure of the composer, an improvement on this would have great impact on usability. There must be some lightweight wysiwyg html editor library hat we could use ? Ideally it should implement styles that you can apply throughout a project (probably through css classes, but I have the feeling someone already talked about this idea ?). And more about the live templates idea (if it's too much of a thread hijacking please start another one) : Maybe to avoid confusion between templates and live templates, we could call the live templates masters ? That's how they are called in Adobe Indesign (which is probably the most polished layouting software around). http://helpx.adobe.com/indesign/using/master-pages.html The thing Indesign isn't not doing well IMO is overrides : it involves an awkward keyboard shortcut and it's hard to know what exactly is overridden and what's not (what element, and what part of the element). The property system you're mentioning would probably be an excellent thing to manage inheritance. And then, there's a question about whether the masters are global or per-project. The problem with global masters is that you can have effects on other files without knowing it, and also that projects may display differently on different setups. I think we should only have per-project masters. And updating a project's layouts only involves reimporting the main master once (that may be a bit tricky though if we want to keep overrides, but using composer's items UUIDs we may make it work for some simple cases). Thanks a lot for those bigger refactoring initiatives ! Olivier 2014-11-11 10:52 GMT+01:00 Andreas Neumann a.neum...@carto.net: Hi, It would be very awesome to have live-linked templates! I would very much need them. I have a lot of operational projects and it is my fear that some day some details would change and I need to go into all of the projects and adopt things like logo, fonts, headers, etc. It would either require a script to process the .qgs files or a lot of manual work. So +1 for having live templates. Nyall, maybe you can plan the redesign in a way to make it possible? I would also participate in financing the development of these live templates. Andreas On 07.11.2014 20:10, Olivier Dalang wrote: Hi, I don't get the point in keeping the old classes if we upgrade the composers to layouts at opening ? Doesn't migration happen at XML level ? Maybe while thinking about reworking the composer, we could think about a new feature : real templates (aka masters in Indesign). All elements added to a master appear on all the page that apply it. This is very handy: you can always edit the master (move some elements, change the fonts/colors, etc.), and the changes are reflected on all the layouts. The challenging part from an UI point of view is the required ability to override the content of templates elements (for instance the extent of a map, the text of a textbox, etc.) I thought of making a plugin for this, but got discouraged because of the problem you exposed... So it would be a good test case to see if the future API for the layouts allows to implement this easily ;) Thanks ! Olivier 2014-11-07 16:26 GMT+01:00 Andreas Neumann a.neum...@carto.net: Hi Nyall, I also think that option 2 would work best. Option one would be very confusing (I remember the days when we had two labeling versions, 2 symbology versions, etc. - awful!). Thanks, Andreas On 07.11.2014 16:16, G. Allegri wrote: Hi Nyall, as I already told you privately, I agree with the second approach: remove the current Composer and guarantee transparent auto-upgrade of existing layouts in projects. The improvements to the composer worth the effort, and the consequent visual impact for users. The important thing is to guarantee old projects to provide the same results (layouts) though, without re-designing them from the ground. Having both the old Composer and the new GUI tools would be misleading and confusing to the users, and I imagine it would double the effort to mantain both the tools. giovanni 2014-11-07 12:37 GMT+01:00 Nyall Dawson nyall.daw...@gmail.com: Hi all, I'm seeking feedback about the best way to move forward with QGIS' map composer. I'm currently running up against some large issues with the current design and API of composer which are holding back important features and fixes. Some of these issues include: - there's too much composer logic tied up in app and gui. This makes it very difficult for plugins to manipulate and export compositions without duplicating large blocks of code - there's too much item-specific logic and handling scattered through QgsComposition, QgsComposerView and QgsComposer. This makes it
Re: [Qgis-developer] Geometry type conversion of 2.6
Hi, I just wanted to write also to the list because of a similar issue, but here it happens when using processing. I created a regular point grid over a polygon. As I just wanted to have the points inside the polygon and not the bounding box, I clipped it with the processing version of ftools clip. The readOGR in my R script I wanted to use the points with then complained about the layer being multipoint. Multipart to single part fortunately did the trick. The original ftools clip did deliver a normal point layer though. Cheers Bernd Am 11.11.2014, 09:28 Uhr, schrieb Minoru Akagi akagi...@gmail.com: Hi, I just found size of .shp file increases more than twice (2900 bytes - 6500 bytes when it has 100 points) when I saved a point layer as a shapefile. I didn't edit the layer anything, but the geometry type was converted from Point to Multipoint. Maybe this must not expected behavior. Is this a big bug of 2.6? See also #11542 and #11597. Regards, Minoru ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Bernd Vogelgesang Siedlerstraße 2 91083 Baiersdorf/Igelsdorf Tel: 09133-825374 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [Qgis-tr] size of translations, use a distinct repo?
Hi Denis, On Mon, 03. Nov 2014 at 08:32:01 +0100, Denis Rouzaud wrote: Last translation commit is quite large again, due to the Spanish file, although from a quick look it just seems to be new translations... Anyway, I'd like to raise again the idea of using git submodule for translation files. As written before, I think they are quite useless in the main repo. Even if we can limit drastically the growth of the files, I think they would be better suited in a distinct repo and have a small advantage regarding growth of the main repo. I found a project [0] which is using github / transifex with git submodule for translation files [1]. I believe no changes to current translation scripts would be required thanks to git submodules. It would just be a question of initialising the submodule and changing the url wherever needed. Does this need a QEP ? ;) I don't see what problem that solves. It just moves the growth into a different repository. Werner decided to move exclusively to transifex, because the coordination of which translations are maintained in our repository and which not, didn't really work out (I think the spanish translation was considered to be kept in our repository, although actually was maintained in transifex - hence the other round of changes). For me that actually is a backstep. Before I could update qgis_de.ts, translate in linguist, update TRANSLATORS and commit all of that in one commit. Without the locations that are only actual translations. Lately I also started to update qgis_en.ts in the process - as that's what transifex tracks. So that translator using transifex have a chance to keep up (I think qgis_en.ts exists only for transifex). Now I'd have to update qgis_en.ts, commit it, wait for transifex to pick it up (didn't yet try - maybe that happens instantly), download qgis_de.ts to translate with linguist, upload the result (or translate directly on the transifex site) and the pull the ts back from transifex and commit that - or wait for Werner's next transifex pull to have them appear in some future nightly build. Maybe we should just stop to keep the translations uptodate in our repository and let the nightly builds pull automatically from transifex instead. That way we always have the latest translations in the nightly builds and avoid all the unnecessary changes in our repository. And once shortly before release all of them would be pulled into our repository just to get them into the tarball. And I would just need update and commit qgis_en.ts when I want to start translating, commit it, translated it via transifex - and get it in the next nightly build without more extra steps and noise in the repository. Opinions? Jürgen -- Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31 Dipl.-Inf. (FH) Rheinstraße 13 Fax. +49-4931-918175-50 Software Engineer D-26506 Norden http://www.norbit.de QGIS release manager (PSC) GermanyIRC: jef on FreeNode signature.asc Description: Digital signature ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] FW: Support | Custom install for XenApp | Removing menu options
Hi, I've been trying to remove some functions from QGIS so we can deploy a stripped down version of it into a Citrix - XenApp 6.5 environment. I've posted on the QGIS forumhttp://gis.stackexchange.com/questions/120199/qgis-deployment-in-citrix-xenapp-how-to-remove-pyramids-from-the-image-proper to see if anyone could help me with this set-up. I need to remove the ability to build pyramids on QGIS when it is installed in XenApp (GIS team will use PC's to do rendering\pyramids overviews etc). I can use the customization tool built in QGIS to remove the Menu options, however I need to remove the 'Properties' (or just the Pyramids) option from the context menu when you right click on an Image. Here is an image of what I am trying to remove: [cid:image001.png@01CFFCFD.37FD8240] [cid:image004.jpg@01CFFCFE.6F437BA0] I need to prevent this option from being used on our XenApp environment due to the amount of memory it grabs. If a user runs this on a highly loaded server it could cause outage for the other users on that server, if possible I'd like to configure GIS to avoid the option being used by mistake. If it is not possible, that is fine. This is my last point of call for support, any help would be much appreciated. Thanks in advance. Steve DISCLAIMER: This email and any files transmitted with it may be confidential, legally privileged and protected in law and are intended solely for the use of the individual to whom it is addressed. The copyright in all documentation is the property of the Borough of Poole and this email and any documentation must not be copied or used other than as strictly necessary for the purpose of this email, without prior written consent which may be subject to conditions. Any view or opinions presented are solely those of the author and do not necessarily represent those of the Borough of Poole. The Borough of Poole reserves the right to inspect incoming and outgoing emails. If you have received this email in error please contact the sender by return and confirm that its contents have been destroyed. Telephone enquiries should be directed to the Borough switchboard on 01202 633633.' ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Save selection as
Am 10.11.2014, 16:14 Uhr, schrieb Andreas Neumann a.neum...@carto.net: Hi, I think that functionality that works on selections and not on the whole layer should always be optional, and not the default. And yes - consistency would be nice ;-) Please open a ticket with call for consistency. Thanks Anita -- anitagraser.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Processing save as script py
Hi all. I remember in previous versions of Processing it was possible to save commands and models as Python scripts. Now I no longer see this option: am I missing something? All the best, and thanks. -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Processing save as script py
Hi Paolo, maybe I'm wrong, but seems this feature was disabled/removed during modeler overhaul. Don't know reasons, hope Victor can shed some light on this. 2014-11-11 19:29 GMT+02:00 Paolo Cavallini cavall...@faunalia.it: Hi all. I remember in previous versions of Processing it was possible to save commands and models as Python scripts. Now I no longer see this option: am I missing something? All the best, and thanks. -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Alexander Bruy ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] FW: Support | Custom install for XenApp | Removing menu options
Hi Steven, Just a notion, and this is more of a “last ditch attempt” than anything else, but I’m reasonably sure that the pyramids are created using GDAL’s gdaladdo. So one possible option is to remove/rename gdaladdo.exe. In theory this would disable the functionality. I can’t test it myself because local admin privs stop me. But it might be worth a try if you’re feeling bold. Not sure if it’ll affect anything else; gdaladdo only seems to do pyramids, so might be ok. Cheers, Jonathan From: qgis-developer-boun...@lists.osgeo.org [mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf Of Steven Campbell Sent: Tuesday, November 11, 2014 2:45 PM To: 'qgis-developer@lists.osgeo.org' Subject: [Qgis-developer] FW: Support | Custom install for XenApp | Removing menu options Hi, I’ve been trying to remove some functions from QGIS so we can deploy a stripped down version of it into a Citrix - XenApp 6.5 environment. I’ve posted on the QGIS forumhttp://gis.stackexchange.com/questions/120199/qgis-deployment-in-citrix-xenapp-how-to-remove-pyramids-from-the-image-proper to see if anyone could help me with this set-up. I need to remove the ability to build pyramids on QGIS when it is installed in XenApp (GIS team will use PC’s to do rendering\pyramids overviews etc). I can use the customization tool built in QGIS to remove the Menu options, however I need to remove the ‘Properties’ (or just the Pyramids) option from the context menu when you right click on an Image. Here is an image of what I am trying to remove: [cid:image001.png@01CFFDD8.79EC3440] [cid:image002.jpg@01CFFDD8.79EC3440] I need to prevent this option from being used on our XenApp environment due to the amount of memory it grabs. If a user runs this on a highly loaded server it could cause outage for the other users on that server, if possible I’d like to configure GIS to avoid the option being used by mistake. If it is not possible, that is fine. This is my last point of call for support, any help would be much appreciated. Thanks in advance. Steve DISCLAIMER: This email and any files transmitted with it may be confidential, legally privileged and protected in law and are intended solely for the use of the individual to whom it is addressed. The copyright in all documentation is the property of the Borough of Poole and this email and any documentation must not be copied or used other than as strictly necessary for the purpose of this email, without prior written consent which may be subject to conditions. Any view or opinions presented are solely those of the author and do not necessarily represent those of the Borough of Poole. The Borough of Poole reserves the right to inspect incoming and outgoing emails. If you have received this email in error please contact the sender by return and confirm that its contents have been destroyed. Telephone enquiries should be directed to the Borough switchboard on 01202 633633.' This message has been scanned for viruses by MailControlhttp://www.mailcontrol.com/, a service from BlackSpider Technology Click herehttps://www.mailcontrol.com/sr/59afDHgHmtHGX2PQPOmvUvmldA89nuwl+uVwa3cC2WMYqA+tYINQQcgt!bBGUvwP+pKcdHXFkgmOdoKZwoXR0w== to report this email as spam. HR Wallingford and its subsidiaries uses faxes and emails for confidential and legally privileged business communications. They do not of themselves create legal commitments. Disclosure to parties other than addressees requires our specific consent. We are not liable for unauthorised disclosures nor reliance upon them. If you have received this message in error please advise us immediately and destroy all copies of it. HR Wallingford Limited Howbery Park, Wallingford, Oxfordshire, OX10 8BA, United Kingdom Registered in England No. 02562099 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Processing save as script py
Yes, it was removed. Basically i didn't have time to reimplement it and it had to be done again from scratch, because the model architecture changed completely. Since there are many improvements with the new modeler, i considered it worthwhile releasing it without this feature that i think is not one of the most important ones (and actually was not even a finished one, since not all models could be exported) I hope to have it ready for a future version, though 2014-11-11 18:39 GMT+01:00 Alexander Bruy alexander.b...@gmail.com: Hi Paolo, maybe I'm wrong, but seems this feature was disabled/removed during modeler overhaul. Don't know reasons, hope Victor can shed some light on this. 2014-11-11 19:29 GMT+02:00 Paolo Cavallini cavall...@faunalia.it: Hi all. I remember in previous versions of Processing it was possible to save commands and models as Python scripts. Now I no longer see this option: am I missing something? All the best, and thanks. -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Alexander Bruy ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Composer... current status and the way forward?
Hi Olivier, Regarding HTML editor: I very briefly discussed this with Nyall (and got an offer to do it)). I proposed to embed a Javascript based HTML editor (like TinyMCE (LGPL)). However, Nyall is probably now busy with composer/report builder. So it would probably be ok, if someone else works on this. I would also like to see this HTML editor in a text area widget - so people could write rich text in an attribute form. Maybe there is also a qt-based rich text widget we could use? Regarding live templates: I was hoping for a global live template that I could link into many projects. Otherwise it wouldn't help me much. On the other hand I don't need the overrides (maybe only the map title). I would only put fixed content in the live templates that needs to be on every print out (like company logo, print date, disclaimer, contact information, etc.). However, maybe one day I would need the overrides - one never knows ;-) Andreas On 11.11.2014 12:46, Olivier Dalang wrote: Hi, Another thing which deserves some work IMO is the text boxes : either you have to write HTML, or you're limited to 1 font/color/size per text box. Even if it's not really linked to the global structure of the composer, an improvement on this would have great impact on usability. There must be some lightweight wysiwyg html editor library hat we could use ? Ideally it should implement styles that you can apply throughout a project (probably through css classes, but I have the feeling someone already talked about this idea ?). And more about the live templates idea (if it's too much of a thread hijacking please start another one) : Maybe to avoid confusion between templates and live templates, we could call the live templates masters ? That's how they are called in Adobe Indesign (which is probably the most polished layouting software around). http://helpx.adobe.com/indesign/using/master-pages.html The thing Indesign isn't not doing well IMO is overrides : it involves an awkward keyboard shortcut and it's hard to know what exactly is overridden and what's not (what element, and what part of the element). The property system you're mentioning would probably be an excellent thing to manage inheritance. And then, there's a question about whether the masters are global or per-project. The problem with global masters is that you can have effects on other files without knowing it, and also that projects may display differently on different setups. I think we should only have per-project masters. And updating a project's layouts only involves reimporting the main master once (that may be a bit tricky though if we want to keep overrides, but using composer's items UUIDs we may make it work for some simple cases). Thanks a lot for those bigger refactoring initiatives ! Olivier 2014-11-11 10:52 GMT+01:00 Andreas Neumann a.neum...@carto.net mailto:a.neum...@carto.net: Hi, It would be very awesome to have live-linked templates! I would very much need them. I have a lot of operational projects and it is my fear that some day some details would change and I need to go into all of the projects and adopt things like logo, fonts, headers, etc. It would either require a script to process the .qgs files or a lot of manual work. So +1 for having live templates. Nyall, maybe you can plan the redesign in a way to make it possible? I would also participate in financing the development of these live templates. Andreas On 07.11.2014 20:10, Olivier Dalang wrote: Hi, I don't get the point in keeping the old classes if we upgrade the composers to layouts at opening ? Doesn't migration happen at XML level ? Maybe while thinking about reworking the composer, we could think about a new feature : real templates (aka masters in Indesign). All elements added to a master appear on all the page that apply it. This is very handy: you can always edit the master (move some elements, change the fonts/colors, etc.), and the changes are reflected on all the layouts. The challenging part from an UI point of view is the required ability to override the content of templates elements (for instance the extent of a map, the text of a textbox, etc.) I thought of making a plugin for this, but got discouraged because of the problem you exposed... So it would be a good test case to see if the future API for the layouts allows to implement this easily ;) Thanks ! Olivier 2014-11-07 16:26 GMT+01:00 Andreas Neumann a.neum...@carto.net mailto:a.neum...@carto.net: Hi Nyall, I also think that option 2 would work best. Option one would be very confusing (I remember the days when we had two labeling versions, 2 symbology versions, etc. - awful!). Thanks, Andreas On 07.11.2014 16:16, G. Allegri wrote: Hi Nyall,
Re: [Qgis-developer] FW: Support | Custom install for XenApp | Removing menu options
Hi Steven, I post an answer in Stackexchange in your original question. Cheers Régis -- View this message in context: http://osgeo-org.1560.x6.nabble.com/FW-Support-Custom-install-for-XenApp-Removing-menu-options-tp5172389p5172423.html Sent from the Quantum GIS - Developer mailing list archive at Nabble.com. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] FW: Support | Custom install for XenApp | Removing menu options
Hi Jonathan, On Tue, 11. Nov 2014 at 17:54:39 +, Jonathan Moules wrote: Just a notion, and this is more of a last ditch attempt than anything else, but I'm reasonably sure that the pyramids are created using GDAL's gdaladdo. Both gdaladdo and QGIS use GDALBuildOverviews[1] - IOW removing gdaladdo won't help. Jürgen [1] http://gdal.org/gdal_8h.html#a767f4456a6249594ee18ea53f68b7e80 -- Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31 Dipl.-Inf. (FH) Rheinstraße 13 Fax. +49-4931-918175-50 Software Engineer D-26506 Norden http://www.norbit.de QGIS release manager (PSC) GermanyIRC: jef on FreeNode signature.asc Description: Digital signature ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Toggle Editing Icon in Layer
Hi Martin, Sorry for my late answer. Please see attached file as example. Regards Lene -Oprindelig meddelelse- Fra: Martin Dobias [mailto:wonder...@gmail.com] Sendt: 10. november 2014 08:32 Til: Lene Fischer Cc: qgis-developer@lists.osgeo.org Emne: Re: [Qgis-developer] Toggle Editing Icon in Layer Hi Lene On Sun, Nov 9, 2014 at 5:11 AM, Lene Fischer l...@ign.ku.dk wrote: Hi, I´m working with 2.6, in the Layer module. I find it difficult to see both the style and the editing pencil because they are on top of each other. I realize that it save space in height, but it has become very difficult to read which layer are in edit mode. Is there a special reason for this change of behavior from 2.4 to 2.6 ? The idea was indeed to reduce the height - and in many cases it helps a lot. Maybe we can just slightly change the way how the editing pencil is shown - for example to put it next to symbol preview icon (instead of drawing over it) - would that work for you? Cheers Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [Qgis-tr] size of translations, use a distinct repo?
Hi! Sounds like a reasonable idea to me, if the translations will be in nightly I've got no problem (and I also think that the translators don't have any). For people compiling out of sources it shouldn't be any problem to pull from transifex either and compile. So if we (more or less) completely stop updating instantly in source repository but rather only update directly in front of a release and that helps keeping the code small - I am in. But speaking from pulling in.. Maybe it is possible to integrate tx pull of the translations directly in the make command? I don't know if it's possible to check for internet connection or not but it would be nice to automatically look for new translations right in front of a compile run. regards Werner On Tue, Nov 11, 2014 at 3:35 PM, Jürgen E. j...@norbit.de wrote: Hi Denis, On Mon, 03. Nov 2014 at 08:32:01 +0100, Denis Rouzaud wrote: Last translation commit is quite large again, due to the Spanish file, although from a quick look it just seems to be new translations... Anyway, I'd like to raise again the idea of using git submodule for translation files. As written before, I think they are quite useless in the main repo. Even if we can limit drastically the growth of the files, I think they would be better suited in a distinct repo and have a small advantage regarding growth of the main repo. I found a project [0] which is using github / transifex with git submodule for translation files [1]. I believe no changes to current translation scripts would be required thanks to git submodules. It would just be a question of initialising the submodule and changing the url wherever needed. Does this need a QEP ? ;) I don't see what problem that solves. It just moves the growth into a different repository. Werner decided to move exclusively to transifex, because the coordination of which translations are maintained in our repository and which not, didn't really work out (I think the spanish translation was considered to be kept in our repository, although actually was maintained in transifex - hence the other round of changes). For me that actually is a backstep. Before I could update qgis_de.ts, translate in linguist, update TRANSLATORS and commit all of that in one commit. Without the locations that are only actual translations. Lately I also started to update qgis_en.ts in the process - as that's what transifex tracks. So that translator using transifex have a chance to keep up (I think qgis_en.ts exists only for transifex). Now I'd have to update qgis_en.ts, commit it, wait for transifex to pick it up (didn't yet try - maybe that happens instantly), download qgis_de.ts to translate with linguist, upload the result (or translate directly on the transifex site) and the pull the ts back from transifex and commit that - or wait for Werner's next transifex pull to have them appear in some future nightly build. Maybe we should just stop to keep the translations uptodate in our repository and let the nightly builds pull automatically from transifex instead. That way we always have the latest translations in the nightly builds and avoid all the unnecessary changes in our repository. And once shortly before release all of them would be pulled into our repository just to get them into the tarball. And I would just need update and commit qgis_en.ts when I want to start translating, commit it, translated it via transifex - and get it in the next nightly build without more extra steps and noise in the repository. Opinions? Jürgen -- Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31 Dipl.-Inf. (FH) Rheinstraße 13 Fax. +49-4931-918175-50 Software Engineer D-26506 Norden http://www.norbit.de QGIS release manager (PSC) GermanyIRC: jef on FreeNode -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQIVAwUBVGIeuBBsJ9SQbsVUAQKhEBAAsnjXaCJ5iB2/7+pI0ceVJ7IR63wyk3L/ MAERycQ9Ha+zj9F4VhEMqEtwYvONUvfoEOQzdVrcxNRxKi8KAVt8cMeix9uSuDxX tYVp2jC+0RQvf4BbMmrtFtEihJkVnYr5HPt27DkRhUVBN/LLLEVokVRN1kDWLRcy OVGt0CLF3KpZH5uRwPCElKItRlUhufAqZ423yi+cvBA+YSslIoNKslm6kWItlvW7 EiVRfCHTVHLIN8Fgv58ZLwxNTetWqEmq5MOsoKz6n+bGLv1tgqdpr7W6aN4CEV7P 4jQit53L/sm/h+pE3nGVFcqjy6tK7Khqf3Rq6rny+6pL4gemSsVqxycLHOOyQz9x mcIAhCvp2reyVL+5SVgTQa0P2JOeZUWu37eTJBlCyPXt2DEqD+IKS5JARNP+RgWi 6fNgTvx1vQDLahMgGLXBCCaO1SSL3dJZictwwgJ+wlONxnWmANX1TArkTcV2dKEw VaM29hsGpavgRU6vMpIihgnLiveDumnw4jVWJF4a7Lonqu7Tb4/zoU3KANGxbs5e njvq4chqjJ5yGt6BA+Lga2ZNlRWl29sgLXzj1pC0nVA6vdrLdipZSGAorIl3lEpU Z1R5n46g3/1QOGFscSaCoTiArX5GdOQRSx9ALQWphvYd6UXUpc6SfnN44uJPeBRs hDB5qvQtKsM= =eQeh -END PGP SIGNATURE- ___ Qgis-tr mailing list qgis...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-tr ___ Qgis-developer mailing list
Re: [Qgis-developer] Processing save as script py
Il 11/11/2014 19:36, Victor Olaya ha scritto: Yes, it was removed. Basically i didn't have time to reimplement it and it had to be done again from scratch, because the model architecture changed completely. Since there are many improvements with the new modeler, i considered it worthwhile releasing it without this feature that i think is not one of the most important ones (and actually was not even a finished one, since not all models could be exported) I hope to have it ready for a future version, though Thanks Victor for clarifying. Should I open a ticket, not to forget about this, and to better document the process? All the best. -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Processing save as script py
yes, good idea thanks! 2014-11-12 7:50 GMT+01:00 Paolo Cavallini cavall...@faunalia.it: Il 11/11/2014 19:36, Victor Olaya ha scritto: Yes, it was removed. Basically i didn't have time to reimplement it and it had to be done again from scratch, because the model architecture changed completely. Since there are many improvements with the new modeler, i considered it worthwhile releasing it without this feature that i think is not one of the most important ones (and actually was not even a finished one, since not all models could be exported) I hope to have it ready for a future version, though Thanks Victor for clarifying. Should I open a ticket, not to forget about this, and to better document the process? All the best. -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Processing save as script py
Il 12/11/2014 08:00, Victor Olaya ha scritto: yes, good idea done: http://hub.qgis.org/issues/11620 thanks -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
