For menu commands on pieces, the “Restrict Commands” trait gives the option to Hide/Disable commands, however there is nothing similar for GKCs.
It would be useful to have the ability to add an optional conditional test to a GKC that must be satisfied to enable the GKC.
Note this is different from the current matching expression field, which limits the GKC applicability to various pieces - as opposed to wholesale disabling the GKC.
IF the GKC is disabled (i.e., does not match the optional conditional test), then the GKC would be grayed out and nothing would happen if you click on it (similar to how the current restrict command works).
So for a GKC on a toolbar, what were you thinking to test against for whether to allow/not-allow the GKC? Presumably Global Properties or (if on a map), Map Level Properties? If so, those are all available to you already in the Matching Expression field.
I’m not clear on why that doesn’t suffice? If I’m missing some reason that approach doesn’t work I might need a more specific example of the sets of conditionals you want to check and why just including them as && in the matching expression field wouldn’t work.
Yes, it would be a test against global module or map level properties.
As I understand it and I think as @Korval said, there are a couple of potential benefits;
This would enable a button to be greyed out if it is not active - just like window buttons are greyed out to players who aren’t on the “belongs to” list.
This “authorization” expression would not be evaluated during the search for pieces.
The logic in a GKC definition would be better separated.
On point 3, at the moment, the logic to exclude use of a GKC button gets mixed up with the logic of what the GKC button is intended to do. This can make for some complicated configurations. Now, bear in mind that if the Reporting field is used, that will also have to have both “authorization” and “execution” components (effectively, duplicating the authorization part of the search field, at least). Finally, the “authorization” has to be repeated for each GKC button tied beneath a Multi-Action button); which is why I would like to see @Korval’s request extended to MA buttons.
In fact, if only one could be chosen, I would ask for the Multi-Action button to have this feature, because then at least, an MA button could front-end any GKC or other button to provide this functionality.
One issue with this is that, since properties can change at any time (after any mouse drag, keystroke, or button click), all of these expressions would have to be checked and re-evaluated every time pretty much anything happens – every time there’s a click, drag, or key press. So there’d be some overhead in that. Maybe okay amounts of it, but we all know beanshell is not “the fastest knife in the drawer”.
As less costly alternative that came to mind was to include a secondary reporting field to give module devs the option of a chat message, or more suitable, an Alert() to let the player know why the button wasn’t working.
Okay I futzed around a thing because I can’t help myself.
If someone wants to give the ToolbarButtonDisabler branch a try at vassalengine.org/builds when it becomes available (probably about 15-20 minutes after this message) then let me know if it is decent. It seems to be working for me. The PR, below, has a screenshot if you just want to oogle.
I’ve tried ToolbarButtonDisabler on a test module, but I can’t get it to disable a button. Is it fussy about the type of Global Property? Or maybe I just got the syntax wrong…
The GKC button is in the French Hand private window, and the Global Property is in the window too. The controlled button is “Draw QG Stock” (above) and the GP can be toggled via the “Change” button.
Are you minded to try a Beanshell expression field ? I have a few GKC buttons in mind that I’d expect to give a good handle on any performance drag, and at what point it starts to become an issue (assuming there’s any doubt).
Beanshell expression field is definitely a no-go because it would have to be checked “after almost each and everything that ever happens in the module”.
We went with the Global Property version because we can put a listener on that which effectively means it gets checked only when the property changes. So that means it’s up to you to “switch the button on and off” from within your module, but you can decide the right time and place for it.
We can probably fix it so the “global” properties on the map work too, though.
There is one common application of this that I can think of that might be difficult; that is PlayerSide checks. This will be awkward to make work, I suspect. Maybe something particular could be done for that, as it is one of those properties that varies between local instances but isn’t something that would need refreshing.
I’ll have a go and see what a bunch of my GKC buttons might look like using the GP check.
I pushed some code to let Map-level global properties work too, where appropriate, so when the next build of ToolbarDisabler comes up check that out (15-20 minutes)
Seems like if it’s doesn’t-need-refreshing kind of a thing, that you could use expressions inside a piece (in a Set Global Property field expression, or a Calculated Property) to do the checking and set the main Global Property. You’d then activate that from e.g. a Startup Global Key Command or some other appropriate type of place?
That worked! Nice that it works with a Global Option Property too, as that will help with user-specific validation. Here’s a test; my CCN x1 die button is disabled. I like how you don’t need to specify an alternative button to get this greyed out effect, same as window buttons.
I have some further thoughts; next reply coming up.
Reviewing GKC buttons for my testing, I concluded this GKC button grey out thing is something of a secondary luxury (@Korval may disagree) … it’s nice and somewhat useful, but expression-based validation is more important to me and, from what’s been said, I imagine its feasible except for the button image refresh.
My fear is that without the expression possibility, the GKC button disabler will be restricted to simple cases, or the logic to maintain the GP in the right state will be convoluted and prone to error. It will certainly be harder to port from old version to this new function.
Here’s my thoughts on a solution:
Retain the new configuration options in the current ToolbarButtonDisabler build.
It would help if this feature allowed a comparison of some kind. No expression field but perhaps a fixed comparison to constants or a regex.
i.e. Button will be disabled if: (property name) (operator) (fixed value or regex)
Add an expression field & a “Hotkey”. The result of the expression will determine whether how the button proceeds. The expression has no effect on the button image. To this extent the button is still “active”. Result will be either
i) The Hotkey fires if specified and exits the button. (The Hotkey gives flexibility to the mod dev as to what should happen in this alternate button state; maybe an Alert() to the user advising them that they can’t use the button).
or
ii) The button continues to execute as normal
This second method will be independent of the first. If both are used, the second will only apply if the button is not disabled by the Property check.
To repeat a point; to get significant benefit, the function has to be in the Multi-Action button, so that validation can be at the top-level of a chain of buttons. Having it also in the GKC Button is useful because that’s a very common need but the MA button gives the most generalised solution (the mod dev will be able to filter all types of buttons, by putting an MA button at the front-end, even of single buttons).
As I write this, I have no idea of the amount of work required, so I make no presumptions.
I’m not sure why you wouldn’t implement that with a toolbar button that sends a GKC to a single “secret hidden piece” that then does all the rest of your validation and proceeds or doesn’t proceed?
When you put it like that, I wonder why gkc buttons exist as a parallel of the gkc trait. Ease of use is the one thing I can think of but with the current limitation, I think you are right and a piece would organise the logic more efficiently.
If a “secret piece” was built in to every map and a map Action Button were able to send a command to its local map piece, the gkc button would be redundant entirely. Maybe that’s too wacky an idea?
I have no doubt that in V4 there won’t be such a weird disjoin between “toolbar buttons” and “pieces”. The “secret piece” can be hidden and immobile … OR it can just be some other piece that’s always there. Like I think PoG uses the turn marker as its little event handler thing.
