Build 19: Active window tracking

[Freddie]

minor unrelated bug report: I tried to assign NumLock to toggle broacasting on/off so I get some visual feedback on my keyboard (pending the overlay or semi transparent status window ) but if I do it eats the event and my keyboard light doesn't toggle anymore
(tried to put both nothing and "when numlock is on" which didn't work; and pressed "numlock" which worked (toggles it in mojo) but then doesn't toggle the light on my keyboard anymore

I know why this happens but I don't know how to design the program to deal with it.

When a keystroke triggers a hotkey, Mojo takes some action. Then it has to decide whether to pass the keystroke to the operating system so the OS and other applications can take whatever actions they would normally take if the keystroke had not been redefined as a hotkey trigger.

(I said the other day that I don't like the word "pass" but in this case, Mojo really is allowing something to pass.)

By default, Mojo doesn't pass hotkey triggers to the operating system. Triggers have been redefined by the user to be commands to Mojo, and Mojo processes those commands, and that's the end of it.

When this happens, users often say that the hotkey program "swallowed" their keystrokes. This isn't right because they redefined the keystrokes themselves, and the keystrokes got processed.

But it's convenient to say the keystrokes get swallowed (you said eaten) so I'll say "swallowed" too.

Now, the thing is, sometimes the user wants the trigger to get swallowed and sometimes he doesn't. The way I handled this in HotkeyNet was with a keyword, <PassThrough>.

You're familiar with HotkeyNet so I 'll illustrate this with two examples from HotkeyNet's script language. We're talking about the difference between the two following hotkeys:

<Hotkey NumLock>
   <SetWindowBroadcast toggle>
 
<Hotkey NumLock>
   <PassThrough>
   <SetWindowBroadcast toggle>

The first one would have the side effects you've reported here. The second one would not.

That's fine for HotkeyNet because everything's defined by the user in a script. But Mojo's supposed to be easier to use.

So the question here is, how to handle the issue of passthrough or not passthrough.

I would like to hide this decision from the user but I can't think of any way to do that, that would really work.

The only thing that occurs to me is to add it as a checkbox on the Set Trigger dialog. In this case, with this hotkey, when you make the trigger, you'd check "PassThrough."

[Fursphere]

Numlock Light Toggle as a visual indicator:
- A visual onscreen overlay will solve this. So I feel the numlock issue should be pushed aside as something else is already planned. I don't think creating two workarounds for one "root" issue is a good way to spend time.

[Moorea]

(about numlock example)

cool so maybe add checkbox to the dialog "with pass thru" option ?

that or automagically treat the checked "when numlock is on" and nothing in the top (keyed in) section as meaning that you should just look at the key status but not consume it ?
(as I assume that if I say for instance "A" and numlock on; you won't touch / do anything with numlock on/off transitions)

(about mojo getting raised when mouse is on another screen)
any chance to make that invisible window independant from mojo's other windows so only the invisible one gets raised by the OS (if it's not possible to make it not do that at all)

I'll add apply in the feature requests in case you forget but for bugs do you need something to track them?

[Moorea]

ps: Fur: I agree a visual overlay would fix my numlock issue but I suspect eating up the key in all cases may have other consequences and so the option to look/peek instead of consume the event is probably valuable for other advanced use - minor though I'd agree - I'd rather get some basic DNP and click broadcasting than this (in term of order)

[Fursphere]

ps: Fur: I agree a visual overlay would fix my numlock issue but I suspect eating up the key in all cases may have other consequences and so the option to look/peek instead of consume the event is probably valuable for other advanced use - minor though I'd agree - I'd rather get some basic DNP and click broadcasting than this (in term of order)

True. Can you clearly define the issue / request and add it to the FAQ Request post?

[Freddie]

Numlock Light Toggle as a visual indicator:
- A visual onscreen overlay will solve this. So I feel the numlock issue should be pushed aside as something else is already planned. I don't think creating two workarounds for one "root" issue is a good way to spend time.

It's really a question about passthrough not numlock. It just happened to get noticed for the first time with Moorea's numlock hotkey.

It has to be decided sooner or later because it's going to affect a big percentage of user-defined hotkeys.

It's not a work around. It's a choice of two ways that hotkeys can work and the choice has to be provided.

[Moorea]

I think I added them in
http://www.dual-boxing.com/showpost....12&postcount=2
and a new
http://www.dual-boxing.com/showpost....12&postcount=3

[Freddie]

(about numlock example)

cool so maybe add checkbox to the dialog "with pass thru" option ?

Unless somebody thinks of something better.

that or automagically treat the checked "when numlock is on" and nothing in the top (keyed in) section as meaning that you should just look at the key status but not consume it ?

"When numlock is on" is a state, not an event. Only an event can trigger a hotkey. You have to do something (press a key) to make something happen. Which key do you press? That's what the top section is for.

(as I assume that if I say for instance "A" and numlock on; you won't touch / do anything with numlock on/off transitions)

I'm not sure I understand. Are you saying you define the trigger NumLockOn A?

That means, "If I press A while NumLock is on, Mojo should do the action."

There's no way to infer anything about passing from that trigger. Two people might define hotkeys with that same trigger. The first person might want A to pass, and the second might want the opposite.

(about mojo getting raised when mouse is on another screen)
any chance to make that invisible window independant from mojo's other windows so only the invisible one gets raised by the OS (if it's not possible to make it not do that at all)

I'm looking at the source code and it looks like the invisible window isn't even a factor. I'm not sure why this is happening.

I'll add apply in the feature requests in case you forget but for bugs do you need something to track them?

I think probably it would be better if I track bugs myself because users have no way to know whether something is a bug or unfinished work.

If you include unfinished work in the bug list you would immediately have dozens or maybe hundreds of items and it would only make the program look bad.

[Akoko]

Would it be possible for it to only track WoW windows (and maybe Mojo window(s))? I find it super annoying that it's continually mousing over to my internet browser when I don't want it to!

[Freddie]

Would it be possible for it to only track WoW windows (and maybe Mojo window(s))? I find it super annoying that it's continually mousing over to my internet browser when I don't want it to!

Active Window Tracking doesn't distinguish one program from another but you might be able to get the effect you want some other way.

For example, you could set all your WoW windows "topmost" (always on top). That way your browser wouldn't cover up a WoW. That's not quite what you want , though.