<div dir="ltr"><div class="gmail_extra">On Mon, Aug 12, 2013 at 5:13 PM, Marco Hugentobler <span dir="ltr"><<a href="mailto:marco.hugentobler@sourcepole.ch" target="_blank">marco.hugentobler@sourcepole.ch</a>></span> wrote:<br>


<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Plugins are a sophisticated way of keeping things lean and
      separated.</blockquote></div><div class="gmail_extra"><br></div><div class="gmail_extra">I have no issue with none core plugins, in fact that is something I always promote as a powerful feature. Core however plugins are a different story. While it makes sense to you and I it doesn't make sense to a normal user. Core plugins, while a feature, in fact make the program look incomplete or patchy.  Some of the main problems with core plugins are: they don't have a Python C++ API, functions in them are separated by wall, users have to enable them in order to use them. </div>


<div class="gmail_extra"><br></div><div class="gmail_extra">Lets take a few examples:  A question the other day on IRC was "can I create a heatmap with pyqgis" No is the answer which is confusing because the heatmap plugin is a core feature so why not have it as part of the API?  The topology checker is another example of the features it has should be part of the core package and just baked in. This would allow tighter integration into the drawing tools and other core features. Can you imagine if snapping was a core plugin? or the composer? </div>


<div class="gmail_extra"><br></div><div class="gmail_extra">I do see the core plugin idea useful as a staging area for things we are not sure fully about just yet or still have issues. </div></div></div>