Re: [Qgis-developer] should core plugins not be available in plugin manager?

[Tom Chadwin]

Amy other plugins - currently core or not - which should also be migrated to
core and stop being plugins at all? Or just Processing and DB Manager? I
can't think of any. 

Tom



-
Buy Pie Spy: Adventures in British pastry 2010-11 on Amazon 
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/should-core-plugins-not-be-available-in-plugin-manager-tp5299556p5300114.html
Sent from the Quantum GIS - Developer mailing list archive at Nabble.com.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] should core plugins not be available in plugin manager?

[Nyall Dawson]

On 13 December 2016 at 09:00, Nyall Dawson  wrote:
> On 13 December 2016 at 08:48, Nathan Woodrow  wrote:
>> Yeah I do agree with this point.  Remove what isn't needed first then make
>> the rest always on, or even better just
>> remove the whole core plugin concept completely as it doesn't make sense
>> IMO.
>
> I've also been thinking... maybe we should make a QEP about "no more
> core plugins, no exceptions!", get it agreed upon and accepted, and
> then block any future additions of core plugins.

Ok, done. See https://github.com/qgis/QGIS-Enhancement-Proposals/issues/85

Nyall

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

Re: [Qgis-developer] should core plugins not be available in plugin manager?

[Victor Olaya]

2016-12-13 10:10 GMT+01:00 Nathan Woodrow :
> IMO anything core is no longer a plugin, processing included.  We don't have
> these options for stuff like Python console etc so it doesn't make sense to
> have it for the rest.
>

+1. Plugins should be "extra" things. Even if they are formally a
plugin, things like DB manager or Processing should be considered core
and handled just like, for instance, the layers panel or the python
console. Will be clearer for user also, i think. They dont have to
know about the implementation, if it's C++ or Python, or that kind of
things...they just have the functionality in there and use it.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] should core plugins not be available in plugin manager?

[Nathan Woodrow]

IMO anything core is no longer a plugin, processing included.  We don't
have these options for stuff like Python console etc so it doesn't make
sense to have it for the rest.

- Nathan

On Tue, Dec 13, 2016 at 6:30 PM, Régis Haubourg 
wrote:

> Hi all,
> just a reminder that we have a --noplugins startup option that will
> deactivate plugins for testing purpose.
> What would be then the intended behaviour with core python plugins like
> processing?
>
> On my side, I would keep an option to do that, and if possible not rename
> it. So this is an argument to support the idea of naming them plugin
> (because they are plugins from a code point of view).
>
> Thinking loudly, maybe a CLI option to choose explicitly the list of
> plugins to load could even be better. That way default behavior will always
> have plugins loaded, but edge uses cases still have a way to avoid loading
> some at all.
> Opinions?
> Régis
>
> 2016-12-13 9:01 GMT+01:00 Paolo Cavallini :
>
>> Il 13/12/2016 08:08, Neumann, Andreas ha scritto:
>>
>> > I do agree though that some core plugins could be removed or integrated
>> > into the core. One example is the coordinate capture plugin, which could
>> > be easily integrated in core, e.g. integrated in the identify tool or
>> > status bar.
>>
>> big +1 from me
>>
>> > Probably the EVIS plugin is another candidate with lots of overlaps. If
>> > we add the missing functionality the EVIS plugin provides to core, we
>> > could get rid of it.
>>
>> also a big +1 (could be more work though.
>> All the best.
>>
>> --
>> Paolo Cavallini - www.faunalia.eu
>> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
>> https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
>> ___
>> Qgis-developer mailing list
>> Qgis-developer@lists.osgeo.org
>> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>
>
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] should core plugins not be available in plugin manager?

[Régis Haubourg]

Hi all,
just a reminder that we have a --noplugins startup option that will
deactivate plugins for testing purpose.
What would be then the intended behaviour with core python plugins like
processing?

On my side, I would keep an option to do that, and if possible not rename
it. So this is an argument to support the idea of naming them plugin
(because they are plugins from a code point of view).

Thinking loudly, maybe a CLI option to choose explicitly the list of
plugins to load could even be better. That way default behavior will always
have plugins loaded, but edge uses cases still have a way to avoid loading
some at all.
Opinions?
Régis

2016-12-13 9:01 GMT+01:00 Paolo Cavallini :

> Il 13/12/2016 08:08, Neumann, Andreas ha scritto:
>
> > I do agree though that some core plugins could be removed or integrated
> > into the core. One example is the coordinate capture plugin, which could
> > be easily integrated in core, e.g. integrated in the identify tool or
> > status bar.
>
> big +1 from me
>
> > Probably the EVIS plugin is another candidate with lots of overlaps. If
> > we add the missing functionality the EVIS plugin provides to core, we
> > could get rid of it.
>
> also a big +1 (could be more work though.
> All the best.
>
> --
> Paolo Cavallini - www.faunalia.eu
> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
> https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] should core plugins not be available in plugin manager?

[Paolo Cavallini]

Il 13/12/2016 08:08, Neumann, Andreas ha scritto:

> I do agree though that some core plugins could be removed or integrated
> into the core. One example is the coordinate capture plugin, which could
> be easily integrated in core, e.g. integrated in the identify tool or
> status bar.

big +1 from me

> Probably the EVIS plugin is another candidate with lots of overlaps. If
> we add the missing functionality the EVIS plugin provides to core, we
> could get rid of it.

also a big +1 (could be more work though.
All the best.

-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] should core plugins not be available in plugin manager?

[Marco Bernasocchi]

A core plugin can be python as well. 
Ciao

On 13 December 2016 08:14:46 CET, Andreas Neumann  wrote:
>Ok - thanks for clarifying.
>
>What's the difference between a core C++ plugin and a C++ plugin?
>
>Is the only difference that the core plugins are shipped and enabled by
>
>default?
>
>Andreas
>
>On 13.12.2016 08:09, Nathan Woodrow wrote:
>> To be clear this isn't removing the ability to have C++ plugins, just
>
>> having core plugins and making them optional.
>>
>> - Nathan
>>
>> On Tue, Dec 13, 2016 at 5:08 PM, Neumann, Andreas
>> > wrote:
>>
>> Hi,
>>
>> Before we remove the ability to have C++ plugins, or the ability
>> to enable/disable them, we should first inform our users and
>> developers and ask them if we are fine with what we propose.
>>
>> There may be usages of QGIS out there that rely on the ability to
>> have C++ plugins that we are not aware of.
>>
>> ---
>>
>> I do agree though that some core plugins could be removed or
>> integrated into the core. One example is the coordinate capture
>> plugin, which could be easily integrated in core, e.g. integrated
>> in the identify tool or status bar.
>>
>> Probably the EVIS plugin is another candidate with lots of
>> overlaps. If we add the missing functionality the EVIS plugin
>> provides to core, we could get rid of it.
>>
>> Andreas
>>
>> On 2016-12-12 20:57, DelazJ wrote:
>>
>>> Hi,
>>> I do not fully share the agreement on having core plugins not
>>> deactivable. Are Core plugins the problem or is it Processing?
>>> Let's not wrongly mix issues.
>>>
>>> I'd always thought that Core plugins meant plugins developed,
>>> managed, updated by the QGIS project itself, provided by default
>>> with installation. It doesn't mean that everybody wants to use
>it
>>> or needs it. The Road Graph is a plugin I had never executed in
>5
>>> years I'm using QGIS. Many others (GPS Tools, Heatmap, rasters
>>> related plugins...) are concerned. Why would I want it activated
>>> by default and crowd the GUI? Then I'd have to struggle and
>>> change some somehow hidden customization option to have it
>>> disabled? Uncheck it in Plugin Manager sounds far simpler.
>>>
>>> What puzzled many users (and might still do) with Processing in
>>> QGIS >=2.16 is to have removed fTools and not activate
>Processing
>>> by default for those that were using fTools. They should be
>>> provided a transparent replacement of fTools (including the
>>> removal of this one from the list).
>>> And maybe communication about this change is not clear for all
>>> people. Currently, fTools state is broken but there's no message
>>> to tell you that you should instead activate Processing to get
>>> back your lovely functions.
>>>
>>> So, from me, no, Core plugins should stay (de)activable even
>>> though looking at all the list of Core plugins being integrated
>>> in Processing in 3.0 I wonder how many Core plugins will stay
>(DB
>>> Manager and Processing?) when 3.0 lands. :)
>>>
>>> Also, one of the power of QGIS imho is its modularity: you pick
>>> what you need. We should not put all in one. And having Core
>>> plugins being listed there gives some kind of confidence to
>>> contributors to follow the path (create plugins). I'm not sure i
>>> well expressed what I meant to.
>>>
>>>
>>> Regards,
>>> Harrissou
>>>
>>>
>>>
>>> 2016-12-12 16:01 GMT+01:00 Martin Dobias >> >:
>>>
>>> Hi Victor
>>>
>>> On Mon, Dec 12, 2016 at 7:05 PM, Victor Olaya
>>> > wrote:
>>> > Hi
>>> >
>>> > This has been discussed in the past, but i think no
>>> decision was
>>> > taken, so I want to bring back the discussion.
>>> >
>>> > I think that core plugins should not be visible in the
>>> plugin manager,
>>> > and users should not be able to disable them. If they are
>>> core, they
>>> > should be active (the menus and buttons can be removed
>with the
>>> > "View/Customization..." functionality if the user wants
>to)
>>>
>>> Agreed that Processing should be always on. Also, IMO it
>>> should be
>>> available as "qgis.processing" python module.
>>>
>>> Cheers
>>> Martin
>>> ___
>>> Qgis-developer mailing list
>>> Qgis-developer@lists.osgeo.org
>>> 
>>> List info:
>>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>> 
>>> Unsubscribe:
>>> 

Re: [Qgis-developer] should core plugins not be available in plugin manager?

[Andreas Neumann]

Ok - thanks for clarifying.

What's the difference between a core C++ plugin and a C++ plugin?

Is the only difference that the core plugins are shipped and enabled by 
default?


Andreas

On 13.12.2016 08:09, Nathan Woodrow wrote:
To be clear this isn't removing the ability to have C++ plugins, just 
having core plugins and making them optional.


- Nathan

On Tue, Dec 13, 2016 at 5:08 PM, Neumann, Andreas > wrote:


Hi,

Before we remove the ability to have C++ plugins, or the ability
to enable/disable them, we should first inform our users and
developers and ask them if we are fine with what we propose.

There may be usages of QGIS out there that rely on the ability to
have C++ plugins that we are not aware of.

---

I do agree though that some core plugins could be removed or
integrated into the core. One example is the coordinate capture
plugin, which could be easily integrated in core, e.g. integrated
in the identify tool or status bar.

Probably the EVIS plugin is another candidate with lots of
overlaps. If we add the missing functionality the EVIS plugin
provides to core, we could get rid of it.

Andreas

On 2016-12-12 20:57, DelazJ wrote:


Hi,
I do not fully share the agreement on having core plugins not
deactivable. Are Core plugins the problem or is it Processing?
Let's not wrongly mix issues.

I'd always thought that Core plugins meant plugins developed,
managed, updated by the QGIS project itself, provided by default
with installation. It doesn't mean that everybody wants to use it
or needs it. The Road Graph is a plugin I had never executed in 5
years I'm using QGIS. Many others (GPS Tools, Heatmap, rasters
related plugins...) are concerned. Why would I want it activated
by default and crowd the GUI? Then I'd have to struggle and
change some somehow hidden customization option to have it
disabled? Uncheck it in Plugin Manager sounds far simpler.

What puzzled many users (and might still do) with Processing in
QGIS >=2.16 is to have removed fTools and not activate Processing
by default for those that were using fTools. They should be
provided a transparent replacement of fTools (including the
removal of this one from the list).
And maybe communication about this change is not clear for all
people. Currently, fTools state is broken but there's no message
to tell you that you should instead activate Processing to get
back your lovely functions.

So, from me, no, Core plugins should stay (de)activable even
though looking at all the list of Core plugins being integrated
in Processing in 3.0 I wonder how many Core plugins will stay (DB
Manager and Processing?) when 3.0 lands. :)

Also, one of the power of QGIS imho is its modularity: you pick
what you need. We should not put all in one. And having Core
plugins being listed there gives some kind of confidence to
contributors to follow the path (create plugins). I'm not sure i
well expressed what I meant to.


Regards,
Harrissou



2016-12-12 16:01 GMT+01:00 Martin Dobias >:

Hi Victor

On Mon, Dec 12, 2016 at 7:05 PM, Victor Olaya
> wrote:
> Hi
>
> This has been discussed in the past, but i think no
decision was
> taken, so I want to bring back the discussion.
>
> I think that core plugins should not be visible in the
plugin manager,
> and users should not be able to disable them. If they are
core, they
> should be active (the menus and buttons can be removed with the
> "View/Customization..." functionality if the user wants to)

Agreed that Processing should be always on. Also, IMO it
should be
available as "qgis.processing" python module.

Cheers
Martin
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org

List info:
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Unsubscribe:
http://lists.osgeo.org/mailman/listinfo/qgis-developer



___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org

List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Unsubscribe:
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] should core plugins not be available in plugin manager?

[Victor Olaya]

Nyall,

I agree on your approach. Not all core plugins are the same. I guess I
didn't want to say "Hey, Processing has to be always enabled!" :-) But
yes, Processing is a particular case of a plugin, since other plugins
depend on it, and now it replaces ftools, so maybe it makes sense to
keep it there and always enabled, while that does not apply for other
plugins.

A bit of cleanup in the set of core plugins is needed, i agree with
that. This is similar to what happens (at a different scale) with
Processing providers. Some of them are there for historical reasons,
from a time when the project was smaller, but it makes no sense to
keep them there now.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] should core plugins not be available in plugin manager?

[Nathan Woodrow]

To be clear this isn't removing the ability to have C++ plugins, just
having core plugins and making them optional.

- Nathan

On Tue, Dec 13, 2016 at 5:08 PM, Neumann, Andreas 
wrote:

> Hi,
>
> Before we remove the ability to have C++ plugins, or the ability to
> enable/disable them, we should first inform our users and developers and
> ask them if we are fine with what we propose.
>
> There may be usages of QGIS out there that rely on the ability to have C++
> plugins that we are not aware of.
>
> ---
>
> I do agree though that some core plugins could be removed or integrated
> into the core. One example is the coordinate capture plugin, which could be
> easily integrated in core, e.g. integrated in the identify tool or status
> bar.
>
> Probably the EVIS plugin is another candidate with lots of overlaps. If we
> add the missing functionality the EVIS plugin provides to core, we could
> get rid of it.
>
> Andreas
>
> On 2016-12-12 20:57, DelazJ wrote:
>
> Hi,
> I do not fully share the agreement on having core plugins not deactivable.
> Are Core plugins the problem or is it Processing? Let's not wrongly mix
> issues.
>
> I'd always thought that Core plugins meant plugins developed, managed,
> updated by the QGIS project itself, provided by default with installation.
> It doesn't mean that everybody wants to use it or needs it. The Road Graph
> is a plugin I had never executed in 5 years I'm using QGIS. Many others
> (GPS Tools, Heatmap, rasters related plugins...) are concerned. Why would I
> want it activated by default and crowd the GUI? Then I'd have to struggle
> and change some somehow hidden customization option to have it disabled?
> Uncheck it in Plugin Manager sounds far simpler.
>
> What puzzled many users (and might still do) with Processing in QGIS
> >=2.16 is to have removed fTools and not activate Processing by default for
> those that were using fTools. They should be provided a transparent
> replacement of fTools (including the removal of this one from the list).
> And maybe communication about this change is not clear for all people.
> Currently, fTools state is broken but there's no message to tell you that
> you should instead activate Processing to get back your lovely functions.
>
> So, from me, no, Core plugins should stay (de)activable even though
> looking at all the list of Core plugins being integrated in Processing in
> 3.0 I wonder how many Core plugins will stay (DB Manager and Processing?)
> when 3.0 lands. :)
>
> Also, one of the power of QGIS imho is its modularity: you pick what you
> need. We should not put all in one. And having Core plugins being listed
> there gives some kind of confidence to contributors to follow the path
> (create plugins). I'm not sure i well expressed what I meant to.
>
>
> Regards,
> Harrissou
>
>
>
> 2016-12-12 16:01 GMT+01:00 Martin Dobias :
>
>> Hi Victor
>>
>> On Mon, Dec 12, 2016 at 7:05 PM, Victor Olaya  wrote:
>> > Hi
>> >
>> > This has been discussed in the past, but i think no decision was
>> > taken, so I want to bring back the discussion.
>> >
>> > I think that core plugins should not be visible in the plugin manager,
>> > and users should not be able to disable them. If they are core, they
>> > should be active (the menus and buttons can be removed with the
>> > "View/Customization..." functionality if the user wants to)
>>
>> Agreed that Processing should be always on. Also, IMO it should be
>> available as "qgis.processing" python module.
>>
>> Cheers
>> Martin
>> ___
>> Qgis-developer mailing list
>> Qgis-developer@lists.osgeo.org
>> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
>
>
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] should core plugins not be available in plugin manager?

[Neumann, Andreas]

Hi, 

Before we remove the ability to have C++ plugins, or the ability to
enable/disable them, we should first inform our users and developers and
ask them if we are fine with what we propose. 

There may be usages of QGIS out there that rely on the ability to have
C++ plugins that we are not aware of. 

--- 

I do agree though that some core plugins could be removed or integrated
into the core. One example is the coordinate capture plugin, which could
be easily integrated in core, e.g. integrated in the identify tool or
status bar. 

Probably the EVIS plugin is another candidate with lots of overlaps. If
we add the missing functionality the EVIS plugin provides to core, we
could get rid of it. 

Andreas 

On 2016-12-12 20:57, DelazJ wrote:

> Hi, I do not fully share the agreement on having core plugins not 
> deactivable. Are Core plugins the problem or is it Processing? Let's not 
> wrongly mix issues.
> 
> I'd always thought that Core plugins meant plugins developed, managed, 
> updated by the QGIS project itself, provided by default with installation. It 
> doesn't mean that everybody wants to use it or needs it. The Road Graph is a 
> plugin I had never executed in 5 years I'm using QGIS. Many others (GPS 
> Tools, Heatmap, rasters related plugins...) are concerned. Why would I want 
> it activated by default and crowd the GUI? Then I'd have to struggle and 
> change some somehow hidden customization option to have it disabled? Uncheck 
> it in Plugin Manager sounds far simpler.
> 
> What puzzled many users (and might still do) with Processing in QGIS >=2.16 
> is to have removed fTools and not activate Processing by default for those 
> that were using fTools. They should be provided a transparent replacement of 
> fTools (including the removal of this one from the list). 
> And maybe communication about this change is not clear for all people. 
> Currently, fTools state is broken but there's no message to tell you that you 
> should instead activate Processing to get back your lovely functions.
> 
> So, from me, no, Core plugins should stay (de)activable even though looking 
> at all the list of Core plugins being integrated in Processing in 3.0 I 
> wonder how many Core plugins will stay (DB Manager and Processing?) when 3.0 
> lands. :)
> 
> Also, one of the power of QGIS imho is its modularity: you pick what you 
> need. We should not put all in one. And having Core plugins being listed 
> there gives some kind of confidence to contributors to follow the path 
> (create plugins). I'm not sure i well expressed what I meant to.
> 
> Regards, Harrissou
> 
> 2016-12-12 16:01 GMT+01:00 Martin Dobias :
> 
>> Hi Victor
>> 
>> On Mon, Dec 12, 2016 at 7:05 PM, Victor Olaya  wrote:
>>> Hi
>>> 
>>> This has been discussed in the past, but i think no decision was
>>> taken, so I want to bring back the discussion.
>>> 
>>> I think that core plugins should not be visible in the plugin manager,
>>> and users should not be able to disable them. If they are core, they
>>> should be active (the menus and buttons can be removed with the
>>> "View/Customization..." functionality if the user wants to)
>> 
>> Agreed that Processing should be always on. Also, IMO it should be
>> available as "qgis.processing" python module.
>> 
>> Cheers
>> Martin
>> 
>> ___
>> Qgis-developer mailing list
>> Qgis-developer@lists.osgeo.org
>> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer [1]
>> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer [1]
> 
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

  

Links:
--
[1] http://lists.osgeo.org/mailman/listinfo/qgis-developer
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] should core plugins not be available in plugin manager?

[Nyall Dawson]

On 13 December 2016 at 08:48, Nathan Woodrow  wrote:
> Yeah I do agree with this point.  Remove what isn't needed first then make
> the rest always on, or even better just
> remove the whole core plugin concept completely as it doesn't make sense
> IMO.

I've also been thinking... maybe we should make a QEP about "no more
core plugins, no exceptions!", get it agreed upon and accepted, and
then block any future additions of core plugins.

Nyall

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

Re: [Qgis-developer] should core plugins not be available in plugin manager?

[Nathan Woodrow]

Yeah I do agree with this point.  Remove what isn't needed first then make
the rest always on, or even better just
remove the whole core plugin concept completely as it doesn't make sense
IMO.

- Nathan

On Tue, Dec 13, 2016 at 8:24 AM, Nyall Dawson 
wrote:

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

Re: [Qgis-developer] should core plugins not be available in plugin manager?

[Nyall Dawson]

On 12 December 2016 at 21:14, Nathan Woodrow  wrote:
> +1
>
> Yes please. if it's core (plugin or not) it shouldn't be optional and should
> be enabled always.
> It's just confusing for people and honestly doesn't feel right having core
> parts disabled/enabled, imagine if
> the style dock or atlas stuff, etc was optional. Messy and confusing.
>
> The other issue is when some of us don't run with all core plugins enabled
> all the time it's hard to judge the
> full state of things as a complete package e.g I see tons of screenshots
> with the shortest path
> plugin enabled and taking half the dock space when I bet most people would
> never use it.
>
> So a massive +1 from me on this one.

I'm a +1 / -1 on this!

To explain: I'm +1 on processing being removed from the list and being
made always-on. Processing is an integral part of QGIS now and I see
no reason why anyone should want to run QGIS without processing.

I'm a strong -1 on making all core plugins enabled and mandatory. My
reasoning here is that the current batch of core plugins is a random
mix of stuff of varying value and usefulness. Historically a lot of
them are just there because they were introduced before the current
python/plugin infrastructure was in place and no one has removed them
yet. I see absolutely no value in making plugins like "oracle raster",
"evis", or "gps tools" manadatory, and lots of reasons why they should
not be (ui clutter, no-one maintaining these plugins or addressing
bugs in them). Even a useful plugin like "coordinate capture" adds a
lot of UI clutter and should not be mandatory.

There's also the issue that we have core plugins with overlapping
functionality (geometry checker vs topology checker).

I think in future we could re-asses this, but right now we need to
first focus on cleaning up, consolidating and purging the existing
plugins (see https://github.com/qgis/qgis3.0_api/issues/67). Then we
should evaluate whether the remaining core plugins should be ported to
python and moved from the core repo to instead exist as separate
standard plugins.

Nyall


>
> - Nathan
>
>
> On Mon, Dec 12, 2016 at 9:05 PM, Victor Olaya  wrote:
>>
>> Hi
>>
>> This has been discussed in the past, but i think no decision was
>> taken, so I want to bring back the discussion.
>>
>> I think that core plugins should not be visible in the plugin manager,
>> and users should not be able to disable them. If they are core, they
>> should be active (the menus and buttons can be removed with the
>> "View/Customization..." functionality if the user wants to)
>>
>> Since we removed the ftools plugin and now have the corresponding
>> functionality from Processing, some users are confused for not finding
>> the usual tools there. We have kept the same menus, for those that are
>> used to them and dont want to use the toolbox. However, if users do
>> not have Processing enabled, they won't see those menus. And it is not
>> obvious that they have to enable Processing to get something that
>> previously was a different plugin..
>>
>> I think this is an interesting discussion, so if you have ideas or
>> think that this might have disadvantages, let's talk about it in here.
>>
>>
>> Thanks!
>> ___
>> Qgis-developer mailing list
>> Qgis-developer@lists.osgeo.org
>> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
>
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] should core plugins not be available in plugin manager?

[Ramon Andiñach]

> On 13 Dec. 2016, at 03:57, DelazJ  wrote:
> 
> Hi,
> I do not fully share the agreement on having core plugins not deactivable. 
> Are Core plugins the problem or is it Processing? Let's not wrongly mix 
> issues.
> 
> I'd always thought that Core plugins meant plugins developed, managed, 
> updated by the QGIS project itself, provided by default with installation. It 
> doesn't mean that everybody wants to use it or needs it. The Road Graph is a 
> plugin I had never executed in 5 years I'm using QGIS. Many others (GPS 
> Tools, Heatmap, rasters related plugins...) are concerned. Why would I want 
> it activated by default and crowd the GUI? Then I'd have to struggle and 
> change some somehow hidden customization option to have it disabled? Uncheck 
> it in Plugin Manager sounds far simpler.
> 
> What puzzled many users (and might still do) with Processing in QGIS >=2.16 
> is to have removed fTools and not activate Processing by default for those 
> that were using fTools. They should be provided a transparent replacement of 
> fTools (including the removal of this one from the list). 

+1
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] should core plugins not be available in plugin manager?

[DelazJ]

Hi,
I do not fully share the agreement on having core plugins not deactivable.
Are Core plugins the problem or is it Processing? Let's not wrongly mix
issues.

I'd always thought that Core plugins meant plugins developed, managed,
updated by the QGIS project itself, provided by default with installation.
It doesn't mean that everybody wants to use it or needs it. The Road Graph
is a plugin I had never executed in 5 years I'm using QGIS. Many others
(GPS Tools, Heatmap, rasters related plugins...) are concerned. Why would I
want it activated by default and crowd the GUI? Then I'd have to struggle
and change some somehow hidden customization option to have it disabled?
Uncheck it in Plugin Manager sounds far simpler.

What puzzled many users (and might still do) with Processing in QGIS >=2.16
is to have removed fTools and not activate Processing by default for those
that were using fTools. They should be provided a transparent replacement
of fTools (including the removal of this one from the list).
And maybe communication about this change is not clear for all people.
Currently, fTools state is broken but there's no message to tell you that
you should instead activate Processing to get back your lovely functions.

So, from me, no, Core plugins should stay (de)activable even though looking
at all the list of Core plugins being integrated in Processing in 3.0 I
wonder how many Core plugins will stay (DB Manager and Processing?) when
3.0 lands. :)

Also, one of the power of QGIS imho is its modularity: you pick what you
need. We should not put all in one. And having Core plugins being listed
there gives some kind of confidence to contributors to follow the path
(create plugins). I'm not sure i well expressed what I meant to.


Regards,
Harrissou



2016-12-12 16:01 GMT+01:00 Martin Dobias :

> Hi Victor
>
> On Mon, Dec 12, 2016 at 7:05 PM, Victor Olaya  wrote:
> > Hi
> >
> > This has been discussed in the past, but i think no decision was
> > taken, so I want to bring back the discussion.
> >
> > I think that core plugins should not be visible in the plugin manager,
> > and users should not be able to disable them. If they are core, they
> > should be active (the menus and buttons can be removed with the
> > "View/Customization..." functionality if the user wants to)
>
> Agreed that Processing should be always on. Also, IMO it should be
> available as "qgis.processing" python module.
>
> Cheers
> Martin
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] should core plugins not be available in plugin manager?

[Martin Dobias]

Hi Victor

On Mon, Dec 12, 2016 at 7:05 PM, Victor Olaya  wrote:
> Hi
>
> This has been discussed in the past, but i think no decision was
> taken, so I want to bring back the discussion.
>
> I think that core plugins should not be visible in the plugin manager,
> and users should not be able to disable them. If they are core, they
> should be active (the menus and buttons can be removed with the
> "View/Customization..." functionality if the user wants to)

Agreed that Processing should be always on. Also, IMO it should be
available as "qgis.processing" python module.

Cheers
Martin
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] should core plugins not be available in plugin manager?

[Victor Olaya]

>
> Only issue I see (and the reason I disable processing sometimes) is the
> brokeness of some providers when I mix and match versions of QGIS, or run
> older (compiled) versions of QGIS.

A good reason to have providers as independent plugins, as I proposed
in another email :-) You should be able to disable providers, but not
the Processing framework itself.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] should core plugins not be available in plugin manager?

[Richard Duivenvoorde]

On 12/12/2016 12:05 PM, Victor Olaya wrote:

Hi

This has been discussed in the past, but i think no decision was
taken, so I want to bring back the discussion.

I think that core plugins should not be visible in the plugin manager,
and users should not be able to disable them. If they are core, they
should be active (the menus and buttons can be removed with the
"View/Customization..." functionality if the user wants to)

Since we removed the ftools plugin and now have the corresponding
functionality from Processing, some users are confused for not finding
the usual tools there. We have kept the same menus, for those that are
used to them and dont want to use the toolbox. However, if users do
not have Processing enabled, they won't see those menus. And it is not
obvious that they have to enable Processing to get something that
previously was a different plugin..

I think this is an interesting discussion, so if you have ideas or
think that this might have disadvantages, let's talk about it in here.


Agreed.

Only issue I see (and the reason I disable processing sometimes) is the 
brokeness of some providers when I mix and match versions of QGIS, or 
run older (compiled) versions of QGIS.


Regards,

Richard

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] should core plugins not be available in plugin manager?

[Giovanni Manghi]

>> So a massive +1 from me on this one.

massive +1 also from me, this has been always confusing for users. It
is funny because when I made this very same proposal by the time qgis
2.0 was in the works it was axed like an heresy ;)

cheers

-- G --
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] should core plugins not be available in plugin manager?

[Tom Chadwin]

+1

In fact, if accepted, why call them plugins?



-
Buy Pie Spy: Adventures in British pastry 2010-11 on Amazon 
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/should-core-plugins-not-be-available-in-plugin-manager-tp5299556p5299567.html
Sent from the Quantum GIS - Developer mailing list archive at Nabble.com.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] should core plugins not be available in plugin manager?

[Alexandre Neto]

+1 by me

If it is a core plugin/functionality, means that it is of interest for most
users, makes no sense to turn it off.

This will solve a few common issues for newcomers.


Nathan Woodrow  escreveu no dia segunda, 12/12/2016 às
11:21:

> +1
>
> Yes please. if it's core (plugin or not) it shouldn't be optional and
> should be enabled always.
> It's just confusing for people and honestly doesn't feel right having core
> parts disabled/enabled, imagine if
> the style dock or atlas stuff, etc was optional. Messy and confusing.
>
> The other issue is when some of us don't run with all core plugins enabled
> all the time it's hard to judge the
> full state of things as a complete package e.g I see tons of screenshots
> with the shortest path
> plugin enabled and taking half the dock space when I bet most people would
> never use it.
>
> So a massive +1 from me on this one.
>
> - Nathan
>
>
> On Mon, Dec 12, 2016 at 9:05 PM, Victor Olaya  wrote:
>
> Hi
>
> This has been discussed in the past, but i think no decision was
> taken, so I want to bring back the discussion.
>
> I think that core plugins should not be visible in the plugin manager,
> and users should not be able to disable them. If they are core, they
> should be active (the menus and buttons can be removed with the
> "View/Customization..." functionality if the user wants to)
>
> Since we removed the ftools plugin and now have the corresponding
> functionality from Processing, some users are confused for not finding
> the usual tools there. We have kept the same menus, for those that are
> used to them and dont want to use the toolbox. However, if users do
> not have Processing enabled, they won't see those menus. And it is not
> obvious that they have to enable Processing to get something that
> previously was a different plugin..
>
> I think this is an interesting discussion, so if you have ideas or
> think that this might have disadvantages, let's talk about it in here.
>
>
> Thanks!
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

-- 
Alexandre Neto
-
@AlexNetoGeo
http://sigsemgrilhetas.wordpress.com
http://gisunchained.wordpress.com
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] should core plugins not be available in plugin manager?

[Nathan Woodrow]

+1

Yes please. if it's core (plugin or not) it shouldn't be optional and
should be enabled always.
It's just confusing for people and honestly doesn't feel right having core
parts disabled/enabled, imagine if
the style dock or atlas stuff, etc was optional. Messy and confusing.

The other issue is when some of us don't run with all core plugins enabled
all the time it's hard to judge the
full state of things as a complete package e.g I see tons of screenshots
with the shortest path
plugin enabled and taking half the dock space when I bet most people would
never use it.

So a massive +1 from me on this one.

- Nathan


On Mon, Dec 12, 2016 at 9:05 PM, Victor Olaya  wrote:

> Hi
>
> This has been discussed in the past, but i think no decision was
> taken, so I want to bring back the discussion.
>
> I think that core plugins should not be visible in the plugin manager,
> and users should not be able to disable them. If they are core, they
> should be active (the menus and buttons can be removed with the
> "View/Customization..." functionality if the user wants to)
>
> Since we removed the ftools plugin and now have the corresponding
> functionality from Processing, some users are confused for not finding
> the usual tools there. We have kept the same menus, for those that are
> used to them and dont want to use the toolbox. However, if users do
> not have Processing enabled, they won't see those menus. And it is not
> obvious that they have to enable Processing to get something that
> previously was a different plugin..
>
> I think this is an interesting discussion, so if you have ideas or
> think that this might have disadvantages, let's talk about it in here.
>
>
> Thanks!
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] should core plugins not be available in plugin manager?

[Victor Olaya]

Hi

This has been discussed in the past, but i think no decision was
taken, so I want to bring back the discussion.

I think that core plugins should not be visible in the plugin manager,
and users should not be able to disable them. If they are core, they
should be active (the menus and buttons can be removed with the
"View/Customization..." functionality if the user wants to)

Since we removed the ftools plugin and now have the corresponding
functionality from Processing, some users are confused for not finding
the usual tools there. We have kept the same menus, for those that are
used to them and dont want to use the toolbox. However, if users do
not have Processing enabled, they won't see those menus. And it is not
obvious that they have to enable Processing to get something that
previously was a different plugin..

I think this is an interesting discussion, so if you have ideas or
think that this might have disadvantages, let's talk about it in here.


Thanks!
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer