A core plugin can be python as well. 
Ciao

On 13 December 2016 08:14:46 CET, Andreas Neumann <a.neum...@carto.net> wrote:
>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

-- 
Marco Bernasocchi (mobile).
OPENGIS.ch - berna.io - 27summits.ch
_______________________________________________
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

Reply via email to