Create hairpin_creator_configuration.lua

[cv-on-hub]

hairpin_creator.lua only provides configuation via option-key, and us KM-freaks really hate selecting menu items manually. This companion script allows direct configuration of its user_settings file, and requires just one more menu item, just for those who need it. (Will shortly be looking at eliminating multiple menus in other utilities like barline_set and delete_selective)

[rpatters1]

Why remove menus in barline set and delete selective? Those seem to me like perfect use cases for extra menus.

[Nick-Mazuk]

Might I suggest using a mixin for the dialog? It can make the code simpler, and as of #253 they will work when scripts are downloaded from the website.

https://www.finalelua.com/docs/library/mixin

https://github.com/finale-lua/lua-scripts/blob/master/src/mixin/FCMCustomLuaWindow.lua

Checkout #183 for how mixins can simplify code creating dialogs.

Note that as of right now, mixins work but their actual methods aren't yet documented on the website. They all have documentation comments, but you'll have to read their code in src/mixin.

[Nick-Mazuk]

As for this script in general, I'm with the idea of it and would be ok merging it. However, there are a few discussion points to bring up.

First, checkout the issue I created #258.

---

Second, should we use this pattern for other scripts (i.e., as part of the convention in #246).

---

Third, if so for the second discussion point, we should offload as much as possible to a new library function. I think the ideal situation would be something like the following:

local configuration = require("library.configuration")

local config = {
    option_a = 0,
    option_b = true,
}

-- this function does everything from displaying the dialog to saving the file
configuration.show_configuration_dialog("hairpin_creator.config.txt", config)

That way, future scripts can do the same thing with pretty much no boilerplate.

[rpatters1]

I'm not sure why we need to add a 2nd copy of this script. Whether you add a menu option with AdditionalMenuOption or add it as a new script, the net effect is the same: another menu option has been added. Instead of adding this script, just add the additional menu option to the original. (But keep the option key as a second way to open the config, because see next paragraph.)

What I need to think about is a way to selectively suppress menu options in RGP Lua. I don't have a good idea at the moment, but maybe something will come to me. If these menu options needed by KM could be optionally suppressed in favor of option-key opening the UI, that would allow either way of working. I am curious to know if there is any way to modify menu selection so that KM could trigger different behavior when selecting it. If there were, I could add it to RGP Lua.

I should be clear that if I had to select from the flat menu that RGP Lua (actually Finale) presents, I would not be selecting from the menu either. I use JWLuaMenu to organize my menus into a sensible, mouse-accessible hierarchy.

[rpatters1]

I had already been thinking along the lines of a generic user settings dialog. (Note: user settings, which have a slightly different input parameter for the name. Which I made a function for in general_library.)

It would be nice to keep the configuration library independent of general_library, though it may be more trouble than it's worth. Also, I'm not sure how a library function should show a proper dialog. It could mean reinventing UserValueInput, which was awful. Maybe a dialog could be passed to the function, but that would create a lot of dependencies.

[cv-on-hub]

Why remove menus in barline set and delete selective? Those seem to me like perfect use cases for extra menus.

The advantage is that the original doesn't automatically load the extra menu item except for those who can't, or don't want to, use option key invocation.

Another solution for menu overload, apart from JWLuaMenu, is if RGPLua would allow more than one "group" folders. Most users won't load the entire repo, but you're right Robert - it's now a handful.

[cv-on-hub]

Might I suggest using a mixin for the dialog?

I've noticed a lot of mixin action on the repo lately without any idea what it is. Will investigate!

[rpatters1]

Oh, I didn't realize barline set or delete selective had UIs. I though they were just an array of (useful) options without UI.

if RGPLua would allow more than one "group" folders.

Could elaborate on that?

I was serious about asking the KM guy if there any way it could select a menu "differently" than normal. If not a modifier key then some other way.

[cv-on-hub]

Oh, I didn't realize barline set or delete selective had UIs.

They don't - yet. I was considering ways to reduce menu proliferation and introducing a dialog to each that responds to a single "code" key to make the selection. This would mimic the behaviour of Nick's SuperUser macro palettes, but within Lua instead of KM.

Could elaborate on that?

My Lua scripts are in >RGPLua along with the plugin. If I add an extra Auto Folder it appears in the plugins menu but is empty, so I assumed that RGPLua only allows one Auto Folder. I imagine JWLUaMenu simplifies the problem, but have never needed it with KM in charge.

[rpatters1]

I would discourage using a code key to make the selection in this repository. Scripts here need to be accessible both with and without KM. A code key approach is more suitable to a stand-alone package like the JetStream Controller package. It seems fairly user-hostile for a non-KM user.

RGP Lua can have as many auto folders as you can configure. I'm not sure why your second one was empty, but the challenge is that Finale dumps all the menu options from all the auto folders into a single flat menu. So some kind of strategy is needed to make them human-accessible.

[cv-on-hub]

I would discourage using a code key to make the selection in this repository

Sorry - I explained it badly. Not selecting other scripts in the repo or in the menu. The (single) script puts up a dialog (as attached) and responds to the user's keystroke with the requested action. Interesting about the second Auto Folder - empty after a couple of attempts!

[rpatters1]

I am of the opinion that the best UI is no UI. And that is especially true if I am driving (rather than KM or the equivalent). So I would vote for the menu options. But ymmv.

[jwink75]

If I had a nickel for every time someone asked what their “code” was for JetStream…

…

Sent from my iPhone

On Jul 16, 2022, at 7:20 PM, rpatters1 ***@***.***> wrote:  I would discourage using a code key to make the selection in this repository. Scripts here need to be accessible both with and without KM. A code key approach is more suitable to a stand-alone package like the JetStream Controller package. It seems fairly user-hostile for a non-KM user. RGP Lua can have as many auto folders as you can configure. I'm not sure why your second one was empty, but the challenge is that Finale dumps all the menu options from all the auto folders into a single flat menu. So some kind of strategy is needed to make them human-accessible. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.

[cv-on-hub]

This humble thread has become seriously divergent, so an attempt to pull it back together:

1. I'm reworking modeless dialog scripts to use mixin (using the transpose_by_step template)
2. is there consensus on whether to:
   (a) allow this separate config script so it makes an extra menu item only for those who need it;
   (b) include it as an additional menu in the parent script; or
   (c) leave it to the option key invocation alone?
3. Since JWLuaMenu can sort scripts into sub-folders, is there some way RGPLua could do the same?

[cv-on-hub]

Oh yeah, but also:

Nick (automated configuration dialogs): we should offload as much as possible to a new library function

4. Great idea, though to handle booleans, floats, popup etc, probably means emulating most of the dialog contents in the setup parameters.
5. (Robert ... other ways for KM to activate menus) Peter Lewis also suggested simulated mouse option-clicks on the actual menu items which I tried in many permutations with no luck. I can only think that Finale is hiding modifier key data from the plugin.

[rpatters1]

If all the dialog box does is offer a list of otherwise non-configurable options to choose from, I think menu options are the correct choice and let's not even have a dialog box.

Finale is what puts all the scripts in a single flat menu, not the plugin. Plugins have no direct control over it. The JWMenuLayout function could be rolled into RGP Lua, but understand that the way it works is to look through the plugin menu for certain menu text and then move the items it finds. This happens after Finale has built the menu, so only one function can do this or else the results will be unpredictable. I think it's better as an external function, since then it can merge any plugin menu item and not just those for RGP Lua. (But see caveats in the documentation for JWMenuLayout.)

I assure you that Finale is not hiding modifiers from the plugin. The modifier data is there in the event when a human selects a menu option. But what I could do (and probably will do) is add a real-time shift-key checker. This would simply check the state of the key at the instant the routine is called. Then your simulated mouse clicks should work, provided you leave the modifier key pressed a few ms for the script to pick it up.

[rpatters1]

If it helps, the event that has the modifier keys is the NSEventTypeLeftMouseUp (mouse up) event. If you programming both the mouse down and the mouse up, you should add the modifier key to the mouse up.

[cv-on-hub]

2. The "simple" example I showed above, offering non-configurable options, was for a different process. hairpin_creator_configuration.lua that started this thread is a vital configuration component of hairpin_creator.lua that definitely requires a dialog box. In the hope that modifier key response might be improved one day I'll leave it just with option/shift key access, and not introduce a new stand-alone script.
   3., 4., - great.

[cv-on-hub]

the event that has the modifier keys is the NSEventTypeLeftMouseUp (mouse up) event

Still no joy from KM.

[rpatters1]

Still no joy from KM.

When I get a spare minute I'll build a version of RGP Lua that looks directly at the modifier keys and see if it does any better.