#2042: wxgui: no more menu access to r.in.gdal / v.in.ogr
------------------------------------+---------------------------------------
Reporter: mlennert | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: wxGUI | Version: svn-trunk
Keywords: r.in.gdal v.in.ogr gui | Platform: Unspecified
Cpu: Unspecified |
------------------------------------+---------------------------------------
In GRASS 6, when you use the File->Import raster data->Common formats
import wizard frontend to r.in.gdal (or its equivalent for v.in.ogr), you
have a button that allows you to launch the actual module GUI, instead of
the wizard frontend.
In GRASS7 that button has disappeared. Why ? Now the user cannot reach
that module gui via the menus anymore, but only by typing the module name
in the terminal or console. I find this a regression as sometimes, being
able to switch to the module gui is helpful.
IMO there should always be a small button or submenu to get to the raw
module UI interface from the front-end wizards without having to use the
command line; nice for experts, old timers, or to work around some other
breakage in the wizards & debugging.
as long as it is well worded it should not be confusing.
#2042: wxgui: no more menu access to r.in.gdal / v.in.ogr
--------------------------------------+-------------------------------------
Reporter: mlennert | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: wxGUI | Version: svn-trunk
Keywords: r.in.gdal, v.in.ogr, gui | Platform: Unspecified
Cpu: Unspecified |
--------------------------------------+-------------------------------------
Comment(by martinl):
Replying to [comment:1 annakrat]:
> The button was removed in r54618. I don't have any strong opinion on
this. Perhaps the button might be confusing for users?
I would say that this button can be confusing to the normal user. Advanced
users can launch r.in.gdal's autogenerated dialog from wxGUI command
prompt by running `r.in.gdal --ui`.
#2042: wxgui: no more menu access to r.in.gdal / v.in.ogr
--------------------------------------+-------------------------------------
Reporter: mlennert | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: wxGUI | Version: svn-trunk
Keywords: r.in.gdal, v.in.ogr, gui | Platform: Unspecified
Cpu: Unspecified |
--------------------------------------+-------------------------------------
Comment(by martinl):
Replying to [comment:3 martinl]:
> Replying to [comment:1 annakrat]:
> > The button was removed in r54618. I don't have any strong opinion on
this. Perhaps the button might be confusing for users?
>
> I would say that this button can be confusing to the normal user.
Advanced users can launch r.in.gdal's autogenerated dialog from wxGUI
command prompt by running `r.in.gdal --ui`.
Moreover running `r.in.gdal` from wxGUI command line should also launch
GUI front-end. The autogenerated dialog should appear only when `--ui`
switch is used. Similarly for the other modules which have special
frontend, e.g. `i.group`. From my personal experience, the user in the
class were very confused when they got different GUI dialog when running
`i.group` from the menu and command prompt.
#2042: wxgui: no more menu access to r.in.gdal / v.in.ogr
--------------------------------------+-------------------------------------
Reporter: mlennert | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: wxGUI | Version: svn-trunk
Keywords: r.in.gdal, v.in.ogr, gui | Platform: Unspecified
Cpu: Unspecified |
--------------------------------------+-------------------------------------
Comment(by hamish):
As long at the button is worded correctly and put in an appropriate place,
it doesn't have to be confusing. Putting it along side as a menu item
might be confusing for sure. Typing 'r.in.gdal --ui' (//are you saying
that just 'r.in.gdal' will not cause the module GUI to open?) from a
command prompt requires prior knowledge of the module's name and knowing
how to do that. Neither is inherently "discoverable" or self-documenting.
The --ui trick is hardly widely known outside of the development team.
see also the cartographic composer's way of launching the ps.map dialog
from the File menu. It's there if you want/need it, but not likely to
confuse new users.
> Similarly for the other modules which have special frontend, e.g.
> i.group. From my personal experience, the user in the class were
> very confused when they got different GUI dialog when running
> i.group from the menu and command prompt.
I would suggest the solution there is different wording titlebar etc text
in the wizard version. i.e. give them better hints along the way to guide
their expectations. (easier said than done of course)
#2042: wxgui: no more menu access to r.in.gdal / v.in.ogr
--------------------------------------+-------------------------------------
Reporter: mlennert | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: wxGUI | Version: svn-trunk
Keywords: r.in.gdal, v.in.ogr, gui | Platform: Unspecified
Cpu: Unspecified |
--------------------------------------+-------------------------------------
Comment(by hamish):
Replying to [comment:4 martinl]:
> Moreover running `r.in.gdal` from wxGUI command line should also launch
GUI
> front-end. The autogenerated dialog should appear only when `--ui`
switch is used.
Oh, I understand what you are saying now. And very much disagree -- if a
user runs 'r.in.gdal' they should get the real r.in.gdal. They are not
going to type/guess that name by mistake. If the GUI-wizard version is
presenting itself by that name, then the trouble is there.
Or do it like 'g.mapsets -s' to launch the extra GUI. (I don't think
that's a wonderful solution either, but..)
I'm not excited about the following name, but if it's a wizard perhaps use
a different name like "g.gui.raster_import" or some other way to start it,
then let the users of the GUI get used to that name.
or maybe "g.gui launch=raster_import"
or "g.gui wizard=raster_import"
or "g.gui.wizard raster_import" ??
#2042: wxgui: no more menu access to r.in.gdal / v.in.ogr
--------------------------------------+-------------------------------------
Reporter: mlennert | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: wxGUI | Version: svn-trunk
Keywords: r.in.gdal, v.in.ogr, gui | Platform: Unspecified
Cpu: Unspecified |
--------------------------------------+-------------------------------------
Comment(by martinl):
Replying to [comment:5 hamish]:
> As long at the button is worded correctly and put in an appropriate
place, it doesn't have to be confusing.
I am not sure about that. Moreover I can hardly say that the place was
really appropriate. I would say opposite.
> Putting it along side as a menu item might be confusing for sure. Typing
'r.in.gdal --ui' (//are you saying that just 'r.in.gdal' will not cause
the module GUI to open?) from a command prompt requires prior knowledge of
the module's name and knowing how to do that. Neither is inherently
"discoverable" or self-documenting. The --ui trick is hardly widely known
outside of the development team.
I can hardly imagine normal user who prefer autogenerated dialog rather
then more user friendly front-end. Most probably if you prefer
autogenerated dialog you are advanced user who knows how to lunch a
command from command line. The easiest think is to document it.
> see also the cartographic composer's way of launching the ps.map dialog
from the File menu. It's there if you want/need it, but not likely to
confuse new users.
>
>
> > Similarly for the other modules which have special frontend, e.g.
> > i.group. From my personal experience, the user in the class were
> > very confused when they got different GUI dialog when running
> > i.group from the menu and command prompt.
>
> I would suggest the solution there is different wording titlebar etc
text in the wizard version. i.e. give them better hints along the way to
guide their expectations. (easier said than done of course)
But these dialogs are not "wizards". Since most users will use front-ends
and they will happily live without knowing about autogenerated dialogs I
don't feel that we need to show this functionality so much. There must be
a way how to launch autogenerated dialogs, in the best case the same for
all commands which have front-ends. From this point of view `--ui` seems
to be better then putting buttons somewhere. The simple the better. Trying
to find a sense in launching front-end and from the front-end launching
autogenerated dialog. How many user will use it and how many of them will
be simply confused?
#2042: wxgui: no more menu access to r.in.gdal / v.in.ogr
--------------------------------------+-------------------------------------
Reporter: mlennert | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: wxGUI | Version: svn-trunk
Keywords: r.in.gdal, v.in.ogr, gui | Platform: Unspecified
Cpu: Unspecified |
--------------------------------------+-------------------------------------
Comment(by martinl):
Replying to [comment:6 hamish]:
> Replying to [comment:4 martinl]:
> > Moreover running `r.in.gdal` from wxGUI command line should also
launch GUI
> > front-end. The autogenerated dialog should appear only when `--ui`
switch is used.
>
> Oh, I understand what you are saying now. And very much disagree -- if a
user runs 'r.in.gdal' they should get the real r.in.gdal. They are not
going to type/guess that name by mistake. If the GUI-wizard version is
presenting itself by that name, then the trouble is there.
HUH, it was the main issue where the students in my class have problems
every year. Users can hardly understand that they get *different* dialog
from the menu and wxGUI command line. Bear in mind, that I speak about
wxGUI command line and not the terminal!
> Or do it like 'g.mapsets -s' to launch the extra GUI. (I don't think
that's a wonderful solution either, but..)
This kind of switches doesn't make sense to me. Moreover I would do the
step forward. Launch front-ends from terminal too (when no parameter is
given), `--ui` would force autogenerated dialog similarly to wxGUI command
console.
Let's try to do steps towards the user. Everyone of us has his/her
specific way of working.
#2042: wxgui: no more menu access to r.in.gdal / v.in.ogr
--------------------------------------+-------------------------------------
Reporter: mlennert | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: wxGUI | Version: svn-trunk
Keywords: r.in.gdal, v.in.ogr, gui | Platform: Unspecified
Cpu: Unspecified |
--------------------------------------+-------------------------------------
Comment(by wenzeslaus):
Replying to [comment:6 hamish]:
> Or do it like 'g.mapsets -s' to launch the extra GUI. (I don't think
that's a wonderful solution either, but..)
>
> I'm not excited about the following name, but if it's a wizard perhaps
use a different name like "g.gui.raster_import" or some other way to start
it, then let the users of the GUI get used to that name.
> or maybe "g.gui launch=raster_import"
> or "g.gui wizard=raster_import"
> or "g.gui.wizard raster_import" ??
>
This was discussed on the ML some time ago:
* [http://lists.osgeo.org/pipermail/grass-user/2012-November/066144.html
new `g.gui.` modules] ([http://osgeo-org.1560.x6.nabble.com/new-g-gui-
modules-td5015150.html nabble])
#2042: wxgui: no more menu access to r.in.gdal / v.in.ogr
--------------------------------------+-------------------------------------
Reporter: mlennert | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: wxGUI | Version: svn-trunk
Keywords: r.in.gdal, v.in.ogr, gui | Platform: Unspecified
Cpu: Unspecified |
--------------------------------------+-------------------------------------
Comment(by martinl):
Replying to [comment:10 hamish]:
> For r.{in,out}.gdal might I suggest to revive the idea of using the name
"r.import" and "r.export", and have those launch the GUI front-end.
right, it would also fits `[r|v].external[.out]` modules. +1 for that.
> Keep the front ends and the backends separate. Let the backend simply do
its "one thing well".
Probably I missed something. Anybody here is doing something else?
#2042: wxgui: no more menu access to r.in.gdal / v.in.ogr
--------------------------------------+-------------------------------------
Reporter: mlennert | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: wxGUI | Version: svn-trunk
Keywords: r.in.gdal, v.in.ogr, gui | Platform: Unspecified
Cpu: Unspecified |
--------------------------------------+-------------------------------------
Comment(by wenzeslaus):
Replying to [comment:11 martinl]:
> Replying to [comment:10 hamish]:
> > For r.{in,out}.gdal might I suggest to revive the idea of using the
name "r.import" and "r.export", and have those launch the GUI front-end.
>
> right, it would also fits `[r|v].external[.out]` modules. +1 for that.
>
Do you mean `[r|v].import` to be GUI-only module? If yes, note that this
would be the first case in GRASS 7 when the module has only GUI and there
is no non-GUI functionality. For example `i.class` was the same case in
GRASS 6 (GUI-only module) and the new wxGUI port of `i.class` was named
`g.gui.iclass` to explicitly say that it is GUI-only.
#2042: wxgui: no more menu access to r.in.gdal / v.in.ogr
--------------------------------------+-------------------------------------
Reporter: mlennert | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: wxGUI | Version: svn-trunk
Keywords: r.in.gdal, v.in.ogr, gui | Platform: Unspecified
Cpu: Unspecified |
--------------------------------------+-------------------------------------
Comment(by martinl):
Replying to [comment:12 wenzeslaus]:
> Replying to [comment:11 martinl]:
> > Replying to [comment:10 hamish]:
> > > For r.{in,out}.gdal might I suggest to revive the idea of using the
name "r.import" and "r.export", and have those launch the GUI front-end.
> >
> > right, it would also fits `[r|v].external[.out]` modules. +1 for that.
> >
> Do you mean `[r|v].import` to be GUI-only module? If yes, note that this
would be the first case in GRASS 7 when the module has only GUI and there
is no non-GUI functionality. For example `i.class` was the same case in
GRASS 6 (GUI-only module) and the new wxGUI port of `i.class` was named
`g.gui.iclass` to explicitly say that it is GUI-only.
#2042: wxgui: no more menu access to r.in.gdal / v.in.ogr
--------------------------------------+-------------------------------------
Reporter: mlennert | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: wxGUI | Version: svn-trunk
Keywords: r.in.gdal, v.in.ogr, gui | Platform: Unspecified
Cpu: Unspecified |
--------------------------------------+-------------------------------------
Comment(by mmetz):
Replying to [comment:13 martinl]:
>
> I thought that we are speaking about renaming
>
> * r.in.gdal -> r.import
> * v.in.ogr -> v.import
> * r.out.gdal -> r.export
> * v.out.ogr -> v.export
>
Considering that the wxGUI interface to r.in.gdal/v.in.ogr does not handle
the GDAL/OGR mapping of input bands(raster) / layers(vector) to
files/directories/databases while GDAL/OGR does, because this mapping is
format-specific, I would suggest to keep r.in.gdal and v.in.ogr as they
are and introduce new wxGUI-specific modules r.import/v.import, or
g.gui.r.import/g.gui.v.import. For example compare the two commonly used
and GDAL supporteded formats AIG and GTiff, See also specifications for
each of the GDAL supported formats [0] and the OGR supported formats [1].
#2042: wxgui: no more menu access to r.in.gdal / v.in.ogr
--------------------------------------+-------------------------------------
Reporter: mlennert | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: wxGUI | Version: svn-trunk
Keywords: r.in.gdal, v.in.ogr, gui | Platform: Unspecified
Cpu: Unspecified |
--------------------------------------+-------------------------------------
Comment(by cmbarton):
I just had a chance to catch up on this discussion. I did not realize that
the button to r.in.gdal had disappeared.The import wrapper is nice, but it
is missing important r.in.gdal functionality and for this reason is not a
full substitute for the original grass module. In addition to lacking
control over input of multiband data, it also lacks the ability to create
a new location from a georeferenced file, or read a GCP file for
reproduction. You also do not have access to the r.in.gdal help from
within the wrapper. There are similar issues with v.in.ogr.
Do I understand from the discussion that r.in.gdal has now been added to
the list of modules that need the semi-secret --ui flag? I hope not,
especially if it can no longer be launched from within the wrapper.
Overall, I think the need to specify the --ui to launch some modules but
not others is really confusing to users trying to use the command line
more.
#2042: wxgui: no more menu access to r.in.gdal / v.in.ogr
--------------------------------------+-------------------------------------
Reporter: mlennert | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: wxGUI | Version: svn-trunk
Keywords: r.in.gdal, v.in.ogr, gui | Platform: Unspecified
Cpu: Unspecified |
--------------------------------------+-------------------------------------
Comment(by mlennert):
Replying to [comment:14 mmetz]:
> Considering that the wxGUI interface to r.in.gdal/v.in.ogr does not
handle the GDAL/OGR mapping of input bands(raster) / layers(vector) to
files/directories/databases while GDAL/OGR does, because this mapping is
format-specific, I would suggest to keep r.in.gdal and v.in.ogr as they
are and introduce new wxGUI-specific modules r.import/v.import, or
g.gui.r.import/g.gui.v.import.
#2042: wxgui: no more menu access to r.in.gdal / v.in.ogr
--------------------------------------+-------------------------------------
Reporter: mlennert | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: wxGUI | Version: svn-trunk
Keywords: r.in.gdal, v.in.ogr, gui | Platform: Unspecified
Cpu: Unspecified |
--------------------------------------+-------------------------------------
Comment(by mlennert):
I would like to revive this discussion. Recently, I imported a vector file
with the wxgui import wizard. I got a message that there were a series of
errors and a hint to try to set a specific snapping distance. However, in
the wizard there is no way to set the snap parameter and there is no way
to get from the wizard to the actual module. You have to be an informed
user to know that you have to launch the module from the terminal, or with
the --ui option.
Again, I plead very strongly for not dumbing down the GUI too much and for
leaving passages to power-user approaches. Even if such passages might
confuse some newbie users (although I would like to see some stats on how
often this really happens), I think that the improvement in ease of use
for other users and the pedagogical effect of showing these advanced
approaches instead of hiding them are worth the occasional confusion.
