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

[Denis Rouzaud]

Hi Olivier,

I always thought it was a good idea, and you did a nice overview.
That would be a big +1 for, me, mainly because there is a big redundancy 
between these two features.

Also, I think that the identify modes should be cleaned up.
The new "layer slection" mode is very useful and does solve the problem 
of opening the right layer attributes table. I have seen many old-time 
users not aware of its existence, but when they discover it they use 
this one only.
I wonder if we should not keep this one only.

Thanks for bringing this up!

Denis

On 03. 04. 14 00:17, Olivier Dalang wrote:
> Hi !
>
> The discussions about this issue http://hub.qgis.org/issues/9907 
> raised the question (at least for me) of merging the concepts of 
> Identified features and Selected features.
>
> I don't know if it's the good moment to discuss this, but since we 
> have a few other threads talking about a bit more deep user 
> interaction changes, I thought it could be good to think of this also 
> (even if it's not urgent)...
>
> In short, the idea would be to have both identified features and 
> selected features be exactly the same thing.
> The only difference between the select tool and the identify tool 
> would then be that the identify tool opens a form window (either the 
> single feature form or the attribute table in form mode).
> The identify tool could then also work in 
> "single","rectangle","polygon" etc modes.
>
>
> Rationale FOR:
>
> 1. There is already a feature overlap
>
> When identifying one feature only, the "identify tool" can open the 
> form (provided "open feature form if a single feature is identified" 
> is checked). But when identifying several features, the way to go is a 
> selection, which dynamically refreshes the attribute table, and where 
> the features can be edited in the form mode.
> This is also a problem in the scenario of issue #9907 : to open the 
> form of overlapping features, you have to use a selection, if you 
> don't want to spend too many clicks expanding the "identify window" 
> tree, finding the right feature, and clicking on it's "open feature 
> form" button. This also has the annoying consequence of being 
> unpredicable : the effect of the tool will sometimes be opening the 
> form (when one feature gets identified), and sometimes to open that 
> "identifying results" window (when several features got identified).
>
> *2. The attribute table in form mode is actually great*
> *
> *
> The "identify results" window is not very practical: the folded tree 
> requires expanding, it does not provide a good overview of what is 
> selected, does not take editing widgets into account etc.
> Meanwhile, the form view is great (both the single feature form and 
> the multiple features form in the attribute table). It's clear, neat, 
> even allows to choose which field to use to list the selection, etc... 
> It's sad that it's a bit hidden in the UI, I find it one of the best 
> additions to the UI that has been made lately.
>
> *3. Both functions are very similar in how they work and look*
>
> Both require you to click on a feature, and have a visual feedback 
> consisting of highlighting the feature. It's very confusing for 
> beginners as it's uncommon for softwares to implement two different 
> types of selections.
>
> *4. Having the attribute table in form mode for editing is promising 
> for the future*
> *
> *
> Because we could implement edition on several feature at once 
> (currently, one needs a plugin to set an attribute on different 
> features at once, and those plugin do not yet take the field widgets 
> into account).
>
>
>
> Rationale AGAINST (and of course counterarguments) :
>
> *1. Identification is not the same than selection*
> Users sometimes want to work on a selection, while still being able to 
> identify features.
> To allow this usage, either we could offer workaround features by 
> implementing store/restore selections and/or have selections in the 
> undo stack (grouped), or we could make an exception for the "identify 
> single feature", which would not set the selection, but only open the 
> feature form (current behavior).
> *
> *
> *2. Identification would stop working across several layers (top-down 
> mode)*
> Since it is difficult to imagine having the attribute table window 
> display selections from several layers. Technically, it would be 
> doable in the form view, since it does show only one form at a time, 
> but it may be more clear simply to remove this possibility.
> However, we could keep the current behaviour when using "identify 
> single feature" though. This tool's behviour could keep the same 
> functions that currently, adding the feature #9907 and an "open 
> attribute table in form mode even if only one feature is selected" 
> option. (to be clarified)
>
> I guess I missed some uses of the "identify results" window ?
>
>
> What do you think ?
>
>
> Best regards,
>
> Olivier
>
>
>
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer

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