<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <font size="-1"><font face="Verdana">Dear all,<br>
        <br>
        Indeed, the layer search offers something Quickfinder doesn't:
        searching on all layers without any configuration, and the use
        of operators.<br>
        Although I think choosing an operator in a global search is not
        very required (why doing price < 1000 on all layers, there is
        a pretty good chance you know what layer you're looking for).<br>
        <br>
        From this, I think Michael's idea is pretty good. <br>
        Make QuickFinder just a search bar in the application toolbar.
        Then you can register any search process to it, which would be a
        processing alg: might be OSM, FTS or Layer search.<br>
        <br>
        I would definitely be ok to do so for QuickFinder.<br>
        But the question is when... It would take me a bit of time to
        reorganize the plugin, make FTS generation and search as
        processing algs (never done that before). I won't be able to
        achieve this before August.<br>
        <br>
        So...is this fair to ask someone to wait that long for a dev and
        then ask to modify its code to fit in? I have no answer, it's a
        real question.<br>
        <br>
        <br>
        Best wishes,<br>
        Denis<br>
        <br>
        <br>
        PS: yes, QuickFinder FTS search handles multiple columns as it
        supports expressions (you can concatenate the columns).<br>
        <br>
        <br>
        <br>
        <br>
        <br>
        <br>
      </font></font><br>
    <div class="moz-cite-prefix">On 06/07/2016 03:27 PM, kimaidou wrote:<br>
    </div>
    <blockquote
cite="mid:CAMKXKO4bw=-ZBLqF928jp=p7S6mWu9N25pcjM3GT79Mfyg3JLQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_default" style="font-size:large">Hi all,<br>
          <br>
        </div>
        <div class="gmail_default" style="font-size:large">I think it is
          not really profitable to have multiple plugins. In my opinion,
          efforts must be made to merge plugins when possible. In this
          case, we have<br>
          <br>
        </div>
        <div class="gmail_default" style="font-size:large">* Quick
          Finder : Full Text Search is used here, which allows fuzzy
          search, and is very efficient compared to scanning all
          features for a match. A drawback, you must fill in the "FTS
          vectors" for each layer you want to be able to search within.
          I think it is not so bad because the process is fast. I also
          think there is nothing preventing to add more than one field
          in the search ( it is possible with FTS in PostgreSQL, must
          also be the case with sqlite)<br>
          <br>
        </div>
        <div class="gmail_default" style="font-size:large">* Layer
          search : Great to have a quick way to search among all the
          fields of all loaded layers, with no configuration. Drawback :
          I think this can be very slow for big datasets, and it is not
          "fuzzy", as regexp are used while iterating on each feature.
          Another drawback : for external vector sources like
          PostgreSQL, all features must been fetched !<br>
          <br>
        </div>
        <div class="gmail_default" style="font-size:large">IMHO, the way
          to go could be<br>
          <br>
        </div>
        <div class="gmail_default" style="font-size:large">* Add the FTS
          pregenerator of Quick Finder in Processing, as an alg
          available for anyone to use<br>
        </div>
        <div class="gmail_default" style="font-size:large">* Add the FTS
          search of Quick Finder as a Processing Alg<br>
        </div>
        <div class="gmail_default" style="font-size:large">* Add the
          "layer search" worker as an Alg in Processing<br>
        </div>
        <div class="gmail_default" style="font-size:large">* Have a
          combined plugin which let the user choose the search type :
          FTS with pregeneration, or direct search with features
          iteration. This will then run the corresponding alg<br>
          <br>
        </div>
        <div class="gmail_default" style="font-size:large">Cheers,<br>
        </div>
        <div class="gmail_default" style="font-size:large">Michaël<br>
        </div>
      </div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">2016-06-07 7:16 GMT+02:00 Jeremy Palmer
          <span dir="ltr"><<a moz-do-not-send="true"
              href="mailto:JPalmer@linz.govt.nz" target="_blank">JPalmer@linz.govt.nz</a>></span>:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex"><span
              class=""><br>
              ><br>
              > I would personally prefer keeping it as a separate
              plugin, but what do you<br>
              > think? Should it be integrated with another plugin?<br>
              ><br>
              <br>
            </span>It seems like it has value over the other plugins.
            Another issue I’ve had is searching all layer fields and
            pushing the query filter down the provider (e.g PostGIS or
            WFS) to increase the performance and usability. Using the
            approach of iterating through all features client side with
            a large dataset can be a killer in terms of bandwidth,
            memory and time. Does your new plugin do that? If so then it
            would be really useful :)<br>
            <br>
            <br>
            <br>
            This message contains information, which may be in
            confidence and may be subject to legal privilege. If you are
            not the intended recipient, you must not peruse, use,
            disseminate, distribute or copy this message. If you have
            received this message in error, please notify us immediately
            (Phone 0800 665 463 or <a moz-do-not-send="true"
              href="mailto:info@linz.govt.nz">info@linz.govt.nz</a>) and
            destroy the original message. LINZ accepts no responsibility
            for changes to this email, or for any attachments, after its
            transmission from LINZ. Thank You.<br>
            <div class="HOEnZb">
              <div class="h5">_______________________________________________<br>
                Qgis-developer mailing list<br>
                <a moz-do-not-send="true"
                  href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
                List info: <a moz-do-not-send="true"
                  href="http://lists.osgeo.org/mailman/listinfo/qgis-developer"
                  rel="noreferrer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
                Unsubscribe: <a moz-do-not-send="true"
                  href="http://lists.osgeo.org/mailman/listinfo/qgis-developer"
                  rel="noreferrer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a></div>
            </div>
          </blockquote>
        </div>
        <br>
      </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>
List info: <a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/qgis-developer">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a>
Unsubscribe: <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>