[Qgis-developer] Identified features vs. Selected features : could we merge those ?

Olivier Dalang olivier.dalang at gmail.com
Thu Apr 3 02:53:20 PDT 2014


Hi !

Thanks for your reactions !
Below is an updated suggestion, which tries to keep the spirit of separated
identified features and selected features concepts, while still providing
some usage improvements.


One thing I'm not at ease with is the point about "not changing the
ergonomics".
I mean, if we find out a better/more simple way to do something, we have to
do it. The fact that users are used to an old unpractical way is no good
reason for not doing it. Because if it was, we'd be stuck in improving QGIS.
It's a matter of minutes to get used to this type of changes, and if a user
really doesn't accept change at all, he's still free to stick to his
current version.
I find it better to think of new users when thinking about the UI, because
it helps going for the most simple and logical implementations. Plus, I
guess in the case of QGIS, it's more of a challenge to attract new users
than to keep the old ones.
That doesn't justify change for the sake change, but we are talking about
improvements (even if small), not just changes.


*Identify features window*

*Régis:*

>
> *I agree identify window needs some improvements, but I think this is a
> mandatory feature*


Can you develop on this ?
The only feature I see is that it displays those "derived" information
(currently area&perimeter) which can't be found easily otherwise. But:
- Is it the best way to show them ? When having "show form if only one
feature is identified", you can't show them on one feature anymore.
- It's still several (hard) clicks to display that information.
- Wouldn't map tooltips be better ? Maybe we could have those info display
by default as tootips on vector layers ?
- What if I'm interested in other "derived" information (centroid...) or if
I want to customize those (number formatting...) ?

The other features (discriminating one layer from multiple identify
results) is done much better by that "select layer" mode.
In case of overlapping features (in a same layer), we could have the same
dropdown menu (or submenu, in case we have overlapping features in the same
layer + overlapping layers) to choose which feature you want to identify.
Exactly the same implementation would be perfect for the "action" tool.

This would actually be enough to replace the "identify results" window. The
real time visual feedback on what's going to be identified is great, and a
contextual (sub-)menu is much more friendly than a tree.
Having each time only one feature identified, it would always open the
feature's form, and never open the "identify results" window. I'd be very
happy with that !!


*Identify multiple features*

I still find the idea of being able to open the attribute table in form
mode for several features great.
Maybe for this, we could have subtools (under the identify tool) called
"Identify by selection", "Identify by rectangle selection", "Identify by
polygon selection", ... which would work as said, i.e. exactly like the
selection tool except that they open the attribute table in form mode.
This would make it clear that it's actually going to define a selection,
and make the attribute table in form mode much more accessible.

So we get the best of the two worlds : ability to identify a feature even
if there's currently a selection, and also being able to take advantage of
the great current implementation of the attribute form mode and the
flexibility of the selection tools.

I believe this will be awesome at the point we implement modifying
attributes of several features at once.




*Alvaro:*
>
> *To avoid repainting the full content of the map when the selection
> changes (it can very heavy for big contents), I find it interesting to
> modify how the highlight of the elements is done by painting similar to how
> it does the identification tool (it uses QgsHighlight class). Basically,
> disconnec the rendered map to the selected elements to draw.*

+1, this would also deal with the problem with complex styles (for instance
an offseted transparent polygon for the shadow, where the shadow is also
highlighted)


Best,

Olivier
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20140403/44ce3ef9/attachment.html>


More information about the Qgis-developer mailing list