On Mon, Feb 18, 2013 at 10:39 PM, Vaclav Petras <wenzesl...@gmail.com> wrote: > On 18 February 2013 20:08, Markus Metz <markus.metz.gisw...@gmail.com> wrote: >> On Mon, Feb 18, 2013 at 6:51 PM, Vaclav Petras <wenzesl...@gmail.com> wrote: >>> On 18 February 2013 15:34, Martin Landa <landa.mar...@gmail.com> wrote: >>>> Hi, >>>> >>>> 2013/2/18 Anna Kratochvílová <kratocha...@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 _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
