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

[Nyall Dawson]

On 13 December 2016 at 08:48, Nathan Woodrow <madmanwoo at gmail.com> wrote:
> Yeah I do agree with this point.  Remove what isn't needed first then make
> the rest always on, or even better just
> remove the whole core plugin concept completely as it doesn't make sense
> IMO.

I've also been thinking... maybe we should make a QEP about "no more
core plugins, no exceptions!", get it agreed upon and accepted, and
then block any future additions of core plugins.

Nyall

>
> - Nathan
>
> On Tue, Dec 13, 2016 at 8:24 AM, Nyall Dawson <nyall.dawson at gmail.com>
> wrote:
>>
>> 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
>
>