Re: [Qgis-developer] Renaming SEXTANTE

[Jonathan Moules]

On 12 August 2013 09:33, Paolo Cavallini  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Il 12/08/2013 10:10, Tim Sutton ha scritto:
>
> > Yes I should have asked this too - personally I prefer we do it in
> > a future version. Maybe its something we should keep for V3?
>
> IMHO renaming sextante after people got used to it will introduce more
> and more confusion. Better remove it now; deeper chamges in the UI can
> wait.
>
>
+1; And I think this philosophy should be carried over to the other plugins
mentioned in this discussion - that they should be renamed sooner rather
than later.
Everyone in this thread knows what all of these things do, but a regular
user isn't going to know what "GDAL" is, or "fTools" or "SEXTANTE". As an
example - just last week I was wondering where my spatial analysis
functions were that were in a tutorial I was following - turns out I'd
disabled the pointless-sounding-to-me "fTools" plugin and they were in
there.
(I'm still quite new to QGIS, but have a technical GIS background - a
non-technical user would have struggled to resolve that).

Jonathan

-- 
This transmission is intended for the named addressee(s) only and may 
contain sensitive or protectively marked material up to RESTRICTED and 
should be handled accordingly. Unless you are the named addressee (or 
authorised to receive it for the addressee) you may not copy or use it, or 
disclose it to anyone else. If you have received this transmission in error 
please notify the sender immediately. All email traffic sent to or from us, 
including without limitation all GCSX traffic, may be subject to recording 
and/or monitoring in accordance with relevant legislation.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Renaming SEXTANTE

[Victor Olaya]

I do not think there is too much risk of breaking things, it shouldn't
be that complex.

Also, it's a plugin (core or not), so we can later publish a newer
version if something is broken, and let people update it. It's not
going to break any other code, since nothing (except plugins based on
SEXTANTE), uses the SEXTANTE code.



2013/8/12 Tim Sutton :
> Hi
>
>
> On Mon, Aug 12, 2013 at 10:33 AM, Paolo Cavallini 
> wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Il 12/08/2013 10:10, Tim Sutton ha scritto:
>>
>> > Yes I should have asked this too - personally I prefer we do it in
>> > a future version. Maybe its something we should keep for V3?
>>
>> IMHO renaming sextante after people got used to it will introduce more
>> and more confusion. Better remove it now; deeper chamges in the UI can
>> wait.
>
>
> I guess we need some feedback on how much work is involved and how much
> chance there is of breaking stuff so close to the release.
>
> Regards
>
> Tim
>
>>
>> All the best.
>> - --
>> Paolo Cavallini - Faunalia
>> www.faunalia.eu
>> Full contact details at www.faunalia.eu/pc
>> Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v1.4.14 (GNU/Linux)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>
>> iEYEARECAAYFAlIInc0ACgkQ/NedwLUzIr5pyQCdExHxNVDYpXN63DB+Ux/K2+o4
>> jQIAn2PaMLEmN0XbXzk9fVWsYKqog0gQ
>> =BCOZ
>> -END PGP SIGNATURE-
>> ___
>> Qgis-developer mailing list
>> Qgis-developer@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
>
>
> --
> Tim Sutton - QGIS Project Steering Committee Member (Release  Manager)
> ==
> Please do not email me off-list with technical
> support questions. Using the lists will gain
> more exposure for your issues and the knowledge
> surrounding your issue will be shared with all.
>
> Irc: timlinux on #qgis at freenode.net
> ==
>
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Renaming SEXTANTE

[Tim Sutton]

Hi


On Mon, Aug 12, 2013 at 10:33 AM, Paolo Cavallini wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Il 12/08/2013 10:10, Tim Sutton ha scritto:
>
> > Yes I should have asked this too - personally I prefer we do it in
> > a future version. Maybe its something we should keep for V3?
>
> IMHO renaming sextante after people got used to it will introduce more
> and more confusion. Better remove it now; deeper chamges in the UI can
> wait.
>

I guess we need some feedback on how much work is involved and how much
chance there is of breaking stuff so close to the release.

Regards

Tim


> All the best.
> - --
> Paolo Cavallini - Faunalia
> www.faunalia.eu
> Full contact details at www.faunalia.eu/pc
> Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.14 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAlIInc0ACgkQ/NedwLUzIr5pyQCdExHxNVDYpXN63DB+Ux/K2+o4
> jQIAn2PaMLEmN0XbXzk9fVWsYKqog0gQ
> =BCOZ
> -END PGP SIGNATURE-
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>



-- 
Tim Sutton - QGIS Project Steering Committee Member (Release  Manager)
==
Please do not email me off-list with technical
support questions. Using the lists will gain
more exposure for your issues and the knowledge
surrounding your issue will be shared with all.

Irc: timlinux on #qgis at freenode.net
==
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Renaming SEXTANTE

[Paolo Cavallini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 12/08/2013 10:10, Tim Sutton ha scritto:

> Yes I should have asked this too - personally I prefer we do it in
> a future version. Maybe its something we should keep for V3?

IMHO renaming sextante after people got used to it will introduce more
and more confusion. Better remove it now; deeper chamges in the UI can
wait.
All the best.
- -- 
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc
Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlIInc0ACgkQ/NedwLUzIr5pyQCdExHxNVDYpXN63DB+Ux/K2+o4
jQIAn2PaMLEmN0XbXzk9fVWsYKqog0gQ
=BCOZ
-END PGP SIGNATURE-
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Renaming SEXTANTE

[Nathan Woodrow]

If you are loading them by default it doesn't make sense to keep them as a
plugins better to just make them core. It doesn't really matter at the
moment for 2.0 anyway but I'll chat about it more at the HF
 On 12/08/2013 6:02 PM, "Tim Sutton"  wrote:

> Hi
>
>
> On Mon, Aug 12, 2013 at 9:32 AM, Nathan Woodrow wrote:
>
>> On Mon, Aug 12, 2013 at 5:13 PM, Marco Hugentobler <
>> marco.hugentob...@sourcepole.ch> wrote:
>>
>>> Plugins are a sophisticated way of keeping things lean and separated.
>>
>>
>> I have no issue with none core plugins, in fact that is something I
>> always promote as a powerful feature. Core however plugins are a different
>> story. While it makes sense to you and I it doesn't make sense to a normal
>> user. Core plugins, while a feature, in fact make the program look
>> incomplete or patchy.  Some of the main problems with core plugins are:
>> they don't have a Python C++ API, functions in them are separated by wall,
>> users have to enable them in order to use them.
>>
>> Lets take a few examples:  A question the other day on IRC was "can I
>> create a heatmap with pyqgis" No is the answer which is confusing because
>> the heatmap plugin is a core feature so why not have it as part of the API?
>>  The topology checker is another example of the features it has should be
>> part of the core package and just baked in. This would allow tighter
>> integration into the drawing tools and other core features. Can you imagine
>> if snapping was a core plugin? or the composer?
>>
>> I do see the core plugin idea useful as a staging area for things we are
>> not sure fully about just yet or still have issues.
>>
>>
> I think this should be simple to address - maintain them as plugins but
> load them automatically and transparently to the user. We could even have a
> new class oc core plugins that do this and explcitly bypass the plugin
> manager ui because they are always 'just on'.
>
> Regards
>
> Tim
>
>
>> ___
>> Qgis-developer mailing list
>> Qgis-developer@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>>
>
>
> --
> Tim Sutton - QGIS Project Steering Committee Member (Release  Manager)
> ==
> Please do not email me off-list with technical
> support questions. Using the lists will gain
> more exposure for your issues and the knowledge
> surrounding your issue will be shared with all.
>
> Irc: timlinux on #qgis at freenode.net
> ==
>
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Renaming SEXTANTE

[Tim Sutton]

Hi


On Mon, Aug 12, 2013 at 10:01 AM, Anita Graser  wrote:

> On Mon, Aug 12, 2013 at 12:36 AM, Victor Olaya  wrote:
>
>> I wasn't very fond of this idea because or course I like the SEXTANTE
>>  branding itself, but in terms of integration I now think it is better.
>
> For a user that wants to do some analysis, keeping the SEXTANTE name
>> means that the user has to know that SEXTANTE is an analysis platform,
>> instead of just being able to look for analysis tools. The menu is
>> already called "analysis", so actually that's not going to be a big
>> problem, but then it doesn't make much sense to have named plugins,
>> specially if it's a core plugin.
>>
>
> Hi Victor,
>
> Considering Tim's latest mail about string and GUI freeze, are you still
> planning to change the naming for 2.0?
>
>
Yes I should have asked this too - personally I prefer we do it in a future
version. Maybe its something we should keep for V3?



> Best wishes,
> Anita
>
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>


-- 
Tim Sutton - QGIS Project Steering Committee Member (Release  Manager)
==
Please do not email me off-list with technical
support questions. Using the lists will gain
more exposure for your issues and the knowledge
surrounding your issue will be shared with all.

Irc: timlinux on #qgis at freenode.net
==
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Renaming SEXTANTE

[Tim Sutton]

Hi


On Mon, Aug 12, 2013 at 9:32 AM, Nathan Woodrow  wrote:

> On Mon, Aug 12, 2013 at 5:13 PM, Marco Hugentobler <
> marco.hugentob...@sourcepole.ch> wrote:
>
>> Plugins are a sophisticated way of keeping things lean and separated.
>
>
> I have no issue with none core plugins, in fact that is something I always
> promote as a powerful feature. Core however plugins are a different story.
> While it makes sense to you and I it doesn't make sense to a normal user.
> Core plugins, while a feature, in fact make the program look incomplete or
> patchy.  Some of the main problems with core plugins are: they don't have a
> Python C++ API, functions in them are separated by wall, users have to
> enable them in order to use them.
>
> Lets take a few examples:  A question the other day on IRC was "can I
> create a heatmap with pyqgis" No is the answer which is confusing because
> the heatmap plugin is a core feature so why not have it as part of the API?
>  The topology checker is another example of the features it has should be
> part of the core package and just baked in. This would allow tighter
> integration into the drawing tools and other core features. Can you imagine
> if snapping was a core plugin? or the composer?
>
> I do see the core plugin idea useful as a staging area for things we are
> not sure fully about just yet or still have issues.
>
>
I think this should be simple to address - maintain them as plugins but
load them automatically and transparently to the user. We could even have a
new class oc core plugins that do this and explcitly bypass the plugin
manager ui because they are always 'just on'.

Regards

Tim


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


-- 
Tim Sutton - QGIS Project Steering Committee Member (Release  Manager)
==
Please do not email me off-list with technical
support questions. Using the lists will gain
more exposure for your issues and the knowledge
surrounding your issue will be shared with all.

Irc: timlinux on #qgis at freenode.net
==
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Renaming SEXTANTE

[Anita Graser]

On Mon, Aug 12, 2013 at 12:36 AM, Victor Olaya  wrote:

> I wasn't very fond of this idea because or course I like the SEXTANTE
>  branding itself, but in terms of integration I now think it is better.

For a user that wants to do some analysis, keeping the SEXTANTE name
> means that the user has to know that SEXTANTE is an analysis platform,
> instead of just being able to look for analysis tools. The menu is
> already called "analysis", so actually that's not going to be a big
> problem, but then it doesn't make much sense to have named plugins,
> specially if it's a core plugin.
>

Hi Victor,

Considering Tim's latest mail about string and GUI freeze, are you still
planning to change the naming for 2.0?

Best wishes,
Anita
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Renaming SEXTANTE

[Nathan Woodrow]

On Mon, Aug 12, 2013 at 5:13 PM, Marco Hugentobler <
marco.hugentob...@sourcepole.ch> wrote:

> Plugins are a sophisticated way of keeping things lean and separated.


I have no issue with none core plugins, in fact that is something I always
promote as a powerful feature. Core however plugins are a different story.
While it makes sense to you and I it doesn't make sense to a normal user.
Core plugins, while a feature, in fact make the program look incomplete or
patchy.  Some of the main problems with core plugins are: they don't have a
Python C++ API, functions in them are separated by wall, users have to
enable them in order to use them.

Lets take a few examples:  A question the other day on IRC was "can I
create a heatmap with pyqgis" No is the answer which is confusing because
the heatmap plugin is a core feature so why not have it as part of the API?
 The topology checker is another example of the features it has should be
part of the core package and just baked in. This would allow tighter
integration into the drawing tools and other core features. Can you imagine
if snapping was a core plugin? or the composer?

I do see the core plugin idea useful as a staging area for things we are
not sure fully about just yet or still have issues.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Renaming SEXTANTE

[Paolo Cavallini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 12/08/2013 09:13, Marco Hugentobler ha scritto:
> I think the plugin concept is highly usefull for both core/noncore,
> C++

Hi all.
I agree the plugin architecture is useful. IMHO the issue is mainly a
matter of hiding too much detail for the average user.
Of course having functions available to Py plugins is an important
feature.
All the best.
- -- 
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc
Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlIIj3QACgkQ/NedwLUzIr5IeQCgn1vE7LzBpIIr/zy3F9dzsaD7
inYAnRa6sQ51PUnkuGkxOFH28RD1EQVE
=LZPr
-END PGP SIGNATURE-
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Renaming SEXTANTE

[Marco Hugentobler]

Hi Nathan

>Personally I find the core plugin concept unnecessary. If it's core it 
shouldn't be a plugin and should just be part of the main program.  It 
can still be Python that is fine however >users shouldn't have to turn 
them on and off they should just be there and be transparent.


I think the plugin concept is highly usefull for both core/noncore, C++ 
and Python plugins. It helps to keep code well separated and avoids 
bloating the size of the main executable for things which are rarely 
used ( read for e.g. here why size _does_ matter: 
https://www.webkit.org/blog/2826/unusual-speed-boost-size-matters/ ). 
Many people never use e.g. grass plugin, evis, georeferencer, globe. 
Plugins are a sophisticated way of keeping things lean and separated.


>however users shouldn't have to turn them on

That's the same thing for toolbars which are hidden by default or the 
browser. Many people don't notice those features. However, Iwe cannot 
clutter the interface with everything by default just to save the user 
from doing a click or looking up things in the documentation or with google.


Regards,
Marco



On 10.08.2013 12:42, Nathan Woodrow wrote:

+1 from me too.

Personally I find the core plugin concept unnecessary. If it's core it 
shouldn't be a plugin and should just be part of the main program.  It 
can still be Python that is fine however users shouldn't have to turn 
them on and off they should just be there and be transparent.


IMO we should aim to kill of all C++ core plugins in 2.1 and make them 
core features.Things like the geometry checking, spatial join, 
georeferencer should all be core features and have C++ and Python APIs 
that the user can use.


- Nathan


On Sat, Aug 10, 2013 at 4:37 PM, MORREALE Jean Roc 
mailto:jr.morre...@enoreth.net>> wrote:


+1 here for dropping the SEXTANTE name for the same reason we now
have a Vector menu instead of fTools.

I would vote for a "processing" menu as sextante goes beyond analysis


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




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



--
Dr. Marco Hugentobler
Sourcepole -  Linux & Open Source Solutions
Weberstrasse 5, CH-8004 Zürich, Switzerland
marco.hugentob...@sourcepole.ch http://www.sourcepole.ch
Technical Advisor QGIS Project Steering Committee

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

Re: [Qgis-developer] Renaming SEXTANTE

[Alex Mandel]

Well there's an interesting dilemma, I mostly agree that core plugins
don't need to be listed in the plugin manager.. except when one wants to
disable them to get faster load times of QGIS, or to hide those features.

Maybe they should be renamed to Core Vector Tools, Core Raster Tools,
Core Geoprocessing Tools (looks like Larry suggested similar) to
highlight that they ship by default with QGIS. I was also thinking about
when plugins add items to Vector/Raster/Analysis menu, how does one
differentiate which plugin a particular tool comes from, so that bug
reports go to the right place?

As for when you're in SEXTANTE, I don't think hiding where the tool
comes from is a good idea. What happens when there are 2 IDW algorithms
and one works and the other doesn't or their methods are different.
There needs to be enough information for an informed decision. It's also
a means of attribution to the original toolbox that's being wrapped.
Which in my case has led to me using some tools directly when they don't
work right or are missing options in the SEXTANTE wrapper (same goes for
the GRASS plugin).

The "as long as it works" is the catch, I often find myself moving
between the tools that do similar things because one does what I want
and the other does not, or one doesn't work the same way, or one if
faster than the other. So being able to distinguish between very similar
tools is important.

Basically I'm in agreement, but trying to leave room for understanding
how some of the current information will remain accessible.

Tim - good points about the api naming, which should indeed match the
core plugins/tools names.

Thanks,
Alex

On 08/11/2013 04:15 PM, Nathan Woodrow wrote:
> Showing SEXTANTE, GDAL Tools, fTools in the menu is the implementation
> model leaking into the UI.  The users don't care how it's implemented as
> long as it works.
> 
> - Nathan
> 
> 
> On Mon, Aug 12, 2013 at 9:04 AM, Tim Sutton  wrote:
> 
>> Hi
>>
>>
>> On Mon, Aug 12, 2013 at 12:14 AM, Alex Mandel 
>> wrote:
>>
>>> So is the proposal to change Analysis to Processing?
>>> I don't think there's a reason to remove the SEXTANTE branding as
>>> SEXTANTE does exist outside a QGIS context, ftools is another story
>>> since that only exists in QGIS. I'm split on GDAL Tools, since it is
>>> good to make sure users know what underlying tool is being used (ie in
>>> the event they want to use the command line).
>>>
>>> As for the Vector, Raster, etc menus... it's expected that over time
>>> plugins will sort themselves into those menus in order to add
>>> organization and make it more obvious what a tool does. It also makes
>>> the generic plugins section smaller so that you don't have to wade
>>> through 100 plugins to find the one you want.
>>>
>>> The same applies for Analysis or Processing, I expect other analysis and
>>> processing tools to exist that are not SEXTANTE but end up on the list,
>>> in which case being able to tell it apart from what's there remains
>>> important.
>>>
>>> To me this is a UI question, not a core vs. non-core/c++ vs. python
>>> question. ie: How do we organize and arrange menus to maximize discovery
>>> of tools and ease workflow (fewer clicks or faster nav to the correct
>>> tool).
>>>
>>> Analysis or Processing are both fine to me so +0 or maybe Advanced ?
>>>
>>>
>> The issue is more that in plugin manager you see all these strangely named
>> things which don't match their corresponding user interface components...
>>
>> Also users of the API have to deal with these naming ideosychrasies - it
>> would be much nicer to do geoprocessing.* than sextante.*
>>
>>
>> Regards
>>
>> Tim
>>
>>
>>
>>> Thanks,
>>> Alex
>>>
>>> On 08/10/2013 10:53 PM, Saber Razmjooei wrote:
 +1 for changing name.
 I like GRASS menus, it has all the analytical modules under vector and
 raster menu. Can similar thing be done with SEXTANTE?

 Cheers
 Saber

 On 2013-08-10 12:23, Alexander Bruy wrote:
> +1 from me to renaming.
>
> Maybe we can use "Processing" or "GeoProcessing" as new name.
>
> 2013/8/10 Nathan Woodrow :
>> +1 from me too.
>>
>> Personally I find the core plugin concept unnecessary. If it's core it
>> shouldn't be a plugin and should just be part of the main program.
>> It can
>> still be Python that is fine however users shouldn't have to turn
>> them on
>> and off they should just be there and be transparent.
>>
>> IMO we should aim to kill of all C++ core plugins in 2.1 and make
>> them core
>> features.Things like the geometry checking, spatial join,
>>> georeferencer
>> should all be core features and have C++ and Python APIs that the
>> user can
>> use.
>>
>> - Nathan


 --
 This email and any files transmitted with it are confidential and
 intended solely for the use of the individual or entity to whom they are
 addressed. If you have received this email in error please n

Re: [Qgis-developer] Renaming SEXTANTE

[Nathan Woodrow]

Showing SEXTANTE, GDAL Tools, fTools in the menu is the implementation
model leaking into the UI.  The users don't care how it's implemented as
long as it works.

- Nathan


On Mon, Aug 12, 2013 at 9:04 AM, Tim Sutton  wrote:

> Hi
>
>
> On Mon, Aug 12, 2013 at 12:14 AM, Alex Mandel 
> wrote:
>
>> So is the proposal to change Analysis to Processing?
>> I don't think there's a reason to remove the SEXTANTE branding as
>> SEXTANTE does exist outside a QGIS context, ftools is another story
>> since that only exists in QGIS. I'm split on GDAL Tools, since it is
>> good to make sure users know what underlying tool is being used (ie in
>> the event they want to use the command line).
>>
>> As for the Vector, Raster, etc menus... it's expected that over time
>> plugins will sort themselves into those menus in order to add
>> organization and make it more obvious what a tool does. It also makes
>> the generic plugins section smaller so that you don't have to wade
>> through 100 plugins to find the one you want.
>>
>> The same applies for Analysis or Processing, I expect other analysis and
>> processing tools to exist that are not SEXTANTE but end up on the list,
>> in which case being able to tell it apart from what's there remains
>> important.
>>
>> To me this is a UI question, not a core vs. non-core/c++ vs. python
>> question. ie: How do we organize and arrange menus to maximize discovery
>> of tools and ease workflow (fewer clicks or faster nav to the correct
>> tool).
>>
>> Analysis or Processing are both fine to me so +0 or maybe Advanced ?
>>
>>
> The issue is more that in plugin manager you see all these strangely named
> things which don't match their corresponding user interface components...
>
> Also users of the API have to deal with these naming ideosychrasies - it
> would be much nicer to do geoprocessing.* than sextante.*
>
>
> Regards
>
> Tim
>
>
>
>> Thanks,
>> Alex
>>
>> On 08/10/2013 10:53 PM, Saber Razmjooei wrote:
>> > +1 for changing name.
>> > I like GRASS menus, it has all the analytical modules under vector and
>> > raster menu. Can similar thing be done with SEXTANTE?
>> >
>> > Cheers
>> > Saber
>> >
>> > On 2013-08-10 12:23, Alexander Bruy wrote:
>> >> +1 from me to renaming.
>> >>
>> >> Maybe we can use "Processing" or "GeoProcessing" as new name.
>> >>
>> >> 2013/8/10 Nathan Woodrow :
>> >>> +1 from me too.
>> >>>
>> >>> Personally I find the core plugin concept unnecessary. If it's core it
>> >>> shouldn't be a plugin and should just be part of the main program.
>> >>> It can
>> >>> still be Python that is fine however users shouldn't have to turn
>> >>> them on
>> >>> and off they should just be there and be transparent.
>> >>>
>> >>> IMO we should aim to kill of all C++ core plugins in 2.1 and make
>> >>> them core
>> >>> features.Things like the geometry checking, spatial join,
>> georeferencer
>> >>> should all be core features and have C++ and Python APIs that the
>> >>> user can
>> >>> use.
>> >>>
>> >>> - Nathan
>> >
>> >
>> > --
>> > This email and any files transmitted with it are confidential and
>> > intended solely for the use of the individual or entity to whom they are
>> > addressed. If you have received this email in error please notify the
>> > system manager. This message contains confidential information and is
>> > intended only for the individual named. If you are not the named
>> > addressee you should not disseminate, distribute or copy this e-mail.
>> > Please notify the sender immediately by e-mail if you have received this
>> > e-mail by mistake and delete this e-mail from your system. If you are
>> > not the intended recipient you are notified that disclosing, copying,
>> > distributing or taking any action in reliance on the contents of this
>> > information is strictly prohibited.
>> >
>> > Whilst reasonable care has been taken to avoid virus transmission, no
>> > responsibility for viruses is taken and it is your responsibility to
>> > carry out such checks as you feel appropriate.
>> >
>> > Saber Razmjooei and Peter Wells trading as Lutra Consulting.
>> > ___
>> > Qgis-developer mailing list
>> > Qgis-developer@lists.osgeo.org
>> > http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>> ___
>> Qgis-developer mailing list
>> Qgis-developer@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>
>
>
> --
> Tim Sutton - QGIS Project Steering Committee Member (Release  Manager)
> ==
> Please do not email me off-list with technical
> support questions. Using the lists will gain
> more exposure for your issues and the knowledge
> surrounding your issue will be shared with all.
>
> Irc: timlinux on #qgis at freenode.net
> ==
>
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osg

Re: [Qgis-developer] Renaming SEXTANTE

[Tim Sutton]

Hi


On Mon, Aug 12, 2013 at 12:14 AM, Alex Mandel wrote:

> So is the proposal to change Analysis to Processing?
> I don't think there's a reason to remove the SEXTANTE branding as
> SEXTANTE does exist outside a QGIS context, ftools is another story
> since that only exists in QGIS. I'm split on GDAL Tools, since it is
> good to make sure users know what underlying tool is being used (ie in
> the event they want to use the command line).
>
> As for the Vector, Raster, etc menus... it's expected that over time
> plugins will sort themselves into those menus in order to add
> organization and make it more obvious what a tool does. It also makes
> the generic plugins section smaller so that you don't have to wade
> through 100 plugins to find the one you want.
>
> The same applies for Analysis or Processing, I expect other analysis and
> processing tools to exist that are not SEXTANTE but end up on the list,
> in which case being able to tell it apart from what's there remains
> important.
>
> To me this is a UI question, not a core vs. non-core/c++ vs. python
> question. ie: How do we organize and arrange menus to maximize discovery
> of tools and ease workflow (fewer clicks or faster nav to the correct
> tool).
>
> Analysis or Processing are both fine to me so +0 or maybe Advanced ?
>
>
The issue is more that in plugin manager you see all these strangely named
things which don't match their corresponding user interface components...

Also users of the API have to deal with these naming ideosychrasies - it
would be much nicer to do geoprocessing.* than sextante.*


Regards

Tim



> Thanks,
> Alex
>
> On 08/10/2013 10:53 PM, Saber Razmjooei wrote:
> > +1 for changing name.
> > I like GRASS menus, it has all the analytical modules under vector and
> > raster menu. Can similar thing be done with SEXTANTE?
> >
> > Cheers
> > Saber
> >
> > On 2013-08-10 12:23, Alexander Bruy wrote:
> >> +1 from me to renaming.
> >>
> >> Maybe we can use "Processing" or "GeoProcessing" as new name.
> >>
> >> 2013/8/10 Nathan Woodrow :
> >>> +1 from me too.
> >>>
> >>> Personally I find the core plugin concept unnecessary. If it's core it
> >>> shouldn't be a plugin and should just be part of the main program.
> >>> It can
> >>> still be Python that is fine however users shouldn't have to turn
> >>> them on
> >>> and off they should just be there and be transparent.
> >>>
> >>> IMO we should aim to kill of all C++ core plugins in 2.1 and make
> >>> them core
> >>> features.Things like the geometry checking, spatial join, georeferencer
> >>> should all be core features and have C++ and Python APIs that the
> >>> user can
> >>> use.
> >>>
> >>> - Nathan
> >
> >
> > --
> > This email and any files transmitted with it are confidential and
> > intended solely for the use of the individual or entity to whom they are
> > addressed. If you have received this email in error please notify the
> > system manager. This message contains confidential information and is
> > intended only for the individual named. If you are not the named
> > addressee you should not disseminate, distribute or copy this e-mail.
> > Please notify the sender immediately by e-mail if you have received this
> > e-mail by mistake and delete this e-mail from your system. If you are
> > not the intended recipient you are notified that disclosing, copying,
> > distributing or taking any action in reliance on the contents of this
> > information is strictly prohibited.
> >
> > Whilst reasonable care has been taken to avoid virus transmission, no
> > responsibility for viruses is taken and it is your responsibility to
> > carry out such checks as you feel appropriate.
> >
> > Saber Razmjooei and Peter Wells trading as Lutra Consulting.
> > ___
> > Qgis-developer mailing list
> > Qgis-developer@lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>



-- 
Tim Sutton - QGIS Project Steering Committee Member (Release  Manager)
==
Please do not email me off-list with technical
support questions. Using the lists will gain
more exposure for your issues and the knowledge
surrounding your issue will be shared with all.

Irc: timlinux on #qgis at freenode.net
==
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Renaming SEXTANTE

[Tim Sutton]

Hi


On Sat, Aug 10, 2013 at 3:06 AM, Larry Shaffer wrote:

> Hi Victor,
>
> On Fri, Aug 9, 2013 at 11:53 AM, Victor Olaya  wrote:
>
>> Hi
>>
>> After much thinking and considering some suggestions, I think it would
>> be a good idea to remove the SEXTANTE branding, and just have
>> everything with a more descriptive name, such as "geoanalysis",
>> "processing", or something like that. In the long-term, that will help
>> to integrate the analysis framework into QGIS,and help users locate
>> it.
>>
>> It shouldn't be more difficult than just replacing string ocurrences,
>> but before doing such a big (and potentially troublesome) change, I
>> would like to hear the opinion you guys have about this (is it a good
>> idea? what name should we use instead of "sextante" for packages and
>> modules? any good refactoring tool that you recommend?,etc)
>>
>> I am going to be out of office next week, so I might not read my email
>> everyday, but it would be great to hear what you think about it. Once
>> I am back, I will proceed to change it,
>>
>> I discussed it briefly with Tim and Paolo, who agreed on this, so I
>> assumme this is not incompatible with the API freeze and the release
>> plan that we have, but if anyone thinks this shouldn't be done now,
>> please say it. I personally think that it would be good to have it in
>> 2.0, so all analysis stuff is called "analysis" (or whatever) and not
>> with a name that (although I like and feel very identified with it)
>> for most people doesn't make much sense...
>>
>
> Agreed (to the doesn't make much sense to users). +1 from me for this much
> needed approach to the naming of core plugins.
>
> Concerning branding (and with no disrespect to any third-party projects
> brought into core), the brand is not SEXTANTE, not fTools, not GDALTools...
> the brand is QGIS.
>
> Here are some examples of current branding confusion for a user:
>
> * GDALTools, fTools, and SEXTANTE are listed in the Plugin Manager. These
> names are indecipherable to a new user, especially one new to GIS or FOSS4G.
>
> * Once activated, there is no indication that any particular part or
> action of the Vector menu is related to fTools, so it's hard for a user to
> discern core functionality from a plugin's. This is the way core plugins
> should be shown, as part of the app. In this case, however, there is a
> disconnect due to branding.
>
> * The Raster menu has GDALTools settings at the bottom of it. Again, it is
> unclear to which tools these settings apply.
>
> * In the SEXTANTE Toolbox there is a big button at the top, which links to
> a third-party site. While this makes sense for a third-party plugin, it is
> inconsistent with other core tools, and makes it appear the tool is not
> actually a core functionality. A discrete Help button at the bottom of the
> toolbox, that goes to QGIS-related help for the tool makes more sense.
>
> In my opinion, the following core plugins should be renamed to similar
> names as such:
>
> SEXTANTE -> Geoanalysis Tools
> GDALTools -> Raster Tools
> fTools -> Vector Tools
>
> Their icons should be updated to reflect their place and purpose within
> QGIS.
>
> An example of a core plugin that looks and acts like a core plugin to QGIS
> is DB Manager. There is absolutely no disconnect between name, due to
> unnecessary branding, or purpose in the app, to the user. The user clearly
> understands what it is in Plugin Manager and, once activated, the plugin
> blends in nicely as part of the app (though maybe the icon needs updated to
> match newer ones).
>
> This is not to say credit should be ignored. These are considerable
> contributions to the project. The underlying external projects ported to
> core should reasonably be accessible to the user, possibly in the About
> dialog, and possibly with links directly to an external resource for each
> (where appropriate). This should probably be done for providers as well.
>
> Side note: there should probably also be some indication within Plugin
> Manager that a plugin is 'core,' hopefully prompting a user that it is
> something they should not generally consider disabling.
>
> Regards,
>
> Larry
>

100% agreed with your points Larry.

regards

Tim


>
>
>
>> Thanks in advance.
>>
>> Victor
>> ___
>> Qgis-developer mailing list
>> Qgis-developer@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>
>
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>


-- 
Tim Sutton - QGIS Project Steering Committee Member (Release  Manager)
==
Please do not email me off-list with technical
support questions. Using the lists will gain
more exposure for your issues and the knowledge
surrounding your issue will be shared with all.

Irc: timlinux on #qgis at freenode.net

Re: [Qgis-developer] Renaming SEXTANTE

[Victor Olaya]

I wasn't very fond of this idea because or course I like the SEXTANTE
branding itself, but in terms of integration I now think it is better.
For a user that wants to do some analysis, keeping the SEXTANTE name
means that the user has to know that SEXTANTE is an analysis platform,
instead of just being able to look for analysis tools. The menu is
already called "analysis", so actually that's not going to be a big
problem, but then it doesn't make much sense to have named plugins,
specially if it's a core plugin.

I disagree in that it's a good thing to keep names in other plugins or
tools, such as GDAL tools. It looks like a good idea to most of us,
because we *know* what GDAL is. For those that don't (and could find
those tools very useful), "GDAL tools" means nothing. One of the main
goals of the SEXTANTE toolbox is to hide the origin of the algorithms
that are run. The user doesn't need to know if it's GRASS, or SAGA, or
OTB, or it is a native python algorihtm. Advanced users can use the
advanced mode, which shows that, but non-advanced ones (the vast
majority,,,) will find if much easier to just look for the algorithm
that they need.

Thanks a lot for your suggestions!

Cheers
VIctor

2013/8/12 Alex Mandel :
> So is the proposal to change Analysis to Processing?
> I don't think there's a reason to remove the SEXTANTE branding as
> SEXTANTE does exist outside a QGIS context, ftools is another story
> since that only exists in QGIS. I'm split on GDAL Tools, since it is
> good to make sure users know what underlying tool is being used (ie in
> the event they want to use the command line).
>
> As for the Vector, Raster, etc menus... it's expected that over time
> plugins will sort themselves into those menus in order to add
> organization and make it more obvious what a tool does. It also makes
> the generic plugins section smaller so that you don't have to wade
> through 100 plugins to find the one you want.
>
> The same applies for Analysis or Processing, I expect other analysis and
> processing tools to exist that are not SEXTANTE but end up on the list,
> in which case being able to tell it apart from what's there remains
> important.
>
> To me this is a UI question, not a core vs. non-core/c++ vs. python
> question. ie: How do we organize and arrange menus to maximize discovery
> of tools and ease workflow (fewer clicks or faster nav to the correct tool).
>
> Analysis or Processing are both fine to me so +0 or maybe Advanced ?
>
> Thanks,
> Alex
>
> On 08/10/2013 10:53 PM, Saber Razmjooei wrote:
>> +1 for changing name.
>> I like GRASS menus, it has all the analytical modules under vector and
>> raster menu. Can similar thing be done with SEXTANTE?
>>
>> Cheers
>> Saber
>>
>> On 2013-08-10 12:23, Alexander Bruy wrote:
>>> +1 from me to renaming.
>>>
>>> Maybe we can use "Processing" or "GeoProcessing" as new name.
>>>
>>> 2013/8/10 Nathan Woodrow :
 +1 from me too.

 Personally I find the core plugin concept unnecessary. If it's core it
 shouldn't be a plugin and should just be part of the main program.
 It can
 still be Python that is fine however users shouldn't have to turn
 them on
 and off they should just be there and be transparent.

 IMO we should aim to kill of all C++ core plugins in 2.1 and make
 them core
 features.Things like the geometry checking, spatial join, georeferencer
 should all be core features and have C++ and Python APIs that the
 user can
 use.

 - Nathan
>>
>>
>> --
>> This email and any files transmitted with it are confidential and
>> intended solely for the use of the individual or entity to whom they are
>> addressed. If you have received this email in error please notify the
>> system manager. This message contains confidential information and is
>> intended only for the individual named. If you are not the named
>> addressee you should not disseminate, distribute or copy this e-mail.
>> Please notify the sender immediately by e-mail if you have received this
>> e-mail by mistake and delete this e-mail from your system. If you are
>> not the intended recipient you are notified that disclosing, copying,
>> distributing or taking any action in reliance on the contents of this
>> information is strictly prohibited.
>>
>> Whilst reasonable care has been taken to avoid virus transmission, no
>> responsibility for viruses is taken and it is your responsibility to
>> carry out such checks as you feel appropriate.
>>
>> Saber Razmjooei and Peter Wells trading as Lutra Consulting.
>> ___
>> Qgis-developer mailing list
>> Qgis-developer@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
___
Qgis-developer mailing list
Qgis-developer

Re: [Qgis-developer] Renaming SEXTANTE

[Alex Mandel]

So is the proposal to change Analysis to Processing?
I don't think there's a reason to remove the SEXTANTE branding as
SEXTANTE does exist outside a QGIS context, ftools is another story
since that only exists in QGIS. I'm split on GDAL Tools, since it is
good to make sure users know what underlying tool is being used (ie in
the event they want to use the command line).

As for the Vector, Raster, etc menus... it's expected that over time
plugins will sort themselves into those menus in order to add
organization and make it more obvious what a tool does. It also makes
the generic plugins section smaller so that you don't have to wade
through 100 plugins to find the one you want.

The same applies for Analysis or Processing, I expect other analysis and
processing tools to exist that are not SEXTANTE but end up on the list,
in which case being able to tell it apart from what's there remains
important.

To me this is a UI question, not a core vs. non-core/c++ vs. python
question. ie: How do we organize and arrange menus to maximize discovery
of tools and ease workflow (fewer clicks or faster nav to the correct tool).

Analysis or Processing are both fine to me so +0 or maybe Advanced ?

Thanks,
Alex

On 08/10/2013 10:53 PM, Saber Razmjooei wrote:
> +1 for changing name.
> I like GRASS menus, it has all the analytical modules under vector and
> raster menu. Can similar thing be done with SEXTANTE?
> 
> Cheers
> Saber
> 
> On 2013-08-10 12:23, Alexander Bruy wrote:
>> +1 from me to renaming.
>>
>> Maybe we can use "Processing" or "GeoProcessing" as new name.
>>
>> 2013/8/10 Nathan Woodrow :
>>> +1 from me too.
>>>
>>> Personally I find the core plugin concept unnecessary. If it's core it
>>> shouldn't be a plugin and should just be part of the main program. 
>>> It can
>>> still be Python that is fine however users shouldn't have to turn
>>> them on
>>> and off they should just be there and be transparent.
>>>
>>> IMO we should aim to kill of all C++ core plugins in 2.1 and make
>>> them core
>>> features.Things like the geometry checking, spatial join, georeferencer
>>> should all be core features and have C++ and Python APIs that the
>>> user can
>>> use.
>>>
>>> - Nathan
> 
> 
> -- 
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they are
> addressed. If you have received this email in error please notify the
> system manager. This message contains confidential information and is
> intended only for the individual named. If you are not the named
> addressee you should not disseminate, distribute or copy this e-mail.
> Please notify the sender immediately by e-mail if you have received this
> e-mail by mistake and delete this e-mail from your system. If you are
> not the intended recipient you are notified that disclosing, copying,
> distributing or taking any action in reliance on the contents of this
> information is strictly prohibited.
> 
> Whilst reasonable care has been taken to avoid virus transmission, no
> responsibility for viruses is taken and it is your responsibility to
> carry out such checks as you feel appropriate.
> 
> Saber Razmjooei and Peter Wells trading as Lutra Consulting.
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

Re: [Qgis-developer] Renaming SEXTANTE

[Saber Razmjooei]

+1 for changing name.
I like GRASS menus, it has all the analytical modules under vector and 
raster menu. Can similar thing be done with SEXTANTE?


Cheers
Saber

On 2013-08-10 12:23, Alexander Bruy wrote:

+1 from me to renaming.

Maybe we can use "Processing" or "GeoProcessing" as new name.

2013/8/10 Nathan Woodrow :

+1 from me too.

Personally I find the core plugin concept unnecessary. If it's core 
it
shouldn't be a plugin and should just be part of the main program.  
It can
still be Python that is fine however users shouldn't have to turn 
them on

and off they should just be there and be transparent.

IMO we should aim to kill of all C++ core plugins in 2.1 and make 
them core
features.Things like the geometry checking, spatial join, 
georeferencer
should all be core features and have C++ and Python APIs that the 
user can

use.

- Nathan



--
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the 
individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately 
by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified 
that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.


Whilst reasonable care has been taken to avoid virus transmission, no responsibility for viruses is taken and it is your responsibility to carry out 
such checks as you feel appropriate.


Saber Razmjooei and Peter Wells trading as Lutra Consulting.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Renaming SEXTANTE

[Alexander Bruy]

+1 from me to renaming.

Maybe we can use "Processing" or "GeoProcessing" as new name.

2013/8/10 Nathan Woodrow :
> +1 from me too.
>
> Personally I find the core plugin concept unnecessary. If it's core it
> shouldn't be a plugin and should just be part of the main program.  It can
> still be Python that is fine however users shouldn't have to turn them on
> and off they should just be there and be transparent.
>
> IMO we should aim to kill of all C++ core plugins in 2.1 and make them core
> features.Things like the geometry checking, spatial join, georeferencer
> should all be core features and have C++ and Python APIs that the user can
> use.
>
> - Nathan

-- 
Alexander Bruy
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Renaming SEXTANTE

[Nathan Woodrow]

+1 from me too.

Personally I find the core plugin concept unnecessary. If it's core it
shouldn't be a plugin and should just be part of the main program.  It can
still be Python that is fine however users shouldn't have to turn them on
and off they should just be there and be transparent.

IMO we should aim to kill of all C++ core plugins in 2.1 and make them core
features.Things like the geometry checking, spatial join, georeferencer
should all be core features and have C++ and Python APIs that the user can
use.

- Nathan


On Sat, Aug 10, 2013 at 4:37 PM, MORREALE Jean Roc
wrote:

> +1 here for dropping the SEXTANTE name for the same reason we now have a
> Vector menu instead of fTools.
>
> I would vote for a "processing" menu as sextante goes beyond analysis
>
>
> __**_
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/**mailman/listinfo/qgis-**developer
>
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Renaming SEXTANTE

[MORREALE Jean Roc]

+1 here for dropping the SEXTANTE name for the same reason we now have a 
Vector menu instead of fTools.


I would vote for a "processing" menu as sextante goes beyond analysis

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

Re: [Qgis-developer] Renaming SEXTANTE

[Nyall Dawson]

>
> Agreed (to the doesn't make much sense to users). +1 from me for this much
> needed approach to the naming of core plugins.
>
> Concerning branding (and with no disrespect to any third-party projects
> brought into core), the brand is not SEXTANTE, not fTools, not GDALTools...
> the brand is QGIS.
>


> In my opinion, the following core plugins should be renamed to similar
> names as such:
>
> SEXTANTE -> Geoanalysis Tools
> GDALTools -> Raster Tools
> fTools -> Vector Tools
>
> Their icons should be updated to reflect their place and purpose within
> QGIS.
>
>
+1 from me for the name change, and +1 to everything Larry said. Once again
he's captured my thoughts exactly!

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

Re: [Qgis-developer] Renaming SEXTANTE

[Larry Shaffer]

Hi Victor,

On Fri, Aug 9, 2013 at 11:53 AM, Victor Olaya  wrote:

> Hi
>
> After much thinking and considering some suggestions, I think it would
> be a good idea to remove the SEXTANTE branding, and just have
> everything with a more descriptive name, such as "geoanalysis",
> "processing", or something like that. In the long-term, that will help
> to integrate the analysis framework into QGIS,and help users locate
> it.
>
> It shouldn't be more difficult than just replacing string ocurrences,
> but before doing such a big (and potentially troublesome) change, I
> would like to hear the opinion you guys have about this (is it a good
> idea? what name should we use instead of "sextante" for packages and
> modules? any good refactoring tool that you recommend?,etc)
>
> I am going to be out of office next week, so I might not read my email
> everyday, but it would be great to hear what you think about it. Once
> I am back, I will proceed to change it,
>
> I discussed it briefly with Tim and Paolo, who agreed on this, so I
> assumme this is not incompatible with the API freeze and the release
> plan that we have, but if anyone thinks this shouldn't be done now,
> please say it. I personally think that it would be good to have it in
> 2.0, so all analysis stuff is called "analysis" (or whatever) and not
> with a name that (although I like and feel very identified with it)
> for most people doesn't make much sense...
>

Agreed (to the doesn't make much sense to users). +1 from me for this much
needed approach to the naming of core plugins.

Concerning branding (and with no disrespect to any third-party projects
brought into core), the brand is not SEXTANTE, not fTools, not GDALTools...
the brand is QGIS.

Here are some examples of current branding confusion for a user:

* GDALTools, fTools, and SEXTANTE are listed in the Plugin Manager. These
names are indecipherable to a new user, especially one new to GIS or FOSS4G.

* Once activated, there is no indication that any particular part or action
of the Vector menu is related to fTools, so it's hard for a user to discern
core functionality from a plugin's. This is the way core plugins should be
shown, as part of the app. In this case, however, there is a disconnect due
to branding.

* The Raster menu has GDALTools settings at the bottom of it. Again, it is
unclear to which tools these settings apply.

* In the SEXTANTE Toolbox there is a big button at the top, which links to
a third-party site. While this makes sense for a third-party plugin, it is
inconsistent with other core tools, and makes it appear the tool is not
actually a core functionality. A discrete Help button at the bottom of the
toolbox, that goes to QGIS-related help for the tool makes more sense.

In my opinion, the following core plugins should be renamed to similar
names as such:

SEXTANTE -> Geoanalysis Tools
GDALTools -> Raster Tools
fTools -> Vector Tools

Their icons should be updated to reflect their place and purpose within
QGIS.

An example of a core plugin that looks and acts like a core plugin to QGIS
is DB Manager. There is absolutely no disconnect between name, due to
unnecessary branding, or purpose in the app, to the user. The user clearly
understands what it is in Plugin Manager and, once activated, the plugin
blends in nicely as part of the app (though maybe the icon needs updated to
match newer ones).

This is not to say credit should be ignored. These are considerable
contributions to the project. The underlying external projects ported to
core should reasonably be accessible to the user, possibly in the About
dialog, and possibly with links directly to an external resource for each
(where appropriate). This should probably be done for providers as well.

Side note: there should probably also be some indication within Plugin
Manager that a plugin is 'core,' hopefully prompting a user that it is
something they should not generally consider disabling.

Regards,

Larry



> Thanks in advance.
>
> Victor
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Renaming SEXTANTE

[Antonio Locandro]

I have to agree with this, Sextante has become a very recognizable "brand" I 
feel renaming it doesn't really bring any real benefit and users already know 
Sextante will be doing Analysis, my two cents with this

Antonio Locandro





 
Date: Fri, 9 Aug 2013 20:00:25 +0100
From: filipesd...@gmail.com
To: vola...@gmail.com
CC: qgis-developer@lists.osgeo.org
Subject: Re: [Qgis-developer] Renaming SEXTANTE

Hi,Many people refer to "Vector" and "Raster" tools as Ftools and GDAL. 
Sextante, in my opinion, is not different, so I dont see why we should change 
anything. The Sextante menu is called "Analysis" which makes sense. And 
Sextante toolbox seems to be a good name, as well as Sextante Modeler.

Additionally, Sextante is a recognizable name for gvsig and Arcgis users. 
Considering that we can expect that a lot more users are going to start using 
QGIS after 2.0 is released, it would make sense the keep the Sextante naming

Best regardsF.

On Fri, Aug 9, 2013 at 6:53 PM, Victor Olaya  wrote:

Hi



After much thinking and considering some suggestions, I think it would

be a good idea to remove the SEXTANTE branding, and just have

everything with a more descriptive name, such as "geoanalysis",

"processing", or something like that. In the long-term, that will help

to integrate the analysis framework into QGIS,and help users locate

it.



It shouldn't be more difficult than just replacing string ocurrences,

but before doing such a big (and potentially troublesome) change, I

would like to hear the opinion you guys have about this (is it a good

idea? what name should we use instead of "sextante" for packages and

modules? any good refactoring tool that you recommend?,etc)



I am going to be out of office next week, so I might not read my email

everyday, but it would be great to hear what you think about it. Once

I am back, I will proceed to change it,



I discussed it briefly with Tim and Paolo, who agreed on this, so I

assumme this is not incompatible with the API freeze and the release

plan that we have, but if anyone thinks this shouldn't be done now,

please say it. I personally think that it would be good to have it in

2.0, so all analysis stuff is called "analysis" (or whatever) and not

with a name that (although I like and feel very identified with it)

for most people doesn't make much sense...



Thanks in advance.



Victor

___

Qgis-developer mailing list

Qgis-developer@lists.osgeo.org

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




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

Re: [Qgis-developer] Renaming SEXTANTE

[Filipe Dias]

Hi,
Many people refer to "Vector" and "Raster" tools as Ftools and GDAL.
Sextante, in my opinion, is not different, so I dont see why we should
change anything. The Sextante menu is called "Analysis" which makes sense.
And Sextante toolbox seems to be a good name, as well as Sextante Modeler.

Additionally, Sextante is a recognizable name for gvsig and Arcgis users.
Considering that we can expect that a lot more users are going to start
using QGIS after 2.0 is released, it would make sense the keep the Sextante
naming

Best regards
F.


On Fri, Aug 9, 2013 at 6:53 PM, Victor Olaya  wrote:

> Hi
>
> After much thinking and considering some suggestions, I think it would
> be a good idea to remove the SEXTANTE branding, and just have
> everything with a more descriptive name, such as "geoanalysis",
> "processing", or something like that. In the long-term, that will help
> to integrate the analysis framework into QGIS,and help users locate
> it.
>
> It shouldn't be more difficult than just replacing string ocurrences,
> but before doing such a big (and potentially troublesome) change, I
> would like to hear the opinion you guys have about this (is it a good
> idea? what name should we use instead of "sextante" for packages and
> modules? any good refactoring tool that you recommend?,etc)
>
> I am going to be out of office next week, so I might not read my email
> everyday, but it would be great to hear what you think about it. Once
> I am back, I will proceed to change it,
>
> I discussed it briefly with Tim and Paolo, who agreed on this, so I
> assumme this is not incompatible with the API freeze and the release
> plan that we have, but if anyone thinks this shouldn't be done now,
> please say it. I personally think that it would be good to have it in
> 2.0, so all analysis stuff is called "analysis" (or whatever) and not
> with a name that (although I like and feel very identified with it)
> for most people doesn't make much sense...
>
> Thanks in advance.
>
> Victor
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Renaming SEXTANTE

[Victor Olaya]

Hi

After much thinking and considering some suggestions, I think it would
be a good idea to remove the SEXTANTE branding, and just have
everything with a more descriptive name, such as "geoanalysis",
"processing", or something like that. In the long-term, that will help
to integrate the analysis framework into QGIS,and help users locate
it.

It shouldn't be more difficult than just replacing string ocurrences,
but before doing such a big (and potentially troublesome) change, I
would like to hear the opinion you guys have about this (is it a good
idea? what name should we use instead of "sextante" for packages and
modules? any good refactoring tool that you recommend?,etc)

I am going to be out of office next week, so I might not read my email
everyday, but it would be great to hear what you think about it. Once
I am back, I will proceed to change it,

I discussed it briefly with Tim and Paolo, who agreed on this, so I
assumme this is not incompatible with the API freeze and the release
plan that we have, but if anyone thinks this shouldn't be done now,
please say it. I personally think that it would be good to have it in
2.0, so all analysis stuff is called "analysis" (or whatever) and not
with a name that (although I like and feel very identified with it)
for most people doesn't make much sense...

Thanks in advance.

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