Support command line arguments for Optikey Pro

[kmcnaught]

See #782 as well as discussion in https://github.com/OptiKey/OptiKey/issues/761

New behaviour

(1) passing an XML file as an argument loads this file directly (2) passing a folder as an argument loads the folder into the dynamic keyboard menu, with a Quit key available instead of the usual Back key

Open questions

(a) How should "Back" work from either of these scenarios? Currently there is no back action available. This means you cannot access the rest of Optikey unless you've set up explicit links, and in the case of (1) you can't access Quit keys unless you've set them up yourself. In my own fork (OK Game On) I don't want to allow people default access to elsewhere since this kind of workflow (opening a single file) is a good way to lock an inexperienced user into a limited set of keyboards for the session. In Optikey Pro's case, dynamic keyboards are mainly for expert users managing their own files, so the arguments might be different

(b) How should it work if there is an existing Optikey instance open? Currently, if you allow multiple instances in your settings, it will launch a new instance, but if you don't, it will silently fail. One might consider pushing the keyboard to the existing instance, perhaps.

Possible extensions

(c) Context menu items to right click on an XML file or a folder and "Open with Optikey" (d) Support new file extension .ok that allows you to double click a file and launch it directly, without faffing with command line args in shortcuts

@JuliusSweetland this could be considered ready to merge but would like to discuss the above first. @AdamRoden @lsaranto for input also

[lsaranto]

@kmcnaught Nice addition.

Here's what came to my mind. a) If a Back key is defined in the keyboard, IMO, it could load either the main menu or the dynamic keyboard menu. Or it could just default to another built-in keyboard like the Letters.

b) Both behaviors are good. IMO, you could pick either behavior as default and add a second parameter to do the other one. If you go with a second parameter for a new OptiKey instance, it could even override the multiple instance setting.

[JuliusSweetland]

Looks good @kmcnaught . My opinions:

a) Back should go back to the menu in Optikey Pro - this is most flexible for users as it allows them to go to the Dynamic Keyboard again, or anywhere else.

b) I think adding the extra logic to push the dynamic keyboard to the already open instance (in the scenario where multiple Optikey instances are NOT allowed) sounds like too much work for an edge case. I don't think failing silently is terrible - it should be obvious that there is an Optikey instance open already.

[kmcnaught]

Okay, I think unless @AdamRoden has strong opinions this PR will be ready to merge once I've implemented:

• [x] Add Back Action to take user to menu
• [x] Replace Quit key with Back key on keyboard menu (when opening a folder rather than a file)

[kmcnaught]

@JuliusSweetland This is ready for review/merge

[lsaranto]

@kmcnaught I managed to make my own build of OptiKey (yay!). It seems this new feature has broken the functionality of my dynamic keyboard trio. I previously had two typing keyboards -- one covering part of the screen at the top, one at the bottom. They both had a key to allow jumping between the keyboards as needed. They both had also a key to switch to a shared "minimised" keyboard containing just a single key: the BackFromKeyboard action. When I now select that action, instead of "restoring" the previous keyboard, it takes me to the dynamic keyboard menu (I guess this is how Julius wanted it to work). Is there a way to make it work as before, or is the only way to have two separate "minimised" keyboards with hardcoded keyboard names? (The key sizing issues appear to be fixed, which was the reason I had to use my own "minimised" keyboard. So I could go back using the built-in minimise function, but I like the added customizability.)

[kmcnaught]

@lsaranto this sounds like a bug. This PR in theory only changes "back" functionality from the first keyboard you launch directly into, it shouldn't affect what "Back" does after navigating via a ChangeKeyboard action.

Some thoughts:

• In your ChangeKeyboard actions, do you have the BackReturnsHere attribute set?
• Have you tested against the latest Optikey code as well as Adam's? At one point in the past his fork had swapped the default behaviour for BackReturnsHere. Or did you already bisect the code to attribute the issue to this commit?
• Where are you starting Optikey? In the dynamic keyboard menu or one of your keyboards?
• Feel free to upload your keyboards and I can take a look

[lsaranto]

@kmcnaught I always have the BackReturnsHere set to True. And I launch OptiKey by just running the (now my own) executable. I've set it to load a dynamic keyboard in the management console. I have not yet looked into actually using the command line arguments. I didn't see any docs about it, I guess because it's not yet included in any official builds.

I'll see how much this and the other little differences mentioned in the other thread bug me. To be honest, I haven't even remembered them today. I'll make a build using the OptiKey repo if I get a sudden boost of energy. :) now that I know how to do it.