Feature request #12879
isSelected operator to define expression baswesd style on selection
Status: | Closed | ||
---|---|---|---|
Priority: | Normal | ||
Assignee: | - | ||
Category: | Expressions | ||
Pull Request or Patch supplied: | No | Resolution: | fixed/implemented |
Easy fix?: | No | Copied to github as #: | 20970 |
Description
The main reason is to have a "smart" visualization of selected feature is in case of:
- they are too crowded
- if would be necessary to have a special style for selected feature (e.g. highlight the selected and blur the others)
In this moment styling of selected feature is:
1) limited to color and transparency setting
2) can be styled adding custom function that retrieve if the feature is selected
the solution 1, obviously, does not satisfy requirement
the solution 2 has two drawback:
A) the custom function have to know the layer id (blocked in the expression) to get selected features and check if the curent feature is selected or not
B) the loop described in A is really time consuming with a large amount of features
during Nodebo Andreas and Nyall confirmed that there is no other way to style selected features
How to solve technically:
I asked to Martin if were possible to add some kind of "contextual" operator that allow the feature knows at what layer it belongs to (and something more)... Martin said that, going up to the layer data (not thread safe), could introduce problems during MT rendering.
He point out that "is selected" state of the feature is already available to the feature, and it should only be published.
He suggested to ask to Nyall to integrate this feature because he is was working on styling in that moment (for 2.10)
Nyall pointed out that this feature can be added after 2.10 because we were too near feature freeze, so it could be added for 2.12 and 2.11 dev version for testing.
this is the state of the art. regarding a sophisticated way to style selected features
History
#1 Updated by Matthias Kuhn over 9 years ago
Nice feature request!
I wonder however if there is any performance benefit for adding a selected property to the feature. On the one hand I think that looking up a feature id in a QSet of feature ids is very fast. Possible performance problems would need to be proven first. On the other hand I don't see a way around a lookup anyway, if it's not done in the expression, it will be done in the layer iterator (get feature from provider -> set selected property). However if it is done in the layer iterator it will also be done when the property is not required.
So IMO, best to (shallow) copy the set of selected feature ids to the expression context and do the check in an expression function.
#2 Updated by Matthias Kuhn over 9 years ago
And a note for people stumbling upon this report and looking for a workaround: Get the https://github.com/NathanW2/qgsexpressionsplus plugin and use the isselected method for the moment.
#3 Updated by Nyall Dawson about 9 years ago
- Assignee deleted (
Nyall Dawson)
#4 Updated by Giovanni Manghi over 7 years ago
- Easy fix? set to No
#5 Updated by Nyall Dawson almost 6 years ago
- Resolution set to fixed/implemented
- Description updated (diff)
- Status changed from Open to Closed
Implemented in 3.2? 3.0? Anyway, it's in 3.4