wxgui: no more menu access to r.in.gdal / v.in.ogr

[mlennert]

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.

[annakrat]

The button was removed in r54618. I don't have any strong opinion on this. Perhaps the button might be confusing for users?

[hamish]

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.

thanks, Hamish

ps- general todo: tooltips on *everything*! :)

[martinl]

Replying to 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.

[martinl]

Replying to martinl:

Replying to 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.

[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)

regards, Hamish

[hamish]

Replying to 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" ??

Hamish

[martinl]

Replying to 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?

[...]

[martinl]

Replying to hamish:

Replying to 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.

Martin

[wenzeslaus]

Replying to 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:

• ​new `g.gui.` modules (​nabble)

• ​Additional switch(es) for <g.mapsets>? (​nabble)

[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.

Keep the front ends and the backends separate. Let the backend simply do its "one thing well".

thanks, Hamish

[martinl]

Replying to 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?

[wenzeslaus]

Replying to martinl:

Replying to 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.

[martinl]

Replying to wenzeslaus:

Replying to martinl:

Replying to 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.

no, 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

[mmetz]

Replying to 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].

[0] ​http://www.gdal.org/formats_list.html [1] ​http://www.gdal.org/ogr/ogr_formats.html

[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.

Michael

[mlennert]

Replying to 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.

+1 (I prefer r.import to g.gui.r.import)

And both should be accessible from the menu.

Moritz

[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.

Moritz

[marisn]

AAAGH! It's the end of 2016 and GRASS continues its death march towards "let's dumb it down to not confuse beginners and thus lose the only reason why we are still relevant". If there are no "advanced" features then "beginners" do not see any reason why to use GRASS not QGIS (and I have to agree with it). If you want to see how it will end, just take a look at Firefox.

I just had to explain to a QGIS user why he can not find in GRASS "snapping tolerance" setting he had been using in QGIS. Reason - you must belong to the secret society who passes its secrets only to chosen ones and type --ui in that black window to get a dialog with all options not an useless dumbed down version where is not possible to change any of not-so-common properties under e.g. button "advanced". (Yes, v.in.ogr snapping setting is exposed to QGIS users and, as far as I know, nobody has died because of it)

I do not thing that users who get confused by "Launch advanced interface" button are the target audience of GRASS GIS.

[hellik]

Replying to marisn:

AAAGH! It's the end of 2015 and GRASS continues its death march towards "let's dumb it down to not confuse beginners and thus lose the only reason why we are still relevant". If there are no "advanced" features then "beginners" do not see any reason why to use GRASS not QGIS (and I have to agree with it). If you want to see how it will end, just take a look at Firefox.

I just had to explain to a QGIS user why he can not find in GRASS "snapping tolerance" setting he had been using in QGIS. Reason - you must belong to the secret society who passes its secrets only to chosen ones and type --ui in that black window to get a dialog with all options not an useless dumbed down version where is not possible to change any of not-so-common properties under e.g. button "advanced". (Yes, v.in.ogr snapping setting is exposed to QGIS users and, as far as I know, nobody has died because of it)

I do not thing that users who get confused by "Launch advanced interface" button are the target audience of GRASS GIS.

I'm strongly +1 for re-adding an advanced button to the wizzard. As I'm often working with foreign data which needs often finetuning for importing (e.g. snapping tolerance, where selection, etc). it's annoying to always start with --ui.

I'm not sure why a 'normal' user should be confused with a advanced button. What is a 'normal' user?

[pvanbosgeo]

I am not sure if there are many examples of this so-called death march, but +1 for the specific example provided.

I indeed see no reason why any user would get confused, on the contrary.. I had similar experiences where beginning users were surprised they couldn't find the options that were described in the manual.

In addition, adding a button called "advanced options" is quite a common way to 'hide' the more complex options while making it still easy to find in many programs.

[martinl]

Replying to pvanbosgeo:

In addition, adding a button called "advanced options" is quite a common way to 'hide' the more complex options while making it still easy to find in many programs.

better would be a new tab with all specific options. Colleague of mine is working on that.

[mlennert]

Replying to martinl:

Replying to pvanbosgeo:

In addition, adding a button called "advanced options" is quite a common way to 'hide' the more complex options while making it still easy to find in many programs.

better would be a new tab with all specific options. Colleague of mine is working on that.

I don't agree. I don't think the wizard should replace the module GUI. It should make initial use easier and by that cover a large majority of use cases, but why program a whole new wizard interface which at the end replicates the GUI module.

I just sent a message to grass-dev & grass-psc as I think this merits a more fundamental discussion beyond this specific bug report. In this specific case, I plead for:

• give a specific name to the wizards
• don't open wizard when module is called by name
• add option to open module GUI from wizard

[martinl]

Replying to mlennert:

I don't agree. I don't think the wizard should replace the module GUI. It should make initial use easier and by that cover a large majority of use cases, but why program a whole new wizard interface which at the end replicates the GUI module.

it's not a wizard, it's GUI front-end for r.in.gdal/v.in.ogr module which enables to call this module in the loop, nothing else.

[mlennert]

Replying to martinl:

Replying to mlennert:

I don't agree. I don't think the wizard should replace the module GUI. It should make initial use easier and by that cover a large majority of use cases, but why program a whole new wizard interface which at the end replicates the GUI module.

it's not a wizard, it's GUI front-end for r.in.gdal/v.in.ogr module which enables to call this module in the loop, nothing else.

Call it what you want. I actually like the idea of calling it a wizard as it simplifies a series of things, such as selecting layers in a file or in a database, that demand a more advanced knowledge to do directly in the modules.

In any case, it is a simplified interface for importing data via r.in.gdal/v.in.ogr. And most people use it not only for looping but for any import, as this is what they get when they chose file import from the menus.

[martinl]

Replying to mlennert:

Call it what you want. I actually like the idea of calling it a wizard as it simplifies a series of things, such as selecting layers in a file or in a database, that demand a more advanced knowledge to do directly in the modules.

try v.in.ogr dialog (--ui) in trunk, it allows you the same (except of importing several layers in the loop).

[mlennert]

Replying to martinl:

Replying to mlennert:

Call it what you want. I actually like the idea of calling it a wizard as it simplifies a series of things, such as selecting layers in a file or in a database, that demand a more advanced knowledge to do directly in the modules.

try v.in.ogr dialog (--ui) in trunk, it allows you the same (except of importing several layers in the loop).

Could you explain where this dialog comes from ? AFAIU, it is not the automatically created dialog based on the parser, or ? So even the --ui doesn't even give the normal interface anymore ?

[martinl]

Replying to mlennert:

Could you explain where this dialog comes from ? AFAIU, it is not the automatically created dialog based on the parser, or ? So even the --ui doesn't even give the normal interface anymore ?

the dialog is still autogenerated, the only difference is that for gisprompt 'datasource' is used GDALSelect widget (1), so nothing special in forms.py. BTW, by normal interface do you mean just textctrl? It's was not normal, it was just not designed at all. You needed to type full path to the file, directory, or connection string manually. I don't feel it as normal in the sense of (interactive) GUI. GDALSelect should be improved of course, but it is separate issue.

(1) source:grass/trunk/gui/wxpython/gui_core/forms.py#L1689​

[mlennert]

Replying to martinl:

Replying to mlennert:

Could you explain where this dialog comes from ? AFAIU, it is not the automatically created dialog based on the parser, or ? So even the --ui doesn't even give the normal interface anymore ?

the dialog is still autogenerated, the only difference is that for gisprompt 'datasource' is used GDALSelect widget (1), so nothing special in forms.py.

Beautiful ! Great job, thanks !

BTW, by normal interface do you mean just textctrl? It's was not normal, it was just not designed at all. You needed to type full path to the file, directory, or connection string manually. I don't feel it as normal in the sense of (interactive) GUI.

+1

"Normal" meant "the one I'm used to". I hadn't followed your changes to forms.py and suddenly got the feeling that by some automagic, typing v.in.ogr somehow circumvented the normal GUI creation process. The current implementation is much better.

I agree, however, that this needs to be improved. Notably, as you mention, you cannot import in a loop, but you can select a directory of shapefiles as datasource and then select several layers in that directory and import those. They are then imported as one vector map (with name of the first layer if you don't set an output name), containing the content of all shapefiles selected in separate layers in that map. Potentially quite confusing for the user.

Maybe the directory option should be desactivated while this isn't solved, or at least a big warning printed somewhere, unless you are working on fixing that issue in a near future ? When that is done, we won't even need what I called the "wizard" anymore, or ?

[neteler]

Ticket retargeted after milestone closed

[neteler]

Ticket retargeted after 7.0.3 milestone closed

[martinl]

No activity for a long time, unclear state. Closing. Feel free to reopen of create new ticket (more clear).

[cmbarton]

Now you can launch r.in.gdal (and v.in.ogr) directly from the menu--which is a good thing because the r.import and v.import interfaces are broken and don't work #3591