Renaming SEXTANTE

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Renaming SEXTANTE

volaya
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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Renaming SEXTANTE

Filipe Dias-2
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 <[hidden email]> 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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer


_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Renaming SEXTANTE

AntonioLocandro
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: [hidden email]
To: [hidden email]
CC: [hidden email]
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 regards
F.


On Fri, Aug 9, 2013 at 6:53 PM, Victor Olaya <[hidden email]> 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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer


_______________________________________________ Qgis-developer mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/qgis-developer

_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Renaming SEXTANTE

Larry_S
In reply to this post by volaya
Hi Victor,

On Fri, Aug 9, 2013 at 11:53 AM, Victor Olaya <[hidden email]> 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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer


_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: 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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Renaming SEXTANTE

Jean-Roc Morreale
In reply to this post by Larry_S
+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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer


_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Renaming SEXTANTE

Alexander Bruy
+1 from me to renaming.

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

2013/8/10 Nathan Woodrow <[hidden email]>:

> +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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]>:
>> +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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Renaming SEXTANTE

Alex Mandel-2
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 <[hidden email]>:
>>> +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
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/qgis-developer

_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Renaming SEXTANTE

volaya
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 <[hidden email]>:

> 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 <[hidden email]>:
>>>> +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
>> [hidden email]
>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
> _______________________________________________
> Qgis-developer mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Renaming SEXTANTE

Tim Sutton-4
In reply to this post by Larry_S
Hi


On Sat, Aug 10, 2013 at 3:06 AM, Larry Shaffer <[hidden email]> wrote:
Hi Victor,

On Fri, Aug 9, 2013 at 11:53 AM, Victor Olaya <[hidden email]> 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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer


_______________________________________________
Qgis-developer mailing list
[hidden email]
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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Renaming SEXTANTE

Tim Sutton-4
In reply to this post by Alex Mandel-2
Hi


On Mon, Aug 12, 2013 at 12:14 AM, Alex Mandel <[hidden email]> 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 <[hidden email]>:
>>> +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
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/qgis-developer

_______________________________________________
Qgis-developer mailing list
[hidden email]
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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> wrote:
Hi


On Mon, Aug 12, 2013 at 12:14 AM, Alex Mandel <[hidden email]> 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 <[hidden email]>:
>>> +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
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/qgis-developer

_______________________________________________
Qgis-developer mailing list
[hidden email]
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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer



_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Renaming SEXTANTE

Alex Mandel-2
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 <[hidden email]> wrote:
>
>> Hi
>>
>>
>> On Mon, Aug 12, 2013 at 12:14 AM, Alex Mandel <[hidden email]>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 <[hidden email]>:
>>>>>> +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
>>>> [hidden email]
>>>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>>
>>> _______________________________________________
>>> Qgis-developer mailing list
>>> [hidden email]
>>> 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
>> [hidden email]
>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>>
>
>
>
> _______________________________________________
> Qgis-developer mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>

_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Renaming SEXTANTE

Marco Hugentobler-4
In reply to this post by Nathan Woodrow
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 <[hidden email]> 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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer



_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer


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

_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Renaming SEXTANTE

pcav
-----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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Renaming SEXTANTE

Nathan Woodrow
In reply to this post by Marco Hugentobler-4
On Mon, Aug 12, 2013 at 5:13 PM, Marco Hugentobler <[hidden email]> 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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Renaming SEXTANTE

Anita Graser
In reply to this post by volaya
On Mon, Aug 12, 2013 at 12:36 AM, Victor Olaya <[hidden email]> 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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Renaming SEXTANTE

Tim Sutton-4
In reply to this post by Nathan Woodrow
Hi


On Mon, Aug 12, 2013 at 9:32 AM, Nathan Woodrow <[hidden email]> wrote:
On Mon, Aug 12, 2013 at 5:13 PM, Marco Hugentobler <[hidden email]> 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
[hidden email]
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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
12