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.15
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 se
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
plugi
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 s
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 argume
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
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
>
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, j
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 th
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 fi
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
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 m
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 W
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 a
> 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,
> upd
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 install
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 di
>
> 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
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, t
>> 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 --
___
Qg
+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 - Deve
+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 s
+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 issu
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 ca
24 matches
Mail list logo