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

Nyall Dawson nyall.dawson at gmail.com
Mon Dec 12 14:24:15 PST 2016


On 12 December 2016 at 21:14, Nathan Woodrow <madmanwoo at gmail.com> wrote:
> +++++1
>
> Yes please. if it's core (plugin or not) it shouldn't be optional and should
> be enabled always.
> It's just confusing for people and honestly doesn't feel right having core
> parts disabled/enabled, imagine if
> the style dock or atlas stuff, etc was optional. Messy and confusing.
>
> The other issue is when some of us don't run with all core plugins enabled
> all the time it's hard to judge the
> full state of things as a complete package e.g I see tons of screenshots
> with the shortest path
> plugin enabled and taking half the dock space when I bet most people would
> never use it.
>
> So a massive +1 from me on this one.

I'm a +1 / -1 on this!

To explain: I'm +1 on processing being removed from the list and being
made always-on. Processing is an integral part of QGIS now and I see
no reason why anyone should want to run QGIS without processing.

I'm a strong -1 on making all core plugins enabled and mandatory. My
reasoning here is that the current batch of core plugins is a random
mix of stuff of varying value and usefulness. Historically a lot of
them are just there because they were introduced before the current
python/plugin infrastructure was in place and no one has removed them
yet. I see absolutely no value in making plugins like "oracle raster",
"evis", or "gps tools" manadatory, and lots of reasons why they should
not be (ui clutter, no-one maintaining these plugins or addressing
bugs in them). Even a useful plugin like "coordinate capture" adds a
lot of UI clutter and should not be mandatory.

There's also the issue that we have core plugins with overlapping
functionality (geometry checker vs topology checker).

I think in future we could re-asses this, but right now we need to
first focus on cleaning up, consolidating and purging the existing
plugins (see https://github.com/qgis/qgis3.0_api/issues/67). Then we
should evaluate whether the remaining core plugins should be ported to
python and moved from the core repo to instead exist as separate
standard plugins.

Nyall


>
> - Nathan
>
>
> On Mon, Dec 12, 2016 at 9: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)
>>
>> Since we removed the ftools plugin and now have the corresponding
>> functionality from Processing, some users are confused for not finding
>> the usual tools there. We have kept the same menus, for those that are
>> used to them and dont want to use the toolbox. However, if users do
>> not have Processing enabled, they won't see those menus. And it is not
>> obvious that they have to enable Processing to get something that
>> previously was a different plugin..
>>
>> I think this is an interesting discussion, so if you have ideas or
>> think that this might have disadvantages, let's talk about it in here.
>>
>>
>> Thanks!
>> _______________________________________________
>> 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


More information about the Qgis-developer mailing list