How can we include/exclude a script in the menu based on a runtime condition - discuss options.

[schwar3kat]

How can we include/exclude a script in the menu based on a runtime condition, like it is possible in armbian config? E.g. depending on a file or executable existing.
How can we include/exclude a script group in the menu based on a runtime condition like it is possible in armbian config?

Perhaps some kind of standard initialization function if it exists, could be triggered first as each script is parsed, setting initialization variables could be included as a standard part of any function script. And a similar menu folder initialization script could be included in any folder.

One of those variables could set visibility. Another could set menu text, allowing dynamic menu text based on runtime requirements and possibly other options could be added if required.

Any logic could be used to set those variables.

To illustrate with an example of what I am imagining. Maybe something like this:
(excuse my bash if it is bad or not feasible)

# @description Do something useless.
#
# @exitcode 0  If successful.
#
# @options none

# menu_init function triggered first by menu creation routines if it exists
function menu_init(){
    #
    # Only display menu option if internet connection is available
    #
    wget -q -t 1 --timeout=5 --spider http://github.com
    if [[ $? -ne 0 ]]; then
        menu_item=false
    else
        menu_item=true
    fi

    menu_text="Do something useful" # this could override the description as the menu text if it exists
}

function group::string() {s
    echo "Doing something"
    return 0
}

[schwar3kat]

For directories/folders creating menu groups, any folder could perhaps have an initialization script with a defined name, maybe menu_group_init. This could contain a function similar to the function in the scripts.

# @group_description Arbitrary group.

# menu_group_init function triggered first by menu creation routines if it exists
function menu_group_init(){
    #
    # Only display menu group if internet connection is available
    #
    wget -q -t 1 --timeout=5 --spider http://github.com
    if [[ $? -ne 0 ]]; then
        menu_group_item=false
    else
        menu_group_item=true
        menu_group_text='Something useful folder' # this could override the group description as the menu text if it exists
    fi
}

[Tearran]

@schwar3kat Thank you. The example you share addresses a few with Header issues I had for 1. and I fully agree with your suggestion regarding the implementation of a "standard initialization function", And has a intended location. However, I want to emphasize the paramount importance of establishing a clear responsibility framework upfront.
As Clearly pointed out and excellently stated Any logic could be used to set those variables. So,
Instead of immediately delving into specific functionalities like the initialization function, I propose prioritizing the definition of responsibilities and the overall project structure. This initial breakdown into Frontend, Backend, and Communication components is crucial for achieving an organized codebase and lays the foundation for seamless contributions from other developers.

In our bash scripting environment:

Frontend: Comprises bash scripts responsible for user interactions and tasks related to the interface. /bin

Backend: Encompasses bash scripts managing server-side logic, data processing, and other backend functionalities. subfolders of the library dynamically can delete or create files and folders without effecting of the frontend.

Communication Layer: Involves custom bash scripts or functions facilitating communication between the Frontend and Backend. Think of it as an interface, akin to an API but tailored to our bash scripting environment. root of library

For example, within the Frontend, bash scripts may trigger specific Backend functionalities and receive responses, possibly by invoking Backend scripts or functions. The Communication Layer ensures a structured and standardized way for these components to exchange data and instructions. initially is in the root of the library these curranty require editing the frontend at the stage.

Focusing on this responsibility framework creates an environment where new contributors can quickly understand and engage with the project. I believe that this structured approach will not only benefit the current development process but will also make it much easier for others to collaborate and contribute effectively.

[schwar3kat]

For dynamic runtime menu text, default text and dialogue text, how could we/should we include multiple languages?

Maybe json key value pair file: (Idea from https://www.honeybadger.io/blog/creating-multi-language-user-interface-with-react/)

en/translation.json (For English):

{
"weather_forcast_for": "Weather forecast for",
"current_temperature": "Current temperature",
"feels_like": "Feels like",
"humidity": "Humidity"
}

fr/translation.json (For French):

{
"weather_forcast_for": "Prévisions météo pour",
"current_temperature": "Température actuelle",
"feels_like": "Ressenti",
"humidity": "Humidité"
}

es/translation.json (For Spanish):

{
"weather_forcast_for": "Pronóstico del tiempo para",
"current_temperature": "Temperatura actual",
"feels_like": "Sensación térmica",
"humidity": "Humedad"
}

[Tearran]

@igorpecovnik @schwar3kat

From my understanding of the existing bash-utility-master in the project was intended for such things.

note: configng has no systems requirements beyond gnu bash tools
A bash read tui was put in place before testing dialog and whiptail functionality.
Technically Dialog or whiptail is requirement but only by request. this broke fallback to bash read but can be used manually.

Separating function requirement from configng requirement are of high importance.

A requirements list in the header could be leveraged to provide a list of requirements, that can then be used for available list used for triggers. such as menu items show/hide

# @description Function header is used for a ( menu wrapper, command launcher or browser ) to interact with
# @requirments git armbian-configlg,
# @default function_name
# @options freeze unfreeze

to make an array that will work something like

requirements=("nmtui" "git" "armbian-config")
echo "${requirements[@]}" 

With bash-utility-master

#
# Source the check.sh file from the bash-utility-master library
. "$libpath"/../bash-utility-master/src/check.sh

# Check if each requirement is met
for requirement in "${requirements[@]}"; do
    check::command_exists $requirement
done

# If all requirements are met, continue with the script
echo "All requirements are met"

With GNU bash

# Check if each requirement is met
for requirement in "${requirements[@]}"; do
    if ! command -v $requirement &> /dev/null; then
        echo "$requirement could not be found"
        exit
    fi
done

# If all requirements are met, continue with the script
echo "All requirements are met"

[schwar3kat]

# @options freeze unfreeze

I can see that this could be the basis for a binary toggle, but would be better if it was constructed to handle any number of item's in a list, rather than just two.
Example (these are not real states, for illustration of the concept only):
# @options all-freeze deep-freeze unfreeze kernel-freeze uboot-freeze

How could a menu item be renamed based on the results of a function during menu initialization?
For example assume that we dynamically retrieved a name of an item from a web query and we wanted to include that name in the text of a menu item together with other fixed text.
Example (For illustration of the concept only):
Fixed text: "Retrieve-"
Result of web query (or other dynamic text): "version 4.201a"
Dynamically created menu text: "Retrieve-version 4.201a"

[Tearran]

include/exclude a script from the menu based on a runtime condition has be solved with jq and json object