On 13 December 2016 at 08:48, Nathan Woodrow <madman...@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.daw...@gmail.com> > wrote: >> >> On 12 December 2016 at 21:14, Nathan Woodrow <madman...@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 <vola...@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@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@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@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer