Bug report #13418

Print Composer : "Lock layer style for map item" doesn't update the map if style used in preset is updated

Added by Harrissou Santanna over 8 years ago. Updated almost 8 years ago.

Status:Closed
Priority:High
Assignee:-
Category:Map Composer/Printing
Affected QGIS version:master Regression?:No
Operating System: Easy fix?:No
Pull Request or Patch supplied:No Resolution:
Crashes QGIS or corrupts data:No Copied to github as #:21467

Description

A visibility preset is a combination of active styles of visible layers (or default style if layer has only one).
In Print composer, map item's properties:
- "Lock layers for map item" : will save the visible layers; the map is updated according to these layers' active style.
- Selecting a preset (and automatically check "Lock layer style for map item" option): will save in the map the layers set in the preset definition with the style they were defined with. Uncheck "Lock layer style for map item" (and automatically uncheck the preset) will just keep the previous preset layers and map item will be updated according to their active style.
- "Lock layer style for map item" (without preset assigned): will save the locked layers with their current style; whatever may be later their active style, map will still show the style the map was locked with.

All this is great except that when the style locked in the map (either through a preset definition or not) changed, the changes are applied in map canvas but the composer map's item doesn't take into account these changes, leading to situation where the map shown in composer may not correspond to nothing in map canvas.

Looking at qgs file xml, it appears that while locking the style in map's item, almost the layer's style is pasted into composer map layer's properties. And these properties do not update. What about just put reference to preset or layer and if needed, style name (since any style has a name -- default or custom). This may ensure correspondance between map canvas and map item and reduce the file size.

Associated revisions

Revision deee8e29
Added by Martin Dobias almost 8 years ago

[FEATURE] Composer map to follow a visibility preset (fixes #13418)

This adds a new option in composer map properties:
"Follow visibility preset" with a combo box to choose the active preset.

This is an alternative to "lock layers" (and "lock layer styles") functionality
which would just copy preset's configuration, while the new option links to preset.

The difference is that when a preset is updated, composer map will automatically
pick the new configuration when following the preset, while there is no update
if "lock layers" (and "lock layer styles") option is used.

History

#1 Updated by Nyall Dawson over 8 years ago

  • Assignee deleted (Nyall Dawson)

#2 Updated by Anita Graser over 8 years ago

  • Status changed from Open to Closed
  • Resolution set to invalid

Imho, the intended behavior of "Lock layer style for map item" is that the layer is "frozen"/locked to the current style settings and no subsequent changes should alter the appearance of the layer inside the map item.

As far as I understand, this has nothing to do with the presets which simply define which layers should be visible.

(Please reopen if necessary)

#3 Updated by Harrissou Santanna over 8 years ago

  • Status changed from Closed to Reopened
I understand what u mean about the option and i agree that it is not related to preset.
But if the aim is just to freeze the current appearance, two remarks :
  • this option shouldn't be tied to preset selection. Once u select a preset, this option is checked. uncheck it, and the preset is lost. Preset can evolve and once you choose it for a map, it's expected that map item follows the changes in preset without being obliged to open composer and check the preset each time you change a related style. With the current behaviour, using a preset in the composer is painful.
  • Then I can not understand the interest in just keeping the current appearance of layers; layers can have many styles so better keep the styles instead of its appearance. The side effect I see for this behaviour is that, if you make many changes to the layers, at a moment, whatever combination of layers/styles you do in the map canvas, you'll not get the map you have in the composer. And this can really puzzle users. And more if you haven't touched your project for days.

Imho, since each style of layer can now be identified (default or whatever name) and people can create as many styles as they want per layer, the "Lock layer style for map item" shouldn't just keep the current appearance; it should save the combination of used styles. If one of these styles change, it follows.

#4 Updated by Harrissou Santanna over 8 years ago

Anita Graser wrote:

As far as I understand, this has nothing to do with the presets which simply define which layers should be visible.

Just to add that preset is more than "simply define which layers should be visible". It helps to quickly define which style of which layers should be visible. And if this is really a great feature in map canvas (now that it can be updated), it'll really simplify life and improve composition for those who use many print composers if its behaviour is coherent in print composer.

#5 Updated by Anita Graser over 8 years ago

Thanks for the clarification Harrissou!

#6 Updated by Giovanni Manghi over 8 years ago

  • Target version deleted (Version 2.12)

#7 Updated by Harrissou Santanna about 8 years ago

  • Resolution deleted (invalid)

I was wondering what's the current state of this bug. Is it expected to be fixed for LTR 2.14?
Should not be set invalid. If more explanation is needed, I'm free to give them. It is a real bug that makes preset use in print composer almost a nightmare.

#8 Updated by Nyall Dawson about 8 years ago

It's still a valid (unresolved) bug

#9 Updated by Martin Dobias about 8 years ago

Agreed this is quite a significant usability problem - even though it works as it was originally planned.

To understand why things work as they do right now: first there was an option to lock layers (otherwise it would always use layers from canvas), later in 2.8 we added option to lock layer style (otherwise it would always use the current style), and finally we added the button to pick a visibility preset and copy layers and styles from it. Probably the most confusing part is the checkbox in the visibility presets menu, which makes a preset checked when it is equivalent to layers+styles currently locked in composer map item - giving impression that it is active (which it is not).

I think the most appropriate fix would be to introduce option to stick to a visibility preset, so there will be three options:
1. following main map canvas (default)
2. following selected visibility preset (new option)
3. custom configuration of layers(+styles) that is static (not following anything) - as of now done by locked layers and locked styles

I am even thinking that for simplicity, it would be reasonable to remove the third option (locked layers/styles) and keep just the first two.

Thoughts?

#10 Updated by Denis Rouzaud about 8 years ago

Indeed stitching to the first 2 seems reasonable and would avoid confusion!

#11 Updated by Harrissou Santanna about 8 years ago

Hi,
Thanks Martin to give it a look

Probably the most confusing part is the checkbox in the visibility presets menu, which makes a preset checked when it is equivalent to layers+styles currently locked in composer map item - giving impression that it is active (which it is not).

Not sure if I understand. Do you mean that currently, if i check a preset, it's not the preset itself that is saved but its current configuration (layers+style with no further update)? This is what I seem to remark.
You don't mean the removal of the preset listbox and its checkboxes, don't you?

I think the most appropriate fix would be to introduce option to stick to a visibility preset, so there will be three options:

1. following main map canvas (default)
2. following selected visibility preset (new option)
3. custom configuration of layers(+styles) that is static (not following anything) - as of now done by locked layers and locked styles
I am even thinking that for simplicity, it would be reasonable to remove the third option (locked layers/styles) and keep just the first two.

Indeed the third option is really confusing. Having a composition that follows nothing is one of the side-effect of the current implementation and should be avoided. However, I see three options that are:

  1. following map canvas (as default - nothing is checked), using the current visible layers and their current active style
  2. lock layers as it behaved before preset introduction (you may want to create a composition with a set of layers without configuring a preset). But given that a layer can have many styles, there can be two options:
    1. it just locks the layers list but shows for each one their current representation (meaning that it fetches the active style)
    2. or it locks layer with their style: layer representation is stuck with the style name active when locking , meaning that the representation of the layer will follow the representation of that style (it doesn't care if it's still the active style or not)

    This means that the "lock layer styles for map item" will be manually checked to choose between these two sub-options. And contrarily to Martin third option, there's still a link possible between the layer shown in the map item and (one of) its style.

  3. following selected preset: shows the layers locked in the preset with their corresponding styles in the preset configuration. Using this option greys the "lock layer styles for map item" given that styles are managed by the preset.

What can be a big improvement (especially because of option 2) would be a "View style combination in map canvas" button (like the "View extent in map canvas") to set visible in the map canvas the current (layer + style) combination from print composer. Does it sound enough coherent to you so that I open a feature request?

#12 Updated by Harrissou Santanna about 8 years ago

Hi,
Up this thread, expecting some comments on the above proposal

#13 Updated by Martin Dobias almost 8 years ago

  • Status changed from Reopened to Closed

Also available in: Atom PDF