<div dir="ltr">Yeah I do agree with this point.  Remove what isn't needed first then make the rest always on, or even better just<div>remove the whole core plugin concept completely as it doesn't make sense IMO.</div><div><br></div><div>- Nathan</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 13, 2016 at 8:24 AM, Nyall Dawson <span dir="ltr"><<a href="mailto:nyall.dawson@gmail.com" target="_blank">nyall.dawson@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 12 December 2016 at 21:14, Nathan Woodrow <<a href="mailto:madmanwoo@gmail.com">madmanwoo@gmail.com</a>> wrote:<br>
> +++++1<br>
><br>
> Yes please. if it's core (plugin or not) it shouldn't be optional and should<br>
> be enabled always.<br>
> It's just confusing for people and honestly doesn't feel right having core<br>
> parts disabled/enabled, imagine if<br>
> the style dock or atlas stuff, etc was optional. Messy and confusing.<br>
><br>
> The other issue is when some of us don't run with all core plugins enabled<br>
> all the time it's hard to judge the<br>
> full state of things as a complete package e.g I see tons of screenshots<br>
> with the shortest path<br>
> plugin enabled and taking half the dock space when I bet most people would<br>
> never use it.<br>
><br>
> So a massive +1 from me on this one.<br>
<br>
</span>I'm a +1 / -1 on this!<br>
<br>
To explain: I'm +1 on processing being removed from the list and being<br>
made always-on. Processing is an integral part of QGIS now and I see<br>
no reason why anyone should want to run QGIS without processing.<br>
<br>
I'm a strong -1 on making all core plugins enabled and mandatory. My<br>
reasoning here is that the current batch of core plugins is a random<br>
mix of stuff of varying value and usefulness. Historically a lot of<br>
them are just there because they were introduced before the current<br>
python/plugin infrastructure was in place and no one has removed them<br>
yet. I see absolutely no value in making plugins like "oracle raster",<br>
"evis", or "gps tools" manadatory, and lots of reasons why they should<br>
not be (ui clutter, no-one maintaining these plugins or addressing<br>
bugs in them). Even a useful plugin like "coordinate capture" adds a<br>
lot of UI clutter and should not be mandatory.<br>
<br>
There's also the issue that we have core plugins with overlapping<br>
functionality (geometry checker vs topology checker).<br>
<br>
I think in future we could re-asses this, but right now we need to<br>
first focus on cleaning up, consolidating and purging the existing<br>
plugins (see <a href="https://github.com/qgis/qgis3.0_api/issues/67" rel="noreferrer" target="_blank">https://github.com/qgis/qgis3.<wbr>0_api/issues/67</a>). Then we<br>
should evaluate whether the remaining core plugins should be ported to<br>
python and moved from the core repo to instead exist as separate<br>
standard plugins.<br>
<span class="HOEnZb"><font color="#888888"><br>
Nyall<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
><br>
> - Nathan<br>
><br>
><br>
> On Mon, Dec 12, 2016 at 9:05 PM, Victor Olaya <<a href="mailto:volayaf@gmail.com">volayaf@gmail.com</a>> wrote:<br>
>><br>
>> Hi<br>
>><br>
>> This has been discussed in the past, but i think no decision was<br>
>> taken, so I want to bring back the discussion.<br>
>><br>
>> I think that core plugins should not be visible in the plugin manager,<br>
>> and users should not be able to disable them. If they are core, they<br>
>> should be active (the menus and buttons can be removed with the<br>
>> "View/Customization..." functionality if the user wants to)<br>
>><br>
>> Since we removed the ftools plugin and now have the corresponding<br>
>> functionality from Processing, some users are confused for not finding<br>
>> the usual tools there. We have kept the same menus, for those that are<br>
>> used to them and dont want to use the toolbox. However, if users do<br>
>> not have Processing enabled, they won't see those menus. And it is not<br>
>> obvious that they have to enable Processing to get something that<br>
>> previously was a different plugin..<br>
>><br>
>> I think this is an interesting discussion, so if you have ideas or<br>
>> think that this might have disadvantages, let's talk about it in here.<br>
>><br>
>><br>
>> Thanks!<br>
>> ______________________________<wbr>_________________<br>
>> Qgis-developer mailing list<br>
>> <a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
>> List info: <a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">http://lists.osgeo.org/<wbr>mailman/listinfo/qgis-<wbr>developer</a><br>
>> Unsubscribe: <a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">http://lists.osgeo.org/<wbr>mailman/listinfo/qgis-<wbr>developer</a><br>
><br>
><br>
><br>
> ______________________________<wbr>_________________<br>
> Qgis-developer mailing list<br>
> <a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
> List info: <a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">http://lists.osgeo.org/<wbr>mailman/listinfo/qgis-<wbr>developer</a><br>
> Unsubscribe: <a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">http://lists.osgeo.org/<wbr>mailman/listinfo/qgis-<wbr>developer</a><br>
</div></div></blockquote></div><br></div>