[Qgis-developer] should core plugins not be available in plugin manager?
Nathan Woodrow
madmanwoo at gmail.com
Mon Dec 12 23:09:36 PST 2016
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>
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>:
>
>> Hi Victor
>>
>> On Mon, Dec 12, 2016 at 7:05 PM, Victor Olaya <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
>> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
>
>
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: 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/4d5a8751/attachment-0001.html>
More information about the Qgis-developer
mailing list