Opened 8 years ago

Last modified 4 years ago

#1420 new enhancement

wxGUI: modeller

Reported by: neteler Owned by: grass-dev@…
Priority: normal Milestone: 6.4.6
Component: wxGUI Version: svn-releasebranch64
Keywords: addons Cc:
CPU: Unspecified Platform: Unspecified

Description

While the new graphical modeller dynamically reads in the available module list, the locally installed Addons are not shown in the list.

Solution proposal: check also Addon-path.

Change History (5)

comment:1 Changed 8 years ago by martinl

Component: DefaultwxGUI
Keywords: addons added
Type: defectenhancement

comment:2 Changed 8 years ago by martinl

In r48545 the addons modules are at least scanned. So it's possible to call them from wxGUI cmd. It would be also good to add them dynamically to the menu and enable to search for them by desc/keywords etc.

Backported to devbr6 for testing.

comment:3 in reply to:  2 ; Changed 8 years ago by hamish

Replying to martinl:

In r48545 the addons modules are at least scanned.

do not scan $GRASS_ADDON_PATH/bin/ and $GRASS_ADDON_PATH/scripts/. rather just scan $GRASS_ADDON_PATH. executables are (ie should be) symlinked back into there if they happened to be installed to ./bin/ or ./scripts/. (I see no reason why with a little more work bin/ and scripts/ couldn't be skipped entirely, and save the trouble of the symlinking)

the $GRASS_ADDON_PATH variable is meant to be part of the $PATH variable, it is not meant to be --prefix= or $ADDON_BASE. (see also William's approach using $GRASS_ADDON_ETC found in lib/gis/find_etc.c and documented in macosx/Readme.rtf)

thanks, Hamish

comment:4 in reply to:  3 Changed 8 years ago by martinl

Replying to hamish:

Replying to martinl:

In r48545 the addons modules are at least scanned.

do not scan $GRASS_ADDON_PATH/bin/ and $GRASS_ADDON_PATH/scripts/. rather just scan $GRASS_ADDON_PATH. executables are (ie should be) symlinked back into there if they happened to be installed to ./bin/ or ./scripts/. (I see no reason why with a little more work bin/ and scripts/ couldn't be skipped entirely, and save the trouble of the symlinking)

the $GRASS_ADDON_PATH variable is meant to be part of the $PATH variable, it is not meant to be --prefix= or $ADDON_BASE. (see also William's approach using $GRASS_ADDON_ETC found in lib/gis/find_etc.c and documented in macosx/Readme.rtf)

But that's the way how GRASS_ADDON_PATH currently works in G7. It's topic for discussion of course. Basically this variables currently serves in G7 as GISBASE for Add-ons modules. This approach doesn't require adding new and new variables for etc, html or man pages. It's the main advantage of this approach, personally I don't know about disadvantages (please correct me). In G7 everything is installed to the one place, by default $HOME/.grass7/addons on GNU/Linux.

comment:5 Changed 4 years ago by neteler

Milestone: 6.4.26.4.6

State of this?

Note: See TracTickets for help on using tickets.