DietPi-Launcher: Add dietpi-display and dietpi-banner, remove dietpi-morsecode

[StephanStS]

Proposal for a minimal fresh up of DietPi-Launcher:

• Removed dietpi-morsecode from the launcher menu (who uses it?)
• Added dietpi-display (direct call instead of going via dietpi-config)
• Added dietpi-banner

[MichaIng]

Should these 3 categories be merged into "Maintenance"? All of this is maintenance ... aside of maybe dietpi-sync.

Agreed that dietpi-moresecode is probably an extreme niche script. But does it hurt at the very end of the list, if we have it already? It does work, and combined with some LCD can produce light signals.

Maybe we should add an optional script usage counter for dietpi-survey 😄.

[StephanStS]

Maybe the grouping could be synchronous to https://dietpi.com/docs/dietpi_tools/?
Or change the docs in accordance with the launcher...

dietpi-morsecode: OK, let's keep it at the end.

[MichaIng]

Makes sense to align it. Though I would change a few entries in the docs as well then:

• dietpi-explorer + dietpi-survey => misc, or dietpi-explorer in maintenance would be also not wrong
• dietpi-logclear is fine in maintenance in the docs, but has a CLI only, hence not suitable for the dietpi-launcher
• dietpi-banner => configuration like you did here
• dietpi-autostart, dietpi-ddns, dietpi-vpn, dietpi-letsencrypt fit into multiple categories ... software, configuration, misc, probably find to arrange them a way that software does not have a single entry only, otherwise either way is okay for me 😅.

[StephanStS]

I propose this:

• Category "Software installation"
  • DietPi-Software
  • DietPi-LetsEncrypt
  • DietPi-VPN
  • DietPi-DDNS
• Category "Configuration"
  • DietPi-Config
  • DietPi-Drive_Manager
  • DietPi-AutoStart
  • DietPi-Services
  • DietPi-Display
  • DietPi-LED_control
  • DietPi-Cron
  • DietPi-JustBoom
  • DietPi-CloudShell
• Category "Maintenance"
  • DietPi-Update
  • DietPi-Backup
  • DietPi-Sync
  • DietPi-Cleaner
• Category "Misc"
  • DietPi-Banner
  • DietPi-CPUinfo
  • DietPi-Explorer
  • DietPi-Survey
  • DietPi-BugReport
  • DietPi-MorseCode

dietpi-logclear: I would put this into category "Maintenance", if we improve it with a user menu. As long as it is only CLI, we keep it outside of dietpi-launcher.

The docu of DietPi-Tools also follows this categorization, dietpi-logclear and "Useful DietPi Shell Functions" are kept as today in the docs.

[MichaIng]

I vote for exchanging banner and CloudShell. The banner menu really is for configuring the login banner that is shown on every login. CloudShell is more a standalone tool for small info LCDs. Otherwise looks good.

dietpi-logclear is a script and no G_* shell function, so in the docs, it is good where it is. Just for the dietpi-launcher, it cannot be practically implemented: other than e.g. dietpi-cpuinfo which has no menu either, it requires one of certain CLI argument to do anything useful. And clearing logs the one or the other way is probably not wanted by someone who just browses through the launcher to see what it offers. So yeah, this script would require a menu to land in the launcher. But then, it is used almost only by our hourly cron job in case dietpi-ramlog is enabled to prevent a tmpfs overflow, hence is meant to be sort of a minimal light script. There are some more such cases:

• dietpi-benchmark which has its menu in dietpi-config. I always wanted to put the menu into dietpi-benchmark itself. In that case no reason to not do that, and a shell alias along with it.
• dietpi-optimal_mtu ... this is probably even less used than dietpi-morsecode 😄.
• Most other scripts below /boot/dietpi/func are meant to be a CLI-only backend for mostly dietpi-config and dietpi-drive_manager. But it would be also possible to move the menus over, make this two huge scripts smaller, and turn the backend scripts into standalone ones to configure stuff. Of course dietpi-config etc would still keep the parent menu entires, but call e.g. dietpi-set_cpu to show CPU governor options in a submenu.

EDIT: Actually, for dietpi-morsecode the same applies than for dietpi-logclear: It requires an input file, and an argument can be used to change the output (screen, LEDs, audio). Would actually make sense to allow giving the text as 2nd argument, and otherwise show a menu (or read -p based console inputs) to ask for input, if the text file does not exist. I think I'll give Copilot the task to implement this 😄.