<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">27.2.2014 22:10, Artem Marchenko:<br>
    </div>
    <blockquote
cite="mid:CAH3UTb4BB5QkdSZrJ=1wC6z8wOhD1+oaUzKg14-5rwNp2EnS8A@mail.gmail.com"
      type="cite">
      <div dir="ltr">Hi all
        <div><br>
        </div>
        <div>As you know harbour rules regarding custom libraries and
          QML modules require two things:</div>
        <div>1. Load everything from your app folder</div>
        <div>2. In your QML import stuff as "import
          harbour.mycoolapp.desiredmodule"</div>
        <div><br>
        </div>
        <div>Rule 1 makes sense for limiting dependency on the system,
          but rule 2.. Following it needs that at the very least you
          need modify the plugin's qmldir, often you also have to change
          the source code of the plugin you use (e.g. some nemomobile
          plugins have ASSERTs for the folder).</div>
        <div><br>
        </div>
        <div>That is not nice and doesn't serve any purpose except for
          warning you. Also it is easily gameable by just packaging all
          QMLs into a QRC resource that harbour check script won't
          parse. That will kill the useful warnings too though..</div>
        <div><br>
        </div>
        <div><b>*Proposal*</b></div>
        <div>- So lets mandate only what is actually needed: reading
          libraries from own folder only. Traceable e.g. by strace</div>
        <div>- Let's not mandate the source code to use particular
          import form</div>
        <div>  - You can still keep the warning as information for the
          developer and alert for the Harbour tester to check that this
          or that plugin is loaded exactly from app folders, but it
          shouldn't fail the validation.</div>
      </div>
    </blockquote>
    +1 from me on this!<br>
    <br>
    BTW, I'll just add another usecase - QML only modules. You might not
    want to use absolute paths in every QML file using a set of
    components (import "../my-shiny-module"), so you make it to a proper
    module with qmldir and everything and add the folder it is in to QML
    import path. Voila, you can just use "import shiny 1.0", looks
    better, can't brek when moving QML files in folder hierarchy, etc.
    Under current rules, every such _plain QML_ module would need to
    have the harbour prefix hardcoded in - which is IMHO pretty useless
    and rather stupid.<br>
    <blockquote
cite="mid:CAH3UTb4BB5QkdSZrJ=1wC6z8wOhD1+oaUzKg14-5rwNp2EnS8A@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div><br>
        </div>
        <div>What do you think?</div>
        <div><br>
        </div>
        <div>Best regards,</div>
        <div>Artem.<br clear="all">
          <div><br>
          </div>
          -- <br>
          Artem Marchenko<br>
          <a moz-do-not-send="true"
            href="http://agilesoftwaredevelopment.com" target="_blank">http://agilesoftwaredevelopment.com</a><br>
          <a moz-do-not-send="true" href="http://twitter.com/AgileArtem"
            target="_blank">http://twitter.com/AgileArtem</a>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
SailfishOS.org Devel mailing list</pre>
    </blockquote>
    <br>
  </body>
</html>