Feature request #12879
isSelected operator to define expression baswesd style on selection
|Pull Request or Patch supplied:||No||Resolution:||fixed/implemented|
|Easy fix?:||No||Copied to github as #:||20970|
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
#1 Updated by Matthias Kuhn about 4 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.