logicalLayer.replaceTrigger or some such

[DougSelph]

It would be nice to have a way of removing a trigger based on a key or condition match, or a way of adding a new trigger that replaces any action already there.

I just spent a few hours figuring out why my new 'KEY.T' trigger action was behaving so bizarrely. It was because ExampleBase already tied KEY.T to a wireframe toggle. I had assumed wrongly that when I did _logicalLayer.registerTrigger(new KeyPressedCondition(Key.T), action) that it replaced what was already there.

As it stands I will go through the triggers and delete the existing one that matches KEY.T; but that kind of activity really belongs in the logicalLayer class.

(If you wish, I can implement it and submit a ticket, once you indicate how you prefer it to be handled).
Thanks,
Doug

[renanse]

Hmm, how do you propose to check if another trigger matches? Seems like a difficult task since you could conceivably have two predicates that respond to the same stimulus, but not be "equals" in the traditional Java sense.

[DougSelph]

Well, what I had in mind, for starters anyway, would be at least to enable matching simple key inputs.

So just for clarity the code for this is listed below.

Let's say we have the following code we want to work:

Code: Select all

      InputTrigger match = new InputTrigger(new KeyPressedCondition(Key.T), null);

      for (InputTrigger trig : _logicalLayer.getTriggers()) {
         if (trig.equals(match)) {
            System.out.println("FOUND MATCH!");
            // Do something here like schedule this trigger
            // to be unregistered after the loop is done.
         }
      }


InputTrigger would override it's equals():

Code: Select all

    @Override
    public boolean equals(final Object obj) {
        if (obj instanceof InputTrigger) {
            return condition.equals(((InputTrigger) obj).condition);
        }
        return super.equals(obj);
    }


And likewise KeyPressedCondition would override it's equals():

Code: Select all

    @Override
    public boolean equals(final Object obj) {
        if (obj instanceof KeyPressedCondition) {
            return key.equals(((KeyPressedCondition) obj).key);
        }
        return super.equals(obj);
    }


Then, for completeness the other conditions could define their own similar matching equals() routines as well.
Does that make sense?
Doug

[petterm]

For what it's worth, the current behaviour of not replacing existing triggers with identical conditions when a new one is added was intentional. I wanted it to be possible for people to trigger more than one action for a single key. That may or may not be a good thing. Adding an implementation of equals() (and hashCode()) to the InputTrigger class would disable that feature.

I think that configuring key bindings in different places in your code is probably a bad thing, as it becomes harder to figure out what key bindings should be there. So ideally, 'real' code shouldn't be based on the ExampleBase.

One use case I can think of for replacing an existing key binding is if you allow users to bind keys to specific actions themselves. But ensuring that key bindings are 'unique' in that scenario should arguably be done at a higher level than the LogicalLayer. That use case could be supported by doing a getTriggers().clear() and then re-adding the desired triggers.

That solution would have the benefit of keeping the LogicalLayer API small and focused, at least. Would that solve your problem?

[DougSelph]

Actually I think you are right.
The key bindings should only happen in one place for clarity sake.
So I have been doing mass-copy and replace on registerTriggers() and that is probably the best way to do it.
Okay.
Thanks,
Doug