[Qgis-developer] should core plugins not be available in plugin manager?
Nathan Woodrow
madmanwoo at gmail.com
Mon Dec 12 14:48:10 PST 2016
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.
- 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20161213/9dfc8253/attachment.html>
More information about the Qgis-developer
mailing list