[Qgis-developer] Adding plugins to core?

Alex Mandel tech_dev at wildintellect.com
Sat Apr 5 09:59:39 PDT 2014


Perhaps the proposal is really, which plugins to ship by default?
Which sounds the same but is slightly different or could be interpreted
differently as add the plugins to core.

I'm +1 for adding a few more default plugins to the distribution,
especially if they are very common in usage. Remember though, there is a
trade-off, putting too many things in the default interface is
overwhelming for some levels of users. It makes GIS more daunting than
it needs to be.

Thanks,
Alex

PS: Hotmail is known to reject osgeo mailing lists. Wondering if that
magically got fixed.

On 04/05/2014 09:13 AM, Etienne Tourigny wrote:
> On Sat, Apr 5, 2014 at 1:00 AM, Nathan Woodrow <madmanwoo at gmail.com> wrote:
> 
>> I agree that adding the plugins to core would be a good idea however I
>> don't feel that we should just add them in their current state.  The plugin
>> repository has the benefit of of being able to update things faster then
>> the release of QGIS itself if you find bugs, etc, you can also add features
>> for older QGIS versions.
>>
> 
> the processing/sextante plugin is both in core and also can be updated.
> Same thing for ftools and gdaltools.
> 
> 
>>
>> I think these features in the plugins are great but we should really
>> integrate them into the core project itself as new features rather then
>> just a plugin.   Having Python plugins in core can also raise issue for
>> users because they still look like normal plugins but you can't update them
>> because they are no longer in the repository.  Having to enable handy
>> features also feels a bit hap hazard to me.
>>
>> Something like the value tool could easily be integrated into the identify
>> tool for instance.
>>
> 
> I agree, more or less - I thought about integrating it into the main
> identify tool, but as it works with raster layers only, how would you
> display raster and vector layers?
> 
> 
>> There are also some other concepts floating around the idea of bring CAD
>> functions into core so I think it's best to just focus on making those
>> stronger.
>>
>> So +1 for adding the functions but -1 for just bringing the plugins into
>> core.
>>
> 
> Not sure they would make it into core then, as development cost fof
> integrating into core is much higher than adding them as core python
> modules. For instance, the openlayer plugin would probably need quite a lot
> of work to be ported to c++.
> 
> On the other hand, anything that relies on qwt would be better handled.
> Butanthing that uses python plotting libraries would obviously not work.
> 
> cheers
> Etienne
> 
> 
>>
>> - Nathan
>>
>>
>> On Sat, Apr 5, 2014 at 1:22 PM, AntonioLocandro <
>> antoniolocandro at hotmail.com> wrote:
>>
>>> I think it's a great idea, I was actually thinking about this the other
>>> day
>>> and glad you brought the topic.
>>>
>>> Although we can install plugins certainly it becomes evident when a plugin
>>> should really become a core feature, example the Openlayers Plugin, I bet
>>> almost all people using QGIS downloads it before doing anything with QGIS.
>>> Plugins extend QGIS functionality beyond what initially was thought but in
>>> many cases plugins become a must to be able to work efficiently
>>>
>>> If the plugins are added to core I would vote for blending the functions
>>> coherently with the rest of the interface in the appropriate menus. A good
>>> example would be CAD tools which I would say be called Advanced Editing or
>>> something.
>>>
>>> I would add
>>>
>>> http://plugins.qgis.org/plugins/zoomtocoordinates/
>>> http://plugins.qgis.org/plugins/numericalDigitize/  - needs to add case
>>> for
>>> geographic coordinates
>>>
>>>
>>>
>>>

> 



More information about the Qgis-developer mailing list