[Qgis-developer] should core plugins not be available in plugin manager?

[Andreas Neumann]

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.neumann at carto.net 
> <mailto:a.neumann at 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.sk at gmail.com
>>     <mailto:wonder.sk at gmail.com>>:
>>
>>         Hi Victor
>>
>>         On Mon, Dec 12, 2016 at 7:05 PM, Victor Olaya
>>         <volayaf at gmail.com <mailto:volayaf at 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 at lists.osgeo.org
>>         <mailto:Qgis-developer at 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 at lists.osgeo.org
>>     <mailto:Qgis-developer at 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 at lists.osgeo.org <mailto:Qgis-developer at 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>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20161213/d1edbf37/attachment.html>