Bug report #14052
Symbol selector dialog: useless advanced "Clip features to canvas extent" option
| Status: | Closed | ||
|---|---|---|---|
| Priority: | Normal | ||
| Assignee: | - | ||
| Category: | - | ||
| Affected QGIS version: | 2.12.0 | Regression?: | No |
| Operating System: | Easy fix?: | No | |
| Pull Request or Patch supplied: | No | Resolution: | |
| Crashes QGIS or corrupts data: | No | Copied to github as #: | 22063 |
Description
Open Settings menu --> Style Manager
Activate Line or Fill tab and click Edit or Add button
At the bottom of the symbol selector dialog, there's an Advanced drop-down list with a single already checked option : "Clip features to canvas extent".
Wonder its use since there's no feature nor canvas at this level.
History
#1
Updated by Nyall Dawson over 8 years ago
- Status changed from Open to Closed
- Resolution set to invalid
That option still applies to a symbol, even in the style manager - it's used to modify the appearance of a centroid or distance offset based symbol so that either the centroid is always visible or the true centroid of the entire feature.
#2
Updated by Harrissou Santanna over 8 years ago
- Status changed from Closed to Reopened
I'm sorry but I don't understand your answer.
In the Style Manager, we're just building models of symbols, models that, i agree, can be later used to style layer or map composer. but, at this moment, it's just a model.
When the designed symbol is applied to a feature (styling a layer), then it'll be needed to ensure it doesn't overlap feature's limit or canvas. Thus I think the Clip option should be available when the dialog is accessed through layer's properties --> Style -->... but not in the context of modeling the symbol itself.
Checking the centroid Fill type, I wonder if the explanation you gave for "Clip" option does not lead it to be a duplicate of the "Force point into polygon" option? and if my remarks above should not also be applied to that option?
I may have misunderstood your answer, that said.
#3
Updated by Nyall Dawson over 8 years ago
I think you may be misunderstanding what this setting does. Easiest way to explain is to try turning it on and off with a centroid fill style, and then zooming in and out on parts of the feature.
If the option isn't ticked, the centroid will always be shown - it's the centroid of the visible portion of the feature.
If it's on, the centroid will stay in the save place, so may not be visible.
It's similar to the force point in polygon option, but different. But it sold be handled similarly, in that it applies to a symbol and affects it's appearance.
Short answer: this isn't a bug ;)
#4
Updated by Giovanni Manghi over 8 years ago
- Status changed from Reopened to Closed
#5
Updated by Harrissou Santanna over 8 years ago
- Status changed from Closed to Reopened
Nyall Dawson:
Short answer: this isn't a bug ;)
If by bug you mean "the option fails to do what it's designed for", I agree with you (though I haven't checked it). I haven't checked it because it's not what i was reporting. Maybe should i have reported it as a feature request but i wasn't asking for an enhancement either.
As stated earlier, I'm not styling a layer and to be more precise I'm trying to document what are the intrinsic properties of a symbol. So don't access the symbol selector dialog through Layer's properties > Style > ... but through Settings menu > Style Manager > ... and ask yourself if this advanced drop-down option is a property :
- to design the symbol itself (which can then be saved and exported)
- or to design the symbol in a context of feature symbology, how the feature style should behave.
What's more coherent?
The layer Style dialog is built by agregating different widgets (including symbol selector's) so if the latter case is the answer, why not move this (these) option(s) at the layer level (as it appears in Style > Single Symbol dialog)?
Note that i can understand if such a design is complicated to implement, given that "Clip features to canvas extent" is used at "layer style class" level and not at layer's. Is there use case when user can check it for a class and not for another one (note also that it's a somehow hidden and already checked option)?
#6
Updated by Harrissou Santanna over 8 years ago
Closing a subject while it's being discussed is not fair, Giovanni, and doesn't encourage people to contribute. This subject has just one day and is active and there are so many elder bug reports that are worth closing, I think.
#7
Updated by Giovanni Manghi over 8 years ago
- Status changed from Reopened to Feedback
Harrissou Santanna wrote:
Closing a subject while it's being discussed is not fair, Giovanni, and doesn't encourage people to contribute. This subject has just one day and is active and there are so many elder bug reports that are worth closing, I think.
this comment is not fair: keeping this bug tracker clean is a pretty time consuming task, that I do pretty much since 2009. I closed this ticket because a main developer told us that this report is not a bug. If you think it is you should keep the discussion active, make your point and then if you are right it will be reopened. So please don't get get me wrong (when I close tickets like this one) but also leave to us the closing/reopening task. A closed ticket does not mean is a dead one.
#8
Updated by Harrissou Santanna over 8 years ago
Sorry if I hurt you. I wasn't criticising the work you may have done on the bug tracker. I've no skill to judge it so I'd never try to criticise. This is not my first issue report you close and it may not be the last. Having it closed simply like that makes me feel that my report was just felt as noisy and it's not cumfortable.
Though I doubt about
A closed ticket does not mean is a dead one.
(I'm not sure dev still spend time on a issue that is referenced as closed) let me precise that I just reopen the report once. The second reopening is related to the fact that I was already writing my message when you close it. "Reopened" was already the message status.
If I may ask a last question about bug tracker management, why is the status field modifiable if simple reporter should not change it?
#9
Updated by Giovanni Manghi over 8 years ago
Harrissou Santanna wrote:
Having it closed simply like that makes me feel that my report was just felt as noisy and it's not cumfortable.
It wasn't closed without justification. Moreover I also think that this ticket is invalid: in the style manager you may want create a new symbol (think to the centroid renderer for polygons example) that may have (or not) the "Clip features to canvas extent" option active. What's wrong with that?
(I'm not sure dev still spend time on a issue that is referenced as closed)
I'm sure that the ones that are active here on Redmine keep an eye on any kind of activity, also on closed tickets.
#10
Updated by Harrissou Santanna over 8 years ago
I still don't understand which feature and which canvas we are talking about at this level of the design (keep in mind the "modular" level I refered to in my earlier posts).
Maybe I'm too much obtuse to change my mind or fail to explain my point.
Whatever, feel free to close the ticket as you also think it's an invalid one. it was more a matter of UX than a buggy feature, so no pain.
#11
Updated by Giovanni Manghi over 8 years ago
- Resolution deleted (
invalid)
Harrissou Santanna wrote:
I still don't understand which feature and which canvas we are talking about at this level of the design (keep in mind the "modular" level I refered to in my earlier posts).
Maybe I'm too much obtuse to change my mind or fail to explain my point.
When a symbol is created directly in the style manager it is not tied to any specific feature, layer or canvas. But nevertheless when applied to a specific layer its options (like "Clip features to canvas extent") are applied. I don't know, to me it makes completely sense.
#12
Updated by Jürgen Fischer over 8 years ago
Harrissou Santanna wrote:
there are so many elder bug reports that are worth closing, I think.
Feel free to do so.
#13
Updated by Nyall Dawson over 8 years ago
- Status changed from Feedback to Closed
Ok, let's close this. It's most definitely a symbol related setting and belongs in the dialog. Here's some extra proof:
1. create a fill symbol with a second symbol layer set to "centroid fill". Leave the "Clip features to canvas extent" on. Save this symbol as "visible centroid"
2. create a second fill symbol with a second symbol layer also set to "centroid fill". Switch the "Clip features to canvas extent" OFF. Save this symbol as "real centroid".
Try applying each symbol to a polygon layer and pan and zoom around your map. The difference should be clear. Just like the "force point inside polygon" option, it affects the placement of the centroid point. But this setting also has an effect with other symbol types, eg gradient fill, line marker with a preset distance, etc.
Harrissou - Just wanted to say that I hope there's no misunderstanding here, I love the work you are doing with filing all these usability issues. It's fantastic stuff and very much needed.
#14
Updated by Harrissou Santanna over 8 years ago
Jürgen Fischer wrote:
Harrissou Santanna wrote:
there are so many elder bug reports that are worth closing, I think.
Feel free to do so.
Giovanni Manghi wrote:
So please don't get get me wrong (when I close tickets like this one) but also leave to us the closing/reopening task.
Beyond what may be passionate words, what is the guideline about issue report closure? I use to close my own reports that are/become irrelevant but only mine. So, Am I or am I not allowed to close any report that is already fixed or seems irrelevant?
Nyall Dawson wrote:
Harrissou - Just wanted to say that I hope there's no misunderstanding here, I love the work you are doing with filing all these usability issues. It's fantastic stuff and very much needed.
Thanks Nyall. No there's no problem, no misunderstanding nor a personal matter. we're just discussing to see how we can improve what is our common project.
When i'm fed up with contributing to QGIS or feel that my contributions are more problematic than a part of solution, then I'll retire :) . But until that moment, like most folks around here, I will try to improve the project at my low level (issue report, translation and documentation) in the respect of our code of conduct. let's focus on the project.
#15
Updated by Giovanni Manghi over 8 years ago
Beyond what may be passionate words, what is the guideline about issue report closure? I use to close my own reports that are/become irrelevant but only mine. So, Am I or am I not allowed to close any report that is already fixed or seems irrelevant?
I don't we are very strict in that (if you have the permissions to do so), in fact if you test/check a ticket and find that is obsolete, invalid, etc. please feel free to close it (and of course any help in this sense is much appreciated).
#16
Updated by Harrissou Santanna over 8 years ago
Got it.
#17
Updated by Jürgen Fischer over 8 years ago
Harrissou Santanna wrote:
Beyond what may be passionate words, what is the guideline about issue report closure? I use to close my own reports that are/become irrelevant but only mine. So, Am I or am I not allowed to close any report that is already fixed or seems irrelevant?
Hey, we're just trying to keep the number of useless tickets low. The relevant tickets get burried in them. So if a ticket needs feedback to become useful and that feedback doesn't arrive in a reasonable time frame, we close it. Same for tickets that were already fixed (if possible with a reference to a commit). "We" includes you ;)
I guess most of the time when a ticket that shouldn't have been gets closed, it's just because there are so many "bad" tickets, that one "good" one can easily slip through and no evidence for "unfair" intentions.