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

[Vaclav Petras]

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.

This thread should turned into a article on Trac wiki. Putting this
into my todo.

> Markus M