Hotkeynet comming back?

[Freddie]

I should mention, in case anybody doesn't know, that HotkeyNet lets you use all your keyboards and they can do different things. So F1 on the first keyboard does one thing, but F1 on another keyboard does something else. Every keyboard can control all the PCs because all PCs are equal with HKN -- there are no primaries and no secondaries. I myself use three keyboards when I multibox, and each keyboard controls all five of my toons.

I'm mentioning this because almost everyone who emails me for help is using HKN as if it's a keybroadcaster, with one machine that sends keypresses to others. You can use it that way if you want, but that's a fraction of what it can do. It's a program that makes all pc's capable of controlling all pc's.

Could we make the tray icon show more than 2 states?

If we do this (a) at best it's going to be limited to one key and (b) the icon would become much harder to interpret with a glance.

In comparison, the LEDs (a) work with three keys and (b) don't reduce the clarity of the icon at all. So LEDs seem better to me. It's true that the icon would allow you to choose any toggle key you like, whereas the LEDs restrict you to three pre-selected ones, but this limitation seems unimportant to me because the LED keys include the only key on the keyboard that is perfect for this purpose -- the NumLock key. It's perfect because it has no other purpose except to be a toggle key, so you lose nothing when you select it for this purpose. The Scroll Lock key is nearly as good because it no longer does anything in most programs. The Caps Lock key is probably the worst key on the board for this purpose because it changes the built-in function of every printing key, but two out of three isn't bad.

Also, LEDs have the enormous advantage of allowing you to use combinations of your three toggle states (e.g. both NumLock and ScrollLock down at the same time vs. only one of them down). This would give you seven toggle states in all vs. just two toggle states with the icon.

[Draku]

Regarding the multi-kb thing.......that is interesting........I need to give that some more thought...

So, having caps lock, num lock and scroll lock plus combinations would be perfect.

Is there a way that to stop Numlock making the numpad keys the direction keycodes? or is that a hardware thing. In other words, I would like to have numlock change the meaning of F1-F5 and leave the numpad keys unchanged. If this is impossible, which the more I think about it the more unlikely it is to be possible, then it will still be fine if I can use capslock and scroll lock.

Would this functionality be hard to implement?

By the way, a solution to feedback could be adding extra tray icons I know I have a wireless keyboard where the software does this for capslock and numlock

[Freddie]

Is there a way that to stop Numlock making the numpad keys the direction keycodes? or is that a hardware thing. In other words, I would like to have numlock change the meaning of F1-F5 and leave the numpad keys unchanged.

There's no difficulty here. The only hard thing is figuring out a syntax that allows users to request this behavior in a way that makes it simple to understand.

Would this functionality be hard to implement?

No. But it would take a few hours, mostly for documentation.

By the way, a solution to feedback could be adding extra tray icons I know I have a wireless keyboard where the software does this for capslock and numlock

I'll think about it.

[Draku]

No. But it would take a few hours, mostly for documentation.

Can I help? If you come up with the design, I would be happy to draft something and then you can use or not

[Freddie]

Well first we have to figure out the syntax. Actually first I have to decide if I want to do it. It's a good idea but maybe something else should get done first.

But if you want to make suggestions about the syntax, fire away. I was thinking:

<Hotkey X> always gets triggered by X regardless of toggle state.
<Hotkey NLUP X> gets triggered by X only if num lock is up
<Hotkey NLDN X> gets triggered by X only if num lock is down

when you add in the new modifiers, this could get pretty verbose:

<Hotkey NLDN SLUP numpad_end LSHIFT LALT F3>

It will have to be illegal (generate an error) if somebody tries to define a toggle key as a modifier and also use it as a toggle.

The syntax for numpad keys is going to have to be a special case since they each have two names, depending on whether num lock is up or down. I think the least-confusing thing will be to require people to define two hotkeys for those keys if they want both NL states to do the same thing for those keys.

[Draku]

If we constrain it to just caps and scroll, it seems to be a nice and logical extension to current functionality

Syntax - I would go for

<Hotkey X> always gets triggered by X regardless of toggle state.
<Hotkey NUMLOCK(UP) X> gets triggered by X only if num lock is up
<Hotkey NUMLOCK(DOWN) X> gets triggered by X only if num lock is down

[Draku]

The syntax for numpad keys is going to have to be a special case since they each have two names, depending on whether num lock is up or down. I think the least-confusing thing will be to require people to define two hotkeys for those keys if they want both NL states to do the same thing for those keys.

This sounds fine and easy to understand

[Draku]

<Hotkey NLDN SLUP numpad_end LSHIFT LALT F3>

<Hotkey NUMLOCK(DOWN) NUMPAD_END LSHIFT LATL F3>
verbose yes, but fairly logical I think

[Freddie]

HKN has about 30 keywords, and for every single one, the syntax is like this:

<Keyword Arg1 Arg2 Arg3>

Now you're suggesting that for three new keyword, they should have a different syntax like this:

Keyword ( Arg1 )

I think syntax should be consistent. This is very important. It makes the program easier to understand and use.

However. Let's consider switching all the functions over to your syntax. That would be consistent. It would look like this:

Hotkey ( NumLock ( down ) X )

I've actually thought many times that maybe I should do this. In fact, if I had written the program for myself, I would have done it this way from the beginning. It has the great advantage of allowing nested functions, as this example shows. Also it's familiar to programmers since it's C syntax. But I think it has the disadvantage of making the program even geekier and more frightening for the average person than it already is.

[Draku]

mmmh.....

I wasn't treating NUMLOCK as a keyword but as a key. or are all keys keywords?

I was adding () to indicate state....

When you proposed NLDN and SLDN was that intended to be new keywords? or were you abbreviating NUMLOCKDOWN and SHIFTLOCKDOWN?

I guess all I was doing was using existing keys and adding the brackets to separate the state. it seemed like a good idea so that if you need to refer to whether a key is down or not in the future you would have the syntax