[Qgis-developer] Adding plugins to core?

Mon Apr 7 13:57:00 PDT 2014

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 <kimaidou at gmail.com>:
> 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 <volayaf at gmail.com>:
>
>> 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 <olivier.dalang at gmail.com>:
>> > 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 <etourigny.dev at gmail.com>:
>> >
>> >> 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 <kimaidou at gmail.com> 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
>> >>> <etourigny.dev at gmail.com>:
>> >>>
>> >>> > 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
>> >>> > <etourigny.dev at gmail.com>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
>> >>> >> <vincent.ml at oslandia.com>wrote:
>> >>> >>
>> >>> >>> Hello,
>> >>> >>>
>> >>> >>> Le lundi 7 avril 2014 12:05:05, Nyall Dawson a écrit :
>> >>> >>> > On 7 April 2014 18:15, Vincent Picavet <vincent.ml at oslandia.com>
>> >>> >>> > 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
>> >>> >>> Qgis-developer at lists.osgeo.org
>> >>> >>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>> >>> >>>
>> >>> >>
>> >>> >>
>> >>> >
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> Qgis-developer mailing list
>> >> Qgis-developer at lists.osgeo.org
>> >> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>> >
>> >
>> >
>> > _______________________________________________
>> > Qgis-developer mailing list
>> > Qgis-developer at lists.osgeo.org
>> > http://lists.osgeo.org/mailman/listinfo/qgis-developer
>> _______________________________________________
>> Qgis-developer mailing list
>> Qgis-developer at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>