<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi Olivier,<br>
    <br>
    I always thought it was a good idea, and you did a nice overview.<br>
    That would be a big +1 for, me, mainly because there is a big
    redundancy between these two features.<br>
    <br>
    Also, I think that the identify modes should be cleaned up.<br>
    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.<br>
    I wonder if we should not keep this one only.<br>
    <br>
    Thanks for bringing this up!<br>
    <br>
    Denis<br>
    <br>
    <div class="moz-cite-prefix">On 03. 04. 14 00:17, Olivier Dalang
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAExk7p3J-9Ji2ZMbFjoUAvcO9iZbWzpvc1hbUgEaeB-gMQyLNg@mail.gmail.com"
      type="cite">
      <div dir="ltr">Hi !<br>
        <br>
        The discussions about this issue <a moz-do-not-send="true"
          href="http://hub.qgis.org/issues/9907">http://hub.qgis.org/issues/9907</a>
        raised the question (at least for me) of merging the concepts of
        Identified features and Selected features.
        <div>
          <br>
        </div>
        <div>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)...<br>
          <br>
          In short, the idea would be to have both identified features
          and selected features be exactly the same thing.
          <div>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).<br>
            The identify tool could then also work in
            "single","rectangle","polygon" etc modes.
            <div><br>
            </div>
            <div><br>
              Rationale FOR:</div>
            <div><br>
              <div><span style="font-weight:bold">1. There is already a
                  feature overlap</span></div>
              <div><br>
              </div>
              <div>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.</div>
              <div>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).</div>
              <div><br>
              </div>
              <div><b>2. The attribute table in form mode is actually
                  great</b></div>
              <div><b><br>
                </b></div>
              <div>
                <div>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.</div>
                <div>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.</div>
              </div>
              <div><br>
              </div>
              <div><b>3. Both functions are very similar in how they
                  work and look</b></div>
              <div><br>
              </div>
              <div>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.</div>
              <div><br>
              </div>
              <div><b>4. Having the attribute table in form mode for
                  editing is promising for the future</b></div>
              <div><b><br>
                </b></div>
              <div>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).</div>
              <div><br>
              </div>
              <div><br>
              </div>
              <div><br>
              </div>
              <div>Rationale AGAINST (and of course counterarguments) :</div>
              <div><br>
              </div>
              <div><b>1. Identification is not the same than selection</b></div>
              <div>Users sometimes want to work on a selection, while
                still being able to identify features.</div>
              <div>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).</div>
              <div><b><br>
                </b></div>
              <div><b>2. Identification would stop working across
                  several layers (top-down mode)</b></div>
              <div>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.</div>
              <div>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)</div>
              <div><br>
              </div>
              <div>I guess I missed some uses of the "identify results"
                window ?<br>
              </div>
              <div><br>
              </div>
              <div><br>
              </div>
              <div>What do you think ?</div>
              <div><br>
              </div>
              <div><br>
              </div>
              <div>Best regards,</div>
              <div>
                <br>
              </div>
              <div>Olivier</div>
              <div><br>
              </div>
            </div>
          </div>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Qgis-developer mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/qgis-developer">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a></pre>
    </blockquote>
    <br>
  </body>
</html>