<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>