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 <[email protected]> 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 <[email protected]>: > >> Hi Victor >> >> On Mon, Dec 12, 2016 at 7:05 PM, Victor Olaya <[email protected]> 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 >> [email protected] >> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer >> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer >> > > _______________________________________________ > Qgis-developer mailing list > [email protected] > List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer > > > > > _______________________________________________ > Qgis-developer mailing list > [email protected] > List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer >
_______________________________________________ Qgis-developer mailing list [email protected] List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
