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

[Qgis-developer] Plugin [713] Indicatrix mapper approval notification.

[noreply]

Plugin Indicatrix mapper approval by pcav.
The plugin version "[713] Indicatrix mapper 1.2" is now approved
Link: http://plugins.qgis.org/plugins/tiss/
___
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] Listener for Atlas Change Page

[Nyall Dawson]

On 13 Dec 2016 4:44 PM, "Shawn Tse"  wrote:

Hi all,

I'm interested in being able to make graphs that update depending on
what the active feature in the atlas is. I know some python and a
little bit of the QGIS API, but I'm curious - is there some sort of
listener function for the atlas that gets called whenever the Preview
Atlas/Prev Feature/Next Feature/First Feature/Last Feature buttons are
pressed?


Try QgsAtlasComposition::featureChanged. See
https://qgis.org/api/classQgsAtlasComposition.html#ab1a15fdb6d20ebb1254ebb6714254fac

Nyall


What I eventually want to do is to manipulate the node items that were
created in a recent updated version of QGIS, and use them to make a
line graph, gridlines, etc.

I'm hoping to draw the data directly from the shapefiles themselves or
from a .csv file.

I originally tried to use an expression in a text box to do this, but
it seems that expressions are unable to use custom functions to
manipulate the composer. So I'm hoping that there's some sort of
Listener method.

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] Listener for Atlas Change Page

[Shawn Tse]

Hi all,

I'm interested in being able to make graphs that update depending on
what the active feature in the atlas is. I know some python and a
little bit of the QGIS API, but I'm curious - is there some sort of
listener function for the atlas that gets called whenever the Preview
Atlas/Prev Feature/Next Feature/First Feature/Last Feature buttons are
pressed?

What I eventually want to do is to manipulate the node items that were
created in a recent updated version of QGIS, and use them to make a
line graph, gridlines, etc.

I'm hoping to draw the data directly from the shapefiles themselves or
from a .csv file.

I originally tried to use an expression in a text box to do this, but
it seems that expressions are unable to use custom functions to
manipulate the composer. So I'm hoping that there's some sort of
Listener method.

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

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] loading multiple wfs layers causes unexpected behaviour

[Even Rouault]

> So I think 2.14 is not patched? You need to have latest 2.18 or 2.16 ...
> 
> maybe Even can comment on this? Is it possible to bring this fix in 2.14
> (LTR?)
> 

Richard,

https://github.com/qgis/QGIS/commit/4bcbc1e4e7ce89237e48067e352d50079fdfa4a6 
was to fix a regression of 2.16.0 that didn't exist in 2.14
If I try the Bouwvlak layer in 2.14.8 (manually), that works, so I'm not sure 
what the issue 
you got with 2.14 is.

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.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?

[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] loading multiple wfs layers causes unexpected behaviour

[Richard Duivenvoorde]

Hi Raymond,

I first tested in 2.18.1, and that one just worked, no matter how many 
times. Also the saving/opening of the project.


Then I went to a 2.14.7 version I have, and then one FAILED. In the 
debug information (you run debug version from cli don't you ;-) ) I found:

DescribFeatureType Failed
Googling that I found 'qgis wfs DescribFeatureType Failed' I found:

http://gis.stackexchange.com/questions/205926/qgis-2-16-adding-certain-wfs-failed

which actually talks about exact the same service! Pointing to:
http://hub.qgis.org/issues/15395
which says:
Fixed per 4bcbc1e (and backported in master_2 in f17f6ac, and in 
release-2_16 a0e3e76)


pointing to this commit:

https://github.com/qgis/QGIS/commit/4bcbc1e4e7ce89237e48067e352d50079fdfa4a6

which looks like it had to handle an uncommon capabilities construct 
from the ruimtelijkeplannen.nl service 


So I think 2.14 is not patched? You need to have latest 2.18 or 2.16 ...

maybe Even can comment on this? Is it possible to bring this fix in 2.14 
(LTR?)


Regards,

Richard Duivenvoorde



On 12/10/2016 01:53 PM, Raymond Nijssen wrote:

import urllib
#from qgis.core import import
import time

plangebied = 'NL.IMRO.0796.0002120-1301'

'''
params = {
'service': 'WFS',
'version': '1.0.0',
'request': 'GetFeature',
'typename': 'union',
'srsname': "EPSG:23030"
}
'''


def getWfsLayer(service, typename, filter):
params = {
'typename': typename,
'filter': filter,
'srsname': 'EPSG:28992',
#'restrictToRequestBBOX': '1',
#'version': '2.0.0',
#'table': '',
#'sql': ''
}
if not service[-1] == '?':
service += '?'
uri = service + urllib.unquote(urllib.urlencode(params))
#print uri
layername = typename
vlayer = QgsVectorLayer(uri, layername, "WFS")
return vlayer


def addBestemmingsplan(plangebied):
service = 'http://afnemers.ruimtelijkeplannen.nl/afnemers2012/services'
filter = '"plangebied"=\'' + plangebied + '\''
#print(filter)
layers = [ \
'app:Bouwaanduiding', \
'app:Bouwvlak', \
'app:Enkelbestemming', \
'app:Bestemmingsplangebied', \
]

root = QgsProject.instance().layerTreeRoot()
bpName = plangebied
bpGroup = root.insertGroup(0, bpName)
#print bpGroup

for layer in layers:
#time.sleep(1)
print layer
vlayer = getWfsLayer(service, layer, filter)
print vlayer
#vlayer.updateExtents()
if vlayer.isValid():
QgsMapLayerRegistry.instance().addMapLayer(vlayer, False)
#time.sleep(1)
node_vlayer = bpGroup.addLayer(vlayer)
#time.sleep(1)
else:
print 'invalid layer'

canvas = iface.mapCanvas()
canvas.refresh()


addBestemmingsplan(plangebied)


___
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

Re: [Qgis-developer] List of versions on the bugtracker

[Denis Rouzaud]

Yes, please, take the opportunity of 3.0 to bring us a nice tool to
report issues.

That might be the chance to start with an empty list too :) Let users
port their own issues to github (sic).

Is there any status on that very long standed issue? Has a group being
created to sort out solutions?

Cheers,
Denis




On 12/12/2016 10:45 AM, Giovanni Manghi wrote:
> Hi,
>
>> Hi,
>> I agree, would be nice to have some cleanup on this list and shorten it
>> (keep only release number for recent but not maintained releases instead of
>> many minor releases?). "master_2" should also be removed, no one should be
>> using it.
>
> I think we all know that the bug tracker would need a major cleaning...
> Still very much in favor of re-start clean moving away from Redmine.
>
> About the "affected version" list: it can be modified in the "custom
> fields" section of Redmine, is not anyway something I will do unless I
> will receive a proper green light. Also consider that recently
> regressions have been reported even in between point releases... that
> would not help in making that list shorter...
>
>
> 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

___
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] List of versions on the bugtracker

[Paolo Cavallini]

Il 12/12/2016 10:45, Giovanni Manghi ha scritto:

> About the "affected version" list: it can be modified in the "custom
> fields" section of Redmine, is not anyway something I will do unless I
> will receive a proper green light. Also consider that recently

green light from me
thanks Giovanni

-- 
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] List of versions on the bugtracker

[Giovanni Manghi]

Hi,

> Hi,
> I agree, would be nice to have some cleanup on this list and shorten it
> (keep only release number for recent but not maintained releases instead of
> many minor releases?). "master_2" should also be removed, no one should be
> using it.


I think we all know that the bug tracker would need a major cleaning...
Still very much in favor of re-start clean moving away from Redmine.

About the "affected version" list: it can be modified in the "custom
fields" section of Redmine, is not anyway something I will do unless I
will receive a proper green light. Also consider that recently
regressions have been reported even in between point releases... that
would not help in making that list shorter...


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