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

Wed Nov 12 15:05:38 PST 2014

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/607fa1f4/attachment-0001.html>