<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>Ok - thanks for clarifying.</p>
    <p>What's the difference between a core C++ plugin and a C++ plugin?</p>
    Is the only difference that the core plugins are shipped and enabled
    by default?<br>
    <br>
    Andreas<br>
    <br>
    <div class="moz-cite-prefix">On 13.12.2016 08:09, Nathan Woodrow
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAAi8Yg91fQYtrzPh==0O=jkPV=8SYB1Fe=Q7hsG0zk_C_q8jrg@mail.gmail.com"
      type="cite">
      <div dir="ltr">To be clear this isn't removing the ability to have
        C++ plugins, just having core plugins and making them optional.
        <div><br>
        </div>
        <div>- Nathan</div>
      </div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On Tue, Dec 13, 2016 at 5:08 PM,
          Neumann, Andreas <span dir="ltr"><<a
              moz-do-not-send="true" href="mailto:a.neumann@carto.net"
              target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:a.neumann@carto.net">a.neumann@carto.net</a></a>></span> wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div
              style="font-size:10pt;font-family:Verdana,Geneva,sans-serif">
              <p>Hi,</p>
              <p>Before we remove the ability to have C++ plugins, or
                the ability to enable/disable them, we should first
                inform our users and developers and ask them if we are
                fine with what we propose.</p>
              <p>There may be usages of QGIS out there that rely on the
                ability to have C++ plugins that we are not aware of.</p>
              <p>---------------</p>
              <p>I do agree though that some core plugins could be
                removed or integrated into the core. One example is the
                coordinate capture plugin, which could be easily
                integrated in core, e.g. integrated in the identify tool
                or status bar.</p>
              <p>Probably the EVIS plugin is another candidate with lots
                of overlaps. If we add the missing functionality the
                EVIS plugin provides to core, we could get rid of it.</p>
              <span class="HOEnZb"><font color="#888888">
                  <p>Andreas</p>
                </font></span>
              <div>
                <div class="h5">
                  <p>On 2016-12-12 20:57, DelazJ wrote:</p>
                  <blockquote type="cite" style="padding:0
                    0.4em;border-left:#1010ff 2px solid;margin:0">
                    <div dir="ltr">
                      <div>
                        <div>
                          <div>
                            <div>
                              <div>
                                <div>Hi,</div>
                                I do not fully share the agreement on
                                having core plugins not deactivable. Are
                                Core plugins the problem or is it
                                Processing? Let's not wrongly mix
                                issues.<br>
                                <br>
                                I'd always thought that Core plugins
                                meant plugins developed, managed,
                                updated by the QGIS project itself,
                                provided by default with installation.
                                It doesn't mean that everybody wants to
                                use it or needs it. The Road Graph is a
                                plugin I had never executed in 5 years
                                I'm using QGIS. Many others (GPS Tools,
                                Heatmap, rasters related plugins...) are
                                concerned. Why would I want it activated
                                by default and crowd the GUI? Then I'd
                                have to struggle and change some somehow
                                hidden customization option to have it
                                disabled? Uncheck it in Plugin Manager
                                sounds far simpler.<br>
                                <br>
                              </div>
                              What puzzled many users (and might still
                              do) with Processing in QGIS >=2.16 is
                              to have removed fTools and not activate
                              Processing by default for those that were
                              using fTools. They should be provided a
                              transparent replacement of fTools
                              (including the removal of this one from
                              the list). <br>
                              And maybe communication about this change
                              is not clear for all people. Currently,
                              fTools state is broken but there's no
                              message to tell you that you should
                              instead activate Processing to get back
                              your lovely functions.<br>
                              <br>
                            </div>
                            So, from me, no, Core plugins should stay
                            (de)activable even though looking at all the
                            list of Core plugins being integrated in
                            Processing in 3.0 I wonder how many Core
                            plugins will stay (DB Manager and
                            Processing?) when 3.0 lands. :)<br>
                            <br>
                          </div>
                          Also, one of the power of QGIS imho is its
                          modularity: you pick what you need. We should
                          not put all in one. And having Core plugins
                          being listed there gives some kind of
                          confidence to contributors to follow the path
                          (create plugins). I'm not sure i well
                          expressed what I meant to.<br>
                          <br>
                          <br>
                        </div>
                        Regards,</div>
                      Harrissou<br>
                      <div>
                        <div><br>
                          <br>
                        </div>
                      </div>
                    </div>
                    <div class="gmail_extra"><br>
                      <div class="gmail_quote">2016-12-12 16:01
                        GMT+01:00 Martin Dobias <span><<a
                            moz-do-not-send="true"
                            href="mailto:wonder.sk@gmail.com"
                            target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:wonder.sk@gmail.com">wonder.sk@gmail.com</a></a>></span>:<br>
                        <blockquote class="gmail_quote" style="margin:0
                          0 0 .8ex;border-left:1px #ccc
                          solid;padding-left:1ex">Hi Victor<br>
                          <span><br>
                            On Mon, Dec 12, 2016 at 7:05 PM, Victor
                            Olaya <<a moz-do-not-send="true"
                              href="mailto:volayaf@gmail.com"
                              target="_blank">volayaf@gmail.com</a>>
                            wrote:<br>
                            > Hi<br>
                            ><br>
                            > This has been discussed in the past,
                            but i think no decision was<br>
                            > taken, so I want to bring back the
                            discussion.<br>
                            ><br>
                            > I think that core plugins should not be
                            visible in the plugin manager,<br>
                            > and users should not be able to disable
                            them. If they are core, they<br>
                            > should be active (the menus and buttons
                            can be removed with the<br>
                            > "View/Customization..." functionality
                            if the user wants to)<br>
                            <br>
                          </span>Agreed that Processing should be always
                          on. Also, IMO it should be<br>
                          available as "qgis.processing" python module.<br>
                          <br>
                          Cheers<br>
                          <span class="m_6925049117748635319HOEnZb"><span
                              style="color:#888888">Martin<br>
                            </span></span>
                          <div class="m_6925049117748635319HOEnZb">
                            <div class="m_6925049117748635319h5">______________________________<wbr>_________________<br>
                              Qgis-developer mailing list<br>
                              <a moz-do-not-send="true"
                                href="mailto:Qgis-developer@lists.osgeo.org"
                                target="_blank">Qgis-developer@lists.osgeo.org</a><br>
                              List info: <a moz-do-not-send="true"
                                href="http://lists.osgeo.org/mailman/listinfo/qgis-developer"
                                target="_blank">http://lists.osgeo.org/mailman<wbr>/listinfo/qgis-developer</a><br>
                              Unsubscribe: <a moz-do-not-send="true"
                                href="http://lists.osgeo.org/mailman/listinfo/qgis-developer"
                                target="_blank">http://lists.osgeo.org/mailman<wbr>/listinfo/qgis-developer</a></div>
                          </div>
                        </blockquote>
                      </div>
                    </div>
                    <br>
                    <div class="m_6925049117748635319pre"
                      style="margin:0;padding:0;font-family:monospace">______________________________<wbr>_________________<br>
                      Qgis-developer mailing list<br>
                      <a moz-do-not-send="true"
                        href="mailto:Qgis-developer@lists.osgeo.org"
                        target="_blank">Qgis-developer@lists.osgeo.org</a><br>
                      List info: <a moz-do-not-send="true"
                        href="http://lists.osgeo.org/mailman/listinfo/qgis-developer"
                        target="_blank">http://lists.osgeo.org/<wbr>mailman/listinfo/qgis-<wbr>developer</a><br>
                      Unsubscribe: <a moz-do-not-send="true"
                        href="http://lists.osgeo.org/mailman/listinfo/qgis-developer"
                        target="_blank">http://lists.osgeo.org/<wbr>mailman/listinfo/qgis-<wbr>developer</a></div>
                  </blockquote>
                  <p> </p>
                  <div> </div>
                </div>
              </div>
            </div>
            <br>
            ______________________________<wbr>_________________<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/<wbr>mailman/listinfo/qgis-<wbr>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/<wbr>mailman/listinfo/qgis-<wbr>developer</a><br>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
  </body>
</html>