[Qgis-developer] Composer... current status and the way forward?

G. Allegri giohappy at gmail.com
Wed Nov 12 15:06:26 PST 2014 

PS: assuming the QEP will be accepted...
Il 13/nov/2014 00:05 "G. Allegri" <giohappy at 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.dalang at 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.neumann at 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.neumann at 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.neumann at 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.dawson at 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 at 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 listQgis-developer at lists.osgeo.orghttp://lists.osgeo.org/mailman/listinfo/qgis-developer
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Qgis-developer mailing list
>>>>> Qgis-developer at lists.osgeo.org
>>>>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>> _______________________________________________
>> Qgis-developer mailing list
>> Qgis-developer at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20141113/01d66e00/attachment-0001.html>

More information about the Qgis-developer mailing list