Make it possible to change display name of commands in [Popup]custom command list

[byzod]

Describe your matter in detail

When use the custom command list popup, it's impossible to change the display name of command entries
Thus command with customizable behavior always have the same name, there's no way to distinguish them

Screenshots or further assistance

For example, I try to add 2 user script command in the popup, one of them is alert(1);, the other is alert(2);

Bind [Popup]custom command list to a gesture, when trigger it

What I expected:

There are two items in the popup, one is Say 1 and the other is Say 2, as I named them

What it actually is:

There are two items in the popup, one is Execute user script and the other is Execute user script too

Your System

• Operating system: win10 20H2
• Firefox version: FDE 90b9
• Gesturefy version: 3.2.0

[Robbendebiene]

I should have never introduced this command... 😖
Of course I acknowledged that this is a problem, even if it is a rare one.

This is related to #456 but in a different part of the UI.

[mortyobnoxious]

@Robbendebiene Except from the labeling/naming issue, is it possible to hide "inactive" items from command list popup.

For example "open link in new tab" doesn't work in some cases naturally. Hiding option for inactive items would be nice.

[Robbendebiene]

@mortyobnoxious This is currently not possible and probably will never be possible. Back when I designed the new "Multi Purpose Command" feature (the command popup is derived from it) I first thought about implementing this as a major feature in Gesturefy. So when you perform a gesture that has multiple commands assigned the command preview will show the exact command that will be executed under the current conditions.

This however would have required even bigger changes under the hood and also had some other drawbacks. For example one cannot always predict what command will/can be executed, because the conditions might be unknown or change at the time the gesture is performed. As an example the "Stop Loading" command might become "unexecutable" in the midst of the gesture execution. This uncertainty (even though it's rare) leads to inconsistencies in the concept. Also if one would test certain commands constantly for failure/success some performance pitfalls might arise.

So that's one reason why this feature went into a separate advanced command called "Multi Purpose Command" and is not as well integrated as it could potentially be.

---

All in all it's probably possible but very hard to get it right, because of the amount of states that might change and which the program would have to react to.

[Robbendebiene]

For my future me:

One possible solution would be to either manually or programmatically add an additional option/setting to each command that already provides at least one setting. Since renaming a command is especially useful for commands with additional settings (because they can behave differently) this seems like a decent solution.

This would also solve #456.

Drawback: Commands without settings cannot be assigned a name/label which is problematic if the user is discontent with the current name (for example because it is in a different language or too long). So this solution does not cover all potential use cases.

[byzod]

Drawback: Commands without settings cannot be assigned a name/label which is problematic if the user is discontent with the current name (for example because it is in a different language or too long). So this solution does not cover all potential use cases.

Command without settings always perform the same action, they're not polymorphic, so this behavior follows the design concept of command

I don't think it will cause problem