[Qgis-developer] Renaming SEXTANTE
Alex Mandel
tech_dev at wildintellect.com
Sun Aug 11 16:59:35 PDT 2013
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 <lists at linfiniti.com> wrote:
>
>> Hi
>>
>>
>> On Mon, Aug 12, 2013 at 12:14 AM, Alex Mandel <tech_dev at wildintellect.com>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 <madmanwoo at gmail.com>:
>>>>>> +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 at lists.osgeo.org
>>>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>>
>>> _______________________________________________
>>> Qgis-developer mailing list
>>> Qgis-developer at 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 at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>>
>
>
>
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
More information about the Qgis-developer
mailing list