[GRASS-dev] Additional switch(es) for <g.mapsets>?

[Markus Metz]

On Tue, Feb 19, 2013 at 1:14 PM, Anna Kratochvílová
<kratochanna at gmail.com> wrote:
> On Tue, Feb 19, 2013 at 1:07 PM, Markus Metz
> <markus.metz.giswork at gmail.com> wrote:
>> On Tue, Feb 19, 2013 at 11:25 AM, Markus Neteler <neteler at osgeo.org> wrote:
>>> On Mon, Feb 18, 2013 at 11:03 PM, Markus Metz
>>> <markus.metz.giswork at gmail.com> wrote:
>>>> On Mon, Feb 18, 2013 at 10:39 PM, Vaclav Petras <wenzeslaus at gmail.com> wrote:
>>>>> On 18 February 2013 20:08, Markus Metz <markus.metz.giswork at gmail.com> wrote:
>>>>>> On Mon, Feb 18, 2013 at 6:51 PM, Vaclav Petras <wenzeslaus at gmail.com> wrote:
>>> ...
>>>>>> Since the -s flag does not add new functionality to g.mapsets, I would
>>>>>> strongly opt to remove the -s flag.
>>>>>
>>>>>> If you want to use the customized gui interface for
>>>>>> r.in.gdal/v.in.ogr/r.colors/v.clean/i.group/g.mapsets etc, use the gui
>>>>>> menu.
>>>>>> Otherwise, you can use the command line.
>>>
>>> This makes perfect sense: i.e. g.mapsets fired up from cmd line
>>> without anything pops up the nice related g.mapsets gui window.
>>>
>>>>> But still there are some power users which would like to avoid
>>>>> starting the main big GUI. Personally, I like the idea of accessing
>>>>> anything in the gui from command line (one reason is that it helps to
>>>>> reduce dependencies in the gui code).
>>>>>
>>>>> One solution would be run gui for modules such as r.in.gdal by some
>>>>> gui starter command which would accept the module name as a parameter;
>>>>> it is something like command line menu (g.gui.climenu). This was
>>>>> proposed for the g.gui.* in order to avoid having many new modules or
>>>>> to avoid the new kind of modules.
>>>
>>> +1
>>
>> I don't think you need another gui starter command. What the parser is
>> doing right now is sufficient. The parser calls
>> gui/wxpython/gui_core/forms.py which in turn brings up the appropriate
>> interface. The only modification that is needed is make forms.py bring
>> up the customized interface. This solution would not require a special
>> flag and no special gui starter command. You would then fire up a
>> module from the command line without arguments and get the same
>> interface like when calling it from the gui menu.
>
> In some cases, the auto-generated form is also useful, for example the
> gui interface for r.colors is created specifically for defining rules,
> however for setting ready color table the generated form is more
> suitable. So can we keep somehow the option to launch the generated
> form (e.g. --ui)?

In this particular case, the autogenerated gui would be called for
r.colors. See handler for r.colors in menudata.xml. That is, it would
behave as you suggest. Forms.py would just need to use the handler
defined in menudata.xml for the given module. The GUI interface to
create custom color rules is not defined as a handler for r.colors.

Markus M

>
> Anna
>
>>
>> Markus M
>>
>>>
>>> ...
>>>> I am not sure if this needs emphasizing, but the customized GUI
>>>> interfaces already exist. The idea here is to call the already
>>>> existing customized interface for a given module, e.g.
>>>> r.in.gdal/v.in.ogr/r.colors/v.clean/i.group/g.mapsets etc. No funny
>>>> flag needed in the module.
>>>
>>> Much agreed :)
>>>
>>> markusN
>> _______________________________________________
>> grass-dev mailing list
>> grass-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-dev