Ok - thanks for clarifying.
What's the difference between a core C++ plugin and a C++ plugin?
Is the only difference that the core plugins are shipped and enabled by
default?
Andreas
On 13.12.2016 08:09, Nathan Woodrow wrote:
To be clear this isn't removing the ability to have C++ plugins, just
having core plugins and making them optional.
- Nathan
On Tue, Dec 13, 2016 at 5:08 PM, Neumann, Andreas <a.neum...@carto.net
<mailto:a.neum...@carto.net>> wrote:
Hi,
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.
There may be usages of QGIS out there that rely on the ability to
have C++ plugins that we are not aware of.
---------------
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.
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.
Andreas
On 2016-12-12 20:57, DelazJ wrote:
Hi,
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.
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.
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).
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.
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. :)
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.
Regards,
Harrissou
2016-12-12 16:01 GMT+01:00 Martin Dobias <wonder...@gmail.com
<mailto:wonder...@gmail.com>>:
Hi Victor
On Mon, Dec 12, 2016 at 7:05 PM, Victor Olaya
<vola...@gmail.com <mailto:vola...@gmail.com>> wrote:
> Hi
>
> This has been discussed in the past, but i think no
decision was
> taken, so I want to bring back the discussion.
>
> I think that core plugins should not be visible in the
plugin manager,
> and users should not be able to disable them. If they are
core, they
> should be active (the menus and buttons can be removed with the
> "View/Customization..." functionality if the user wants to)
Agreed that Processing should be always on. Also, IMO it
should be
available as "qgis.processing" python module.
Cheers
Martin
_______________________________________________
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
<mailto:Qgis-developer@lists.osgeo.org>
List info:
http://lists.osgeo.org/mailman/listinfo/qgis-developer
<http://lists.osgeo.org/mailman/listinfo/qgis-developer>
Unsubscribe:
http://lists.osgeo.org/mailman/listinfo/qgis-developer
<http://lists.osgeo.org/mailman/listinfo/qgis-developer>
_______________________________________________
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
<mailto:Qgis-developer@lists.osgeo.org>
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
<http://lists.osgeo.org/mailman/listinfo/qgis-developer>
Unsubscribe:
http://lists.osgeo.org/mailman/listinfo/qgis-developer
<http://lists.osgeo.org/mailman/listinfo/qgis-developer>
_______________________________________________
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org <mailto:Qgis-developer@lists.osgeo.org>
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
<http://lists.osgeo.org/mailman/listinfo/qgis-developer>
Unsubscribe:
http://lists.osgeo.org/mailman/listinfo/qgis-developer
<http://lists.osgeo.org/mailman/listinfo/qgis-developer>
_______________________________________________
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
