"Device State"-related thoughts

[Pfeil]

One feature that I intended to request for the tokens, but would work here as well, is a method of checking a trigger combination mapped to the command("When I press" of any type), without specifying the exact combination again.
E.G. if the command can be triggered by pressing "A", selecting "<When I press key>" in the relevant dropdown would make the condition return True if "A" is pressed.


With the added "Device State" tab the contents of the window appear offset to the left, I feel expanding the text boxes for the "old" tabs("Variable Name", "Variable Name / Token", "Another Variable", and "Text") towards the right side of the window(I'm always keen for more {token} real estate ), or perhaps centering the contents, would improve this.
On the other hand, if you get rid of the "Small Integer" tab(Which you've expressed a desire to deprecate in the past), it'd all fit nicely(Perhaps making the "Small Integer" tab show only when editing a condition containing it, or even not having a tab visibly selected when editing a "Small Integer" condition, so legacy support is still possible).


For both function and aesthetic, would it be feasible to use the "Add/Edit a Keypress"-style buttons to select the keypress(There's enough space to embed the "Ctrl", "Alt", "Shift", "Win", and "Press Key" icons in the "Device State" tab)?
This would also include the keyboard icon underneath the "Press Key" icon to select keyboard keys that can't physically be pressed(Like F13 to F24).
The default key selection could still be "Any Key", where pressing a key would replace it("<Any Key>" would still be at the top of the keyboard icon dropdown to enable re-selecting it).

I believe there's enough space to do the same with the "When I press button" and "When I press mouse" as well.

The logic dropdown("Is Pressed", "Is Not Pressed", "Only Key Pressed") could go below them.

A very quick mockup(which is of course easy to do, as I don't have actually have to make it work behind the scenes ):


If feel the currently implemented dropdown list is, in a way, less clear than the key name list for the "{STATE_KEYSTATE:}" token in the manual(less logically sorted at least), so having the ability to press the key(combination) seems easier to use.

Perhaps this makes it slightly less obvious that you can use the condition builder when you need multiple keys/combinations, but if you only need a single combination with a modifier key, having the picker for both in a single window would also be quicker.


More of a visual "bug" that isn't new per-se(but definitely not worth logging an issue for), but the tab button bar has an extra separator on the right side. This was true before the addition of the "Device State" button as well.
I'm not sure which type of control it is, so I don't know if there's a technical limitation causing it.

EDIT: Still applies to v1.7.5.45

EDIT #2: With the v1.8 GUI changes, none of the tabs have separators anymore, effectively solving this.


As an aside, "<Any Key>" and "<No Key>" could in theory be reduced to "<Any key>" with "Is Pressed" and "Is Not Pressed", but I assume it was done this way to make it clearer and prevent situations like

 


Also, something I hadn't noticed before: All regular windows I checked use solid F0F0F0 as the background color, however, the "Add/Edit a Keypress", "Command Shortcut", "Select Joystick Buttons",and "Mouse Shortcut" dialogs uses a gradient from F4F4F4 to EBEBEB instead!





I realize much of this comes across as backseat developing, but it's intended as a user's perspective. I don't mean to disregard the forethought that goes into these things


EDIT: To add insult to...more insult? I have to point out the changelog notes

Fixed issue where, 'Active Window' selection in, 'Perform a Windows Function' ceased to work.

Whereas the action is named "Perform a Window Function" is VoiceAttack.

EDIT#2:

Whereas the action is named "Perform a Window Function" is VoiceAttack.

[Gary]

I went through different layouts for the device condition screen.  My first inclination was to use the controls from the key selection dialog as that would make it easier in that case.  However, I wanted to minimize the amount of interface for that, as I see it as something that very few people are going to use and the ones that use it are not going to be using it regularly.  This has been a whiteboard item for a very long time, mostly because of all the hassle around the idea of making UI for it (again, for a feature that's going to be used relatively little... not much, 'bang for the buck', actually).  So, once I decided to just do bare minimum for UI, I got the feature out and (hopefully) usable in short order because the functionality was already built in (with tokens).  If it finds itself being used a lot, I'll probably pop more interface on it

You are correct about the Any/No key thing.  I had it just as you said:  'Any/All Keys' as one selection with both 'Pressed' and 'Is Not Pressed'.  It went through a few revisions, and I ended up splitting it after, 'Only Key Pressed' was added.

The small integer stuff will be nixed at some point and merged with integer.  Haven't made that jump yet

The gradients go way back to the first versions of VA... I haven't ripped it out of all the screens as I guess I've become blind to it lol.

Fixed the, 'Windows Function' thing


Thanks for all your help, Pfeil!