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

[Markus Metz]

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:
>>> On 18 February 2013 15:34, Martin Landa <landa.martin at gmail.com> wrote:
>>>> Hi,
>>>>
>>>> 2013/2/18 Anna Kratochvílová <kratochanna at gmail.com>:
>>>>> I think there is no reason for that. Also, this g.mapsets -s is not
>>>>> really consistent with the new g.gui.modules. What about
>>>>> g.gui.mapsets? Or if we want to keep the flag -s, the code should be
>>>>> at least on one place.
>>>>
>>>> this `-s` flag is a historical artefact from G6 - `g.mapsets -s`
>>>> originally launch TCL/TK dialog (if GUI is TCL/TK). Having `g.gui.*`
>>>> modules, `g.gui.mapsets` makes probably more sense (drawback: one more
>>>> module introduced, backward compatibility broken - 's' flag removed)
>>>> than `g.mapsets -s`. In any case, code should be on one place, of
>>>> course.
>>>>
>>>
>>> Hi,
>>>
>>> we can ignore backward compatibility issue if we decide that mixing
>>> modules with and without gui is simply wrong (I vote for non-mixing
>>> but we can do some wider discussion on that topic, of course).
>>>
>>> I'm afraid that we are not able to keep the number of g.gui.* modules small.
>>>
>>> For me the drawback is that as a user I have to thing about two
>>> different mapset modules. Generally speaking, there is no rule to
>>> determine which functionality is provided by the g.mapset(s) module
>>> and which by g.gui.mapset(s) module.
>>>
>> Adding some confusion:
>>
>> There is gui/wxpython/modules which holds gui interfaces to modules,
>> but not modules itself. Other customized interfaces are in
>> gui/wxpython/gui_core. These have no additional functionality, the
>> reason for their existence is mainly that the automatically generated
>> gui is less powerful than the cli. The g.gui.* modules are apparently
>> distributed in several subfolders of gui/wxpython/.
>>
>> 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.
>
> 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.
>
>> The g.gui.* naming
>> should IMHO be reserved exclusively for modules that require a GUI
>> like e.g. g.gui.mapswipe.
>
>>
>> Alternatively, gui/wxpython/gui_core/forms.py could be modified to use
>> a customized interface if it exists for a given module, defined as
>> handler in gui/wxpython/gui_core/xml/menudata.xml which in turn is
>> parsed by gui/wxpython/core/menudata.py, the handler itself is defined
>> in gui/wxpython/lmgr/frame.py. Can the handlers be moved to forms.py?
>>
> Show customized instead of generated, interesting. The handlers in
> lmgr/frame.py are subject to refactoring and even more, they might be
> connected to toolbox concept. I will try to keep this in mind.

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.

>
> This thread should turned into a article on Trac wiki.

+1

> Putting this > into my todo.

Thanks!

Markus M