Re: [Qgis-developer] Composer... current status and the way forward?
I'm not sure about the final scheduling for the composer refactoring. Following the discussions about LTS and QGIS 3.0 will it be shifted to 3.0? giovanni Il 11/nov/2014 21:20 Olivier Dalang olivier.dal...@gmail.com ha scritto: I just checked, there's a rich text example for Qt5 : http://qt-project.org/doc/qt-5/qtwidgets-richtext-textedit-example.html I guess it's also doable with Qt4, since the QTextEdit widget already works with HTML, but the provided examples are not exactly a wysiwyg editor. http://qt-project.org/doc/qt-4.8/examples-richtext.html However, TinyMCE is also nice, especially since it allows to work easily on the underlying HTML, so it's even useful for power users. I'd love to give it a shot but I'm really not enough at ease with C++ to do more than copy/paste some lines of code. And about the live templates, the nice thing of overrides is for instance when you have several thematic maps, and want the same layout for all those (same map extent, same position of the legend, etc.). You can update all of those at once. I don't know for you, but I have more than one layout in almost all of my projects. A good practice is to have a general master defining the very static elements (company logo, guides for margins...) in all of your projects, and several other masters dependent of every project that inherit the general master (for instance one where you display a big map and a small overview, one with two maps side by side, ...). This way, you can simply reimport your company template in the general master, and have all your project's layout update. Still, you're able to reopen old projects without having them automatically modified. Olivier 2014-11-11 20:57 GMT+01:00 Andreas Neumann a.neum...@carto.net: 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: 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
Re: [Qgis-developer] Composer... current status and the way forward?
PS: assuming the QEP will be accepted... Il 13/nov/2014 00:05 G. Allegri gioha...@gmail.com ha scritto: I'm not sure about the final scheduling for the composer refactoring. Following the discussions about LTS and QGIS 3.0 will it be shifted to 3.0? giovanni Il 11/nov/2014 21:20 Olivier Dalang olivier.dal...@gmail.com ha scritto: I just checked, there's a rich text example for Qt5 : http://qt-project.org/doc/qt-5/qtwidgets-richtext-textedit-example.html I guess it's also doable with Qt4, since the QTextEdit widget already works with HTML, but the provided examples are not exactly a wysiwyg editor. http://qt-project.org/doc/qt-4.8/examples-richtext.html However, TinyMCE is also nice, especially since it allows to work easily on the underlying HTML, so it's even useful for power users. I'd love to give it a shot but I'm really not enough at ease with C++ to do more than copy/paste some lines of code. And about the live templates, the nice thing of overrides is for instance when you have several thematic maps, and want the same layout for all those (same map extent, same position of the legend, etc.). You can update all of those at once. I don't know for you, but I have more than one layout in almost all of my projects. A good practice is to have a general master defining the very static elements (company logo, guides for margins...) in all of your projects, and several other masters dependent of every project that inherit the general master (for instance one where you display a big map and a small overview, one with two maps side by side, ...). This way, you can simply reimport your company template in the general master, and have all your project's layout update. Still, you're able to reopen old projects without having them automatically modified. Olivier 2014-11-11 20:57 GMT+01:00 Andreas Neumann a.neum...@carto.net: 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: 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
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] 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] 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] Composer... current status and the way forward?
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 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. This approach means that existing PyQgis code and plugins will still function for existing projects, but at the expense of a confusing experience for users. 2. Add all the new layout classes and keep the existing composer classes. Composer would NOT be exposed in the GUI and compositions are upgraded to layouts when projects are opened. This approach means that standalone python code would still operate, but plugins or code which are designed to be run from within QGIS would no longer function. 3. Move totally to the new layout classes and remove all composer classes (unlikely) I'm leaning toward option 2, but what are you thoughts? What's the best approach to move forward? Obviously I'll submit all this as a QEP when the plans are finalised, but for now I'm just after advice on the preferred approach. Nyall ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Giovanni Allegri http://about.me/giovanniallegri Twitter: https://twitter.com/_giohappy_ blog: http://blog.spaziogis.it GEO+ geomatica in Italia http://bit.ly/GEOplus ___ 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 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. This approach means that existing PyQgis code and plugins will still function for existing projects, but at the expense of a confusing experience for users. 2. Add all the new layout classes and keep the existing composer classes. Composer would NOT be exposed in the GUI and compositions are upgraded to layouts when projects are opened. This approach means that standalone python code would still operate, but plugins or code which are designed to be run from within QGIS would no longer function. 3. Move totally to the new layout classes and remove all composer classes (unlikely) I'm leaning toward option 2, but what are you thoughts? What's the best approach to move forward? Obviously I'll submit all this as a QEP when the plans are finalised, but for now I'm just after advice on the preferred approach. Nyall ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org mailto:Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Giovanni Allegri http://about.me/giovanniallegri Twitter: https://twitter.com/_giohappy_ blog: http://blog.spaziogis.it GEO+ geomatica in Italia http://bit.ly/GEOplus ___ 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, 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 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. This approach means that existing PyQgis code and plugins will still function for existing projects, but at the expense of a confusing experience for users. 2. Add all the new layout classes and keep the existing composer classes. Composer would NOT be exposed in the GUI and compositions are upgraded to layouts when projects are opened. This approach means that standalone python code would still operate, but plugins or code which are designed to be run from within QGIS would no longer function. 3. Move totally to the new layout classes and remove all composer classes (unlikely) I'm leaning toward option 2, but what are you thoughts? What's the best approach to move forward? Obviously I'll submit all this as a QEP when the plans are finalised, but for now I'm just after advice on the preferred approach. Nyall ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Giovanni Allegri http://about.me/giovanniallegri Twitter: https://twitter.com/_giohappy_ blog:
Re: [Qgis-developer] Composer... current status and the way forward?
On 08/11/2014 6:11 am, Olivier Dalang olivier.dal...@gmail.com 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 ? It would allow standalone scripts which utilise compositions, or scripts which operate within qgis but without any gui, to still function. 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 ;) Hmmm.. Intriguing idea. On my longer term radar is a rework of how composer item properties work. I think eventually we need to switch to a property browser for setting item properties (think qt designer style). A new button just like the data defined button could be used to set property inheritance. (I think eventually labelling could use the same widget). This is out of scope for the planned 2.8 work, but I'll keep it in mind whilst doing the redesign. Nyall ___ 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?
Nyall, Please, let's not go down the road of two options to do the same thing (ala double symbology double labelling engine era of qgis 1.x) Nor can we leave users' previously saved composers broken. So #2 seems to be the wining option. A fundamental change like that would go very well with a name change too. Every move that gets us closer to having non mm units is worth the sweat :) On 7 Nov 2014 18:38, Nyall Dawson nyall.daw...@gmail.com wrote: 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. This approach means that existing PyQgis code and plugins will still function for existing projects, but at the expense of a confusing experience for users. 2. Add all the new layout classes and keep the existing composer classes. Composer would NOT be exposed in the GUI and compositions are upgraded to layouts when projects are opened. This approach means that standalone python code would still operate, but plugins or code which are designed to be run from within QGIS would no longer function. 3. Move totally to the new layout classes and remove all composer classes (unlikely) I'm leaning toward option 2, but what are you thoughts? What's the best approach to move forward? Obviously I'll submit all this as a QEP when the plans are finalised, but for now I'm just after advice on the preferred approach. Nyall ___ 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
