[Qgis-developer] Composer... current status and the way forward?
Andreas Neumann
a.neumann at carto.net
Tue Nov 11 11:57:56 PST 2014
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
> <mailto: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
>> <mailto: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 <mailto: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
>>> <mailto: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 list
>>> Qgis-developer at lists.osgeo.org <mailto:Qgis-developer at lists.osgeo.org>
>>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>>
>> _______________________________________________
>> Qgis-developer mailing list
>> Qgis-developer at lists.osgeo.org
>> <mailto: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/20141111/e16a05ee/attachment-0001.html>
More information about the Qgis-developer
mailing list