Bug report #7755
Using bufferSize to enable/disable label buffer is confusing
| Status: | Closed | ||
|---|---|---|---|
| Priority: | Normal | ||
| Assignee: | - | ||
| Category: | Labelling | ||
| Affected QGIS version: | master | Regression?: | No |
| Operating System: | Easy fix?: | No | |
| Pull Request or Patch supplied: | No | Resolution: | fixed |
| Crashes QGIS or corrupts data: | No | Copied to github as #: | 16655 |
Description
Currently, the value of the label buffer size is used to determine whether or not label buffers are enabled. Unchecking buffer sets the buffer size to 0.
This is confusing - for instance:
1. enable buffer, set it up nicely with the right size
2. temporarily disable buffer by unchecking it
3. try to reenable buffer by going back into label properties and ticking buffer
This results in two confusing outcomes:
1. The buffer size has been reset to 0 - if I don't manually change this to a non-zero buffer then the buffers are still disabled, even though it looks like I've switched them on
2. Any tweaks to the buffer size I've previously made have been lost
It would be better if a bufferDraw property were used (similar to how shadowDraw and shapeDraw are used for shadows and shapes), so that the buffer enable/disable state is kept separate to the actual buffer size.
History
#1
Updated by Larry Shaffer over 11 years ago
Hi Nyall,
This is a known issue that is currently being fixed (for all pre-2.0 label settings). See the notes associated with "Redesign GUI to prepare for styles and rule-based setup" under the GUI section of New Labeling changes and roadmap. Pretty much all of those notes should be done on Monday.
I'm guessing that with the original implementation of data definitions (which were only field mappings) it was simpler to key off of an empty value instead of forcing creation of yet another attribute field just to turn the option on/off (e.g. bufferDraw type toggles). This setup leads to issues, as you've seen, which is why I've avoided it for new labeling features. It also makes it difficult to move forward with a better data definition setup.
With the new setup, all data definitions can be expressions or field mappings, so there is no need to add an extra attribute field. An expression is perfectly suited for 'bufferDraw' type of data definition toggles.
Also, all layer-level labeling feature settings, expressions and field mappings should be preserved between Apply actions and app relaunches and regardless of whether they are used. So switching back-and-forth when trying out different label settings nothing should be lost anymore (that's the goal anyway).
I'm working as fast as I can on this, since it is the finishing bit for 2.0 labeling (excepting existing bugs, of course). :^)
#2
Updated by Nyall Dawson over 11 years ago
Larry - thanks for the detailed reply, and for all the hard work you're putting into the QGIS labelling engine. I'm excited for this final part to land and to start exploring the possibilities it unlocks!
#3
Updated by Larry Shaffer over 11 years ago
- Resolution set to fixed
- Status changed from Open to Closed