Hi list.
Working with version=7.0.svn, revision=57486M here. It seems the option to
create a subgroup is missing from:
Imagery > Develop images and groups > Create/edit group [i.group]
Best regards, Nikos
Confirmed that the option does not work in the gui, but does work on the command line. Have you filed a ticket?
Doug
···
On Wed, Sep 11, 2013 at 5:35 AM, Nikos Alexandris <nik@nikosalexandris.net> wrote:
Hi list.
Working with version=7.0.svn, revision=57486M here. It seems the option to
create a subgroup is missing from:Imagery > Develop images and groups > Create/edit group [i.group]
Best regards, Nikos
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
–
Doug Newcomb
USFWS
Raleigh, NC
919-856-4520 ext. 14 doug_newcomb@fws.gov
The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats.
On 11/09/13 14:53, Newcomb, Doug wrote:
Confirmed that the option does not work in the gui, but does work on the
command line. Have you filed a ticket?
This seems like another example of a gui wizard providing less than the original module and the gui of the module becoming unaccessible via the menus (cf also https://trac.osgeo.org/grass/ticket/2042).
I do think that we should have a more general debate about how to handle these issues. Personally, I'm very strongly opposed to this tendency of "dumbing-down" the GUI menus. I have nothing against wizards, but I think they should be an additional feature, not a replacing features.
Moritz
On Wednesday 11 of September 2013 08:53:24 you wrote:
Confirmed that the option does not work in the gui, but does work on the
command line. Have you filed a ticket?
Not yet. Thaks for (re-)checking,
Nikos
Moritz wrote:
I do think that we should have a more general debate about how to handle
these issues. Personally, I'm very strongly opposed to this tendency of
"dumbing-down" the GUI menus. I have nothing against wizards, but I
think they should be an additional feature, not a replacing features.
Hi,
I don't think it needs a big debate, just a bit of finesse in the execution.
For example I think the Cartographic Composer tool does a nice job of hiding
the ps.map module GUI dialog behind a conceptual "Advanced" button using
its menu placement. New users would probably ignore the menu item not
knowing what it did; seasoned users would recognize what it was and use it
as needed, but for them too it wouldn't be cluttering up for normal use.
An example I keep coming back to is wrapper-subset scripts for d.vect (*see g6
addons d.stations, d.varea, and ~d.mark), since the main GUI controls begin
to resemble the complication of a Boeing 747 cockpit. Simplification in and
of itself is not always a bad thing.
wrt the steepness of the learning curve, I don't think you should have to know
the name of a module to launch its GUI (ie from the command line) instead of a
wizard, but the wizard should gently teach you the name of the module. For
me this was the self-assembling command lines at the bottom of the grass5
tcltkgrass module GUIs.
wrt r.import and r.export as fancy g.GUI wizards and r.{in|out}.gdal as
advanced full module dialog GUIs, the idea sounds nice to me.
regards,
Hamish