Three Competing Interfaces?

[thw26]

One of the big upgrades of the Python update is having a fuller TUI/GUI experience over Bash's install-only interface and the CLI optargs (besides the launcher and control panel scripts). The Python script has optargs, a TUI, and a GUI. Due to differences in limitations between each interface, some of these conflict.

As an example, the --skip-fonts flag was designed for the CLI of the Bash interface of LogosLinuxInstaller.sh which was an install-only script with no TUI. There was no checkbox in the install TUI or the Zenity GUI for skipping fonts; it had to be declared on the CLI.

With the introduction of an interactive TUI and GUI, some of the optargs no longer make sense, like --skip-fonts. The current GUI has this flag built in as a checkbox, but the current TUI does not. How should we handle these competing flags and interfaces?

Finally, to finish the above discussion, should there be an option in the TUI/GUI control panel to install fonts in case the user skips them but realizes he needs them later? :D

[n8marti]

I guess I was envisioning the purpose of 3 interfaces a little differently:

• GUI is for "normal" end users who just want to point and click, and it should handle ~80% of the use cases (the most common ones);
• TUI is for more advanced users and should handle ~90-95% of use cases;
• CLI-only (i.e. LogosLinuxInstaller --option1) would be used mostly for testing or "internal" needs and should ideally handle all use cases.

Here's a lame visual representation of the above verbal description:

Interface   Features
CLI:        ********************
TUI:        ******************
GUI:        ****************

Or, if that's a bit overkill, maybe the GUI and TUI should have equivalent functionality, both covering the top 80% of use cases, while the CLI covers 100%. And I have conveniently avoided trying to define "features" or list what they are, because I don't really have a clear picture of that yet.

I don't see any of the CLI options as being redundant or conflicting, though, because that's what I use to run tests more quickly. For example, I can do an install almost non-interactively with ./LogosLinuxInstaller.py -FPV, which skips fonts (and so installs much faster), installs the MSI passively (and so there are no prompts when the MSI is run), and gives verbose terminal output so I can more closely follow what's going on.

So, taking the --skip-fonts example, maybe we need to work that into the TUI so that the option is available there? Or maybe we need to remove it from the GUI if we don't think it will be all that useful for most people and might instead lead to confusion? (NOTE: I don't even know myself how running the app is affected by whether the extra fonts are installed or not. Are some font substitutions done in the app if those extra fonts are missing? Or is some text not rendered properly without the extra fonts? Or does it depend on the language of the Logos UI?)

CLI options are also used to run "subcommands" that may or may not require a UI, such as ./LogosLinuxInstaller.py --control-panel to open the Control Panel window, and now ./LogosLinuxInstaller.py --run-winetricks to run winetricks.

Finally, I'm not trying to say that this is how things should be, but just how I have subconsciously pictured it up till now. If we can clarify this together, then I will be a lot more comfortable going forward.

[thw26]

In the Bash script repo, the Launcher script handled all things pertaining to an installed use of Logos. The Control Panel script handled all things pertaining to the Wine bottle. The Installer of course handled installs, but also regenerating the Launcher and Control Panel scripts so that users didn't have to reinstall their entire Logos system, and this regenerating action was the motivation to establish a config file. That should give you some history of this.

My intent with this rewrite was to merge the Installer, the Launcher, and the Control Panel of the Bash script collection into a single application with near feature-parity. I imagine the program then being usable like this:

• GUI for average user
• TUI for interactive CLI use
• optargs for non-interactive CLI use

In the current implementation, the TUI relies on some optargs to get full functionality (e.g., --skip-fonts), whereas the GUI has its checkbox.

In the Bash set up, before I implemented optargs, Zenity was used for install, and optargs were used for everything else. Following my implementation of optargs in Bash, I also implemented a basic TUI to replace Zenity so that install could happen at CLI. So in the Bash setup, the split was:

• optargs could do everything but install
• TUI could only install
• optargs plus TUI could do 100%
• GUI could only install
• optargs plus GUI could do 100%, except for the fact that the Launcher and Control Panel had no GUI and were optargs/CLI only

With our current implementation, I'd say we are at something like (and of course this is highly subjective):

• CLI 100%
• TUI 90% (or 100% with optargs)
• GUI 90%

Here is our current help:

usage: LogosLinuxInstaller.py [-h] [--version] [--config CONFIG_FILE] [--verbose] [--skip-fonts] [--force-root]
                              [--reinstall-dependencies] [--debug] [--make-skel]
                              [--custom-binary-path CUSTOMBINPATH] [--check-resources] [--delete-install-log]
                              [--edit-config] [--indexing] [--backup] [--restore] [--logs] [--dirlink] [--shortcut]
                              [--passive] [--control-panel] [--get-winetricks] [--run-winetricks]

Installs FaithLife Bible Software with Wine on Linux.

options:
  -h, --help            show this help message and exit
  --version, -v         show program's version number and exit
  --config CONFIG_FILE, -c CONFIG_FILE
                        Use a custom Logos on Linux config file during installation. Default config is at
                        /home/thwright/.config/Logos_on_Linux/Logos_on_Linux.json.
  --verbose, -V         Enable verbose mode
  --skip-fonts, -F      Skip font installations
  --force-root, -f      Set LOGOS_FORCE_ROOT to true, which permits the root user to use the script.
  --reinstall-dependencies, -I
                        Reinstall your distro's dependencies.
  --debug, -D           Enable Wine debug output.
  --make-skel, -k       Make a skeleton install only.
  --custom-binary-path CUSTOMBINPATH, -p CUSTOMBINPATH
                        Specify a custom wine binary path.
  --check-resources, -R
                        Check resources and exit
  --delete-install-log, -L
                        Delete the installation log file.
  --edit-config, -e     Edit configuration file
  --indexing, -i        Perform indexing
  --backup, -b          Perform backup
  --restore, -r         Perform restore
  --logs, -l            Enable/disable logs
  --dirlink, -d         Create directory link
  --shortcut, -s        Create shortcut
  --passive, -P         Install Faithlife product non-interactively
  --control-panel, -C   Open Control Panel app
  --get-winetricks      Download or update Winetricks
  --run-winetricks      Download or update Winetricks

The one command in here I was planning to obsolete is --check-resources, which was an attempt at obtaining debugging helps.

The backup/restore functionality is almost too simplistic for me to really recommend us advocating or advertising it at present.

The only options I think are truly optargs-only here are: --version, --debug/--verbose (but the GUI should auto-set this so we always get our average user's logs when they report a bug),--passive, --force-root (which shouldn't be advertised as it will be misused), and perhaps --config or --custom-binary-path, though I think the GUI has some of these. I hardly think these amount to having a difference in feature parity.

--control-panel is GUI only, and this could be merged with the installer by creating a button for Install that opens the Installer GUI and disables the other buttons until an install is detected, thus making it function like the TUI.

The other option here that is a little odd is the --make-skel, which was an option Ferion11 used to help with his testing. I'm not aware of any of us using this at the present time.

My main issue with the "action" commands is that they seem to be a secondary set of optargs, and I think it would be easy for us to move them to the optargs section as new optargs, e.g., --run-logos.

That was what I envisioned when I embarked on the rewrite.

Happy to receive pushback here.

[n8marti]

• GUI for average user
• TUI for interactive CLI use
• optargs for non-interactive CLI use

This is great. I think we're saying basically the same thing on the question of how functional the various interfaces should be.

The one command in here I was planning to obsolete is --check-resources, which was an attempt at obtaining debugging helps.

I have no problem with this, but if there's a hope to pursue the idea farther in the future, then we could also just hide it from help by setting it's help paramenter like this: help=argparse.SUPPRESS. This could also be useful for "backup" and "restore" until they are functional. This leaves the options usable for testing but not easily findable.

... --config or --custom-binary-path, though I think the GUI has some of these...

If these are rarely-used or only used by testers, then I'd be in favor of dropping them from the GUI for simplicity's sake. The GUI user shouldn't be given choices that they're unlikely to use, in my opinion. The same goes for --skip-fonts. But I still don't understand if this is needed by typical users for some reason, or if it's just used to facilitate quick installation for testing, or something else? But I'd be happy to remove it from the GUI if most people aren't going to need to make that decision.

--control-panel is GUI only, and this could be merged with the installer by creating a button for Install that opens the Installer GUI and disables the other buttons until an install is detected, thus making it function like the TUI.

I hadn't thought about it this way, but, yes, it makes sense to consider that the "main app" is the control panel with the installer only being a dependent of that.

The other option here that is a little odd is the --make-skel, which was an option Ferion11 used to help with his testing. I'm not aware of any of us using this at the present time.

I be happy to drop it if it's not being used. I haven't bothered to use it. But one thing I do a lot of in testing, though, is rm -rf ~/LogosBible10. Would it be worth adding an option (CLI, at least) to delete, if not that base folder, then maybe at least the wine prefix/bottle in data/? It's a bit tricky, since the base level folder's name can vary depending on what app is installed, but the config file could be used to pick the correct wine prefix/bottle path.

My main issue with the "action" commands is that they seem to be a secondary set of optargs, and I think it would be easy for us to move them to the optargs section as new optargs, e.g., --run-logos.

Yes, I agree that there should be a --run-logos option, in the spirit of giving 100% functionality to the CLI. The "action" variable was added to allow parsing the optargs fairly early on in script execution without taking immediate action at that moment. That gave time after parsing the arguments for the rest of the initialization to happen (e.g. die_if_*, set up logging, read in env vars) before the "action" was taken. The alternative I saw was to call the related function at the moment the CLI was being parsed, but that meant that other options risked getting ignored because they hadn't been handled yet. So I think something has to be done to separate pure optargs that affect how the script runs from options that affect what the script does (i.e. "actions"), because their values needed to be handled at different times during execution.

I now have a clearer idea of the flow, with a paradigm of thinking of the control panel as the "main app", so I'd like to work on a rewrite of LogosLinuxInstaller.py as soon as I'm confident that we have the same understanding of how it should work, and I think we're almost there!

[thw26]

I have no problem with this, but if there's a hope to pursue the idea farther in the future, then we could also just hide it from help by setting it's help paramenter like this: help=argparse.SUPPRESS. This could also be useful for "backup" and "restore" until they are functional. This leaves the options usable for testing but not easily findable.

This would be great!

[thw26]

If these are rarely-used or only used by testers, then I'd be in favor of dropping them from the GUI for simplicity's sake. The GUI user shouldn't be given choices that they're unlikely to use, in my opinion. The same goes for --skip-fonts. But I still don't understand if this is needed by typical users for some reason, or if it's just used to facilitate quick installation for testing, or something else? But I'd be happy to remove it from the GUI if most people aren't going to need to make that decision.

We have had mix responses about whether or not the fonts are needed. I don't see it as solely for testers.

[thw26]

I be happy to drop it if it's not being used. I haven't bothered to use it. But one thing I do a lot of in testing, though, is rm -rf ~/LogosBible10. Would it be worth adding an option (CLI, at least) to delete, if not that base folder, then maybe at least the wine prefix/bottle in data/? It's a bit tricky, since the base level folder's name can vary depending on what app is installed, but the config file could be used to pick the correct wine prefix/bottle path.

I think with our config that should be easy to do. The bigger issue is running an rm, so we'd want to be careful with our programming, especially because there are symlinks in the wine bottle.

This could be some part of setting up the app to do upgrades or reinstalls, but keeping the data, and thus also tying in to backups/restores.

[thw26]

Yes, I agree that there should be a --run-logos option, in the spirit of giving 100% functionality to the CLI. The "action" variable was added to allow parsing the optargs fairly early on in script execution without taking immediate action at that moment. That gave time after parsing the arguments for the rest of the initialization to happen (e.g. die_if_*, set up logging, read in env vars) before the "action" was taken. The alternative I saw was to call the related function at the moment the CLI was being parsed, but that meant that other options risked getting ignored because they hadn't been handled yet. So I think something has to be done to separate pure optargs that affect how the script runs from options that affect what the script does (i.e. "actions"), because their values needed to be handled at different times during execution.

This is what I did in the Bash script. I iterated over the optargs twice, once setting any runtime config settings, and a second time to determine the user's action.

We can do this easy by changing the actions like --run-winetricks to set a variable, and then we just check if that variable is set once we hit main().

[thw26]

I now have a clearer idea of the flow, with a paradigm of thinking of the control panel as the "main app", so I'd like to work on a rewrite of LogosLinuxInstaller.py as soon as I'm confident that we have the same understanding of how it should work, and I think we're almost there!

I agree with your first statements; we are on the same page.

[n8marti]

One more thought. I see now maybe another source of confusion: runtime config. Since we want to handle input from a config file, from the CLI, and from environment variables, the runtime config can't be fully established until all 3 sources have been evaluated. But some "actions" require that the config be set before they're run. So this is the general flow that I see:

• set the runtime config
  • set default config
  • update config using config file
  • update config using CLI options (can't run CLI "actions" here b/c final config isn't yet set)
  • update config using environment variables
• Run desired "action": run CLI action(s), or start TUI, or start GUI
  • But choices in TUI/GUI that are related to earlier config are pre-selected in GUI and skipped as already set in TUI(?)

[thw26]

Reposting what I shared above, just because it is the same kind of issue:

This is what I did in the Bash script. I iterated over the optargs twice, once setting any runtime config settings, and a second time to determine the user's action.

We can do this easy by changing the actions like --run-winetricks to set a variable, and then we just check if that variable is set once we hit main().

[n8marti]

Perfect. This is what I was doing by using config.ACTION as the variable. And that's why the block checking the value of that variable was placed just after config was finally setup, and just before any of the UI-specific code. The assumption was that if one of these action options was passed, that it would run that one action and exit. If we wanted to support multiple actions, then that variable could just as easily be a list of functions that get executed sequentially.

[thw26]

If you have an idea of how to make this work well, so that we can also call the GUI with whatever we need/want, then go for it.

I'm not sure whether we want to be able to run multiple actions (e.g., reinstall winetricks and run winetricks) or not by optargs.

I made #37 as the issue related to this discussion.