I agree, each plugin is a different world. It's true that core development can bring further integration, but maybe moving plugins to core is a good moment to rethink how plugins can integrate in the QGIS interface and allow new ways of interacting (for instance, making it easy for a plugin to add elements to the properties window, or new context menus when right-clicking in an element, etc). That's currently limited (or maybe not well documented), and most plugin developers tend to do the most tipical thing and add a menu entry in the "plugins" menu. That is most of the time not the best thing to do...and clearly not the way to go for a core plugin.
2014-04-07 22:41 GMT+02:00 kimaidou <[email protected]>: > Hi Victor > > For me, core features (and not core plugins) are much more integrated into > QGIS ui and dialogs. For example, tablemanager plugins adds some nice > features , but they should be integrated in the Fields tab of the vector > layer properties. Having the features separated in a plugin (core or not > core) adds complexity for users. > > For other plugins like mmqgis, which brings a list of algorithms , I agree > there is no big difference between plugin and feature. > > I think we won't find a common rule for all the plugins. We should have a > look plugin by plugin, otherwise our discussion will go in every direction. > > Michael > > > 2014-04-07 21:43 GMT+02:00 Victor Olaya <[email protected]>: > >> I actually do not see the difference between a core plugin a something >> implemented directly in the core c++ code. Other than the extra time >> it might take to develop it. The user doesn't have to know it is a >> plugin, and it should be easy to actually remove a core plugin from >> the plugin manager (like black-listing it), so it doesn't appear >> there. >> >> >> >> 2014-04-07 20:05 GMT+02:00 Olivier Dalang <[email protected]>: >> > Hi ! >> > >> > I agree with those saying it's better to integrate the features of >> > top-plugin in the core, if we find the features are worth it, and if >> > someone >> > has the time to do so, rather than shipping dozens of preinstalled >> > plugin. >> > >> > I don't like the impression it gives to have a brand new software >> > already >> > "bloated" by plugins, which you never really know what they do and if >> > it's >> > OK or not to remove them. >> > >> > A better alternative IMO is to display the "featured" plugins category >> > as a >> > tab in the plugin manager, but not to preinstall them. >> > It could even become the default page of the plugin manager. >> > >> > I personally feel much better when adding by myself suggested plugins >> > than >> > when hesitating to remove a plugin which I'm not really sure what it's >> > about >> > but seems kinda-important since it already was installed... >> > >> > About this, please consider this ticket also : >> > http://hub.qgis.org/issues/9405 >> > >> > Cheers ! >> > >> > Olivier >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > 2014-04-07 19:41 GMT+02:00 Etienne Tourigny <[email protected]>: >> > >> >> Thanks for the links. Most of this information is also available at >> >> [1]. >> >> >> >> I am preparing a simple plugin to load these layers as raster layers, >> >> will keep you updated on this. >> >> >> >> [1] http://www.gdal.org/frmt_wms.html >> >> >> >> >> >> >> >> On Mon, Apr 7, 2014 at 2:32 PM, kimaidou <[email protected]> wrote: >> >>> >> >>> Hi List >> >>> >> >>> For the record, here is an old blog post about using gdal driver to >> >>> use external layers such as OSM >> >>> >> >>> >> >>> http://www.3liz.com/blog/rldhont/index.php?post/2012/07/17/OpenStreetMap-Tiles-in-QGIS >> >>> >> >>> The problem is that with this method, it seems GDAL does not alway use >> >>> the right tiles for the rigth scale. There must be an additionnal >> >>> parameter wich can control this behaviour. >> >>> >> >>> I totally agree with the concerns about licence violation. Easing the >> >>> use of Google layers is kind of encouraging people to use it, for >> >>> example for digitization purpose. Users must be warned about the terms >> >>> of service. >> >>> >> >>> Michael >> >>> >> >>> PS : someone has gathered a list of XML for GDAL for some providers : >> >>> >> >>> >> >>> http://libreavous.teledetection.fr/geomatique/28-sig/58-afficher-des-couches-issues-de-services-en-ligne-dans-un-sig >> >>> >> >>> Click on the button called "Fichiers de configuration ...." >> >>> Michael >> >>> >> >>> 2014-04-07 16:48 UTC+02:00, Etienne Tourigny >> >>> <[email protected]>: >> >>> >> >>> > Since the OpenLayers plugin does not (currently) work with master, >> >>> > perhaps >> >>> > we can replace it with TMS-based layers, either through a plugin or >> >>> > as >> >>> > a >> >>> > native (GDAL-based) provider? >> >>> > >> >>> > Is there anything in OpenLayers plugin that could not work with GDAL >> >>> > TMS >> >>> > mini-driver [1] ? >> >>> > >> >>> > [1] http://www.gdal.org/frmt_wms.html >> >>> > >> >>> > >> >>> > On Mon, Apr 7, 2014 at 11:42 AM, Etienne Tourigny >> >>> > <[email protected]>wrote: >> >>> > >> >>> >> Since the OpenLayers plugin does not (currently) work with master, >> >>> >> perhaps >> >>> >> we can replace it with TMS-based layers, wither through a plugin or >> >>> >> as >> >>> >> a >> >>> >> native (GDAL-based) provider? >> >>> >> >> >>> >> Is there anything in OpenLayers that could not work with GDAL TMS >> >>> >> mini-driver [1] ? >> >>> >> >> >>> >> >> >>> >> >> >>> >> On Mon, Apr 7, 2014 at 7:22 AM, Vincent Picavet >> >>> >> <[email protected]>wrote: >> >>> >> >> >>> >>> Hello, >> >>> >>> >> >>> >>> Le lundi 7 avril 2014 12:05:05, Nyall Dawson a écrit : >> >>> >>> > On 7 April 2014 18:15, Vincent Picavet <[email protected]> >> >>> >>> > wrote: >> >>> >>> > > A good solution though would be to remove google layers and >> >>> >>> > > only >> >>> >>> > > use >> >>> >>> OSM >> >>> >>> > > and mapbox layers, which begin to be on par in terms of >> >>> >>> > > quality. >> >>> >>> > >> >>> >>> > I'm pretty sure this is against MapBox's terms of service too, >> >>> >>> > unless >> >>> >>> > users were made to sign up for a MapBox account and had to add >> >>> >>> > their >> >>> >>> > individual API key to QGIS to unlock MapBox layers: >> >>> >>> > "You must have a Mapbox account to use Mapbox. You are required >> >>> >>> > to >> >>> >>> > register for an account before using the Service. Each request >> >>> >>> > to >> >>> >>> > the >> >>> >>> > API must include your account's unique API identifier. >> >>> >>> > Unauthorized >> >>> >>> > use of any API identifier is prohibited." [1] >> >>> >>> >> >>> >>> Right, I had not read this through. It would probably be much >> >>> >>> easier >> >>> >>> to >> >>> >>> get a >> >>> >>> specific authorization from MapBox than from Google though, given >> >>> >>> their >> >>> >>> open- >> >>> >>> source orientation. >> >>> >>> >> >>> >>> > > Or let the user a >> >>> >>> > > deliberate way to add google layers (indicating a URL or >> >>> >>> > > something >> >>> >>> like >> >>> >>> > > this), warning him about the licence. >> >>> >>> > >> >>> >>> > Hmm... while this may be a workable solution to the licensing >> >>> >>> > issue, >> >>> >>> > wouldn't it be a step back in functionality anyway? We'd be >> >>> >>> > trading >> >>> >>> > having a good, working off-the-shelf third-party plugin for a >> >>> >>> > crippled >> >>> >>> > core version which takes user intervention to unlock the same >> >>> >>> > features. >> >>> >>> >> >>> >>> In any case, there are quite a lot of OSM based layers which can >> >>> >>> be >> >>> >>> used >> >>> >>> (HOT, >> >>> >>> OSM.fr, OpenCycleMap...). We can still enhance the plugin with >> >>> >>> those. >> >>> >>> It would lack an aerial imagery layer though. >> >>> >>> >> >>> >>> > I'm totally for adding essential plugins to core (or merging the >> >>> >>> > functionality with reimplemented c++ versions), but I honestly >> >>> >>> > don't >> >>> >>> > know if it's workable to do this for the OpenLayers plugin. >> >>> >>> >> >>> >>> Right, if we remove everything from the plugin except the TMS YXZ >> >>> >>> layers, >> >>> >>> we >> >>> >>> could also just have a better ergonomy for opening this kind of >> >>> >>> layers >> >>> >>> through >> >>> >>> GDAL, and have a predefined list of layers accessible on internet >> >>> >>> (even >> >>> >>> auto- >> >>> >>> updatable by downloading the list). >> >>> >>> >> >>> >>> Vincent >> >>> >>> _______________________________________________ >> >>> >>> Qgis-developer mailing list >> >>> >>> [email protected] >> >>> >>> http://lists.osgeo.org/mailman/listinfo/qgis-developer >> >>> >>> >> >>> >> >> >>> >> >> >>> > >> >> >> >> >> >> >> >> _______________________________________________ >> >> Qgis-developer mailing list >> >> [email protected] >> >> http://lists.osgeo.org/mailman/listinfo/qgis-developer >> > >> > >> > >> > _______________________________________________ >> > Qgis-developer mailing list >> > [email protected] >> > http://lists.osgeo.org/mailman/listinfo/qgis-developer >> _______________________________________________ >> Qgis-developer mailing list >> [email protected] >> http://lists.osgeo.org/mailman/listinfo/qgis-developer > > _______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
