Hotkeynet comming back?

[Draku]

Maybe we should also stop using up and down here...

I think On/Off is better

So how about

So <Hotkey NUMLOCK(ON) CTL F1>

[Freddie]

I don't think definitions matter here. The point is, everything in a hotkey file looks like this:

<something arg1 arg2 arg3>

And you're suggesting adding three things that look like this:

something ( arg1 )

You don't think that's inconsistent?

I guess all I was doing was using existing keys and adding the brackets to separate the state.

Yes but you're adding something that doesn't currently exist in HKN's syntax, and thereby creating an inconsistency.

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

Yes, that's one of the advantages of your syntax. That's one of the reasons your syntax is used in industrial-strength programming languages like C and C++. But this doesn't change the fact that it's a different syntax from the one the program currently uses. The syntax must be consistent, so the only way I'd use your suggestion is if the syntax were switched over 100%. As I said in my last email, this would have advantages. But I think it also has the enormous disadvantage of appearing much more difficult to average people. That last consideration outweights all others, in my view.

[Freddie]

I think On/Off is better

Here's a good rule of thumb. When designing interfaces (whether it's a script language or the index of a book or the menu in a program), always pick the word that is most likely to pop into the user's mind.

Ttry it in an ordinary sentence.

"My cat jumped on the keyboard and pressed the key _____ by mistake."

Down or On? Which comes to mind?

[Freddie]

Hmm on second thought you're right about on/off. The key isn't down in this situation.

[Draku]

mmmh this stuff is not easy!

I think on/off is correct.......

I certainly would not want to change the whole syntax...it works well and is easy to use.

Problem (and I think you raised this before in this thread) is that we need to add a capability in the <Hotkey> definition to test a state before executing the hotkey commands. It is hard to be consistent when state checking is not really implemented elsewhere in HKN

The proposal is that the capslock on/off state is convenient because of the built in feedback mechanisms in the keyboard

I was associating the state with the key. This might not be useful. ie we could (although we probably dont want to) treat the capslock button completely separately from the capslock state.......this is probably not a helpful line of thought


Perhaps we go for

<Hotkey CTRL F1 CAPSLOCK=ON>

[Freddie]

I think on/off is correct.......

I agree with you. (I said so above, I changed my mind.)

Problem (and I think you raised this before in this thread) is that we need to add a capability in the <Hotkey> definition to test a state before executing the hotkey commands. It is hard to be consistent when state checking is not really implemented elsewhere in HKN

What we need to do is write code for two different states. One way to handle that is with testing. But that's not the only way. Let me illustrate with an example. When we added hotkeys that fire on key release, the syntax could have been designed like this:

<Hotkey F1>
IF release
do something
IF press
do something else

But here's how I designed it:

<HotkeyUp F1>
do something

<Hotkey F1>
do something else

The two chunks of code do exactly the same thing, but one tests explicitly and the other doesn't. I chose the second option because I think it's less intimidating to average users. We can do a similar thing with toggles.

Perhaps we go for
<Hotkey CTRL F1 CAPSLOCK=ON>

Once again, this is inconsistent with the existing syntax. The exisitng syntax doesn't use the equality symbol, and it has no concept of assignment or equality.

[Draku]

I understand your points (I think)

I would be happy.....if not delighted.....if I could say <HOTKEY CAPSLOCKON CTRL F1>..........and......to be honest I can appreciate that if we take the existing HKN language, then this is really very clear and easy...... (In other words I think I was wrong!)

I sort of think I have got carried away with this, but at least I now understand where you are coming from

[Freddie]

Cool. Your ideas were good ones -- I wouldn't say they were wrong. They just don't fit our constraint here. Our constraint is that we need a solution that matches the existing script language. (Or else come up with something that is so much easier for average users that it would be worth converting the whole scrpt language to the new syntax.)

I sort of think I have got carried away with this...

I don't think so, not at all. We only looked at three ideas! You want to get carried, away, let's try to list 25 ideas.

[Draku]

I am now worrying about whether we should be more verbose and precise......ie have CAPSLOCKLIGHTON, NUMLOCKLIGHTON,SCROLLLOCKIGHTON

as opposed to CAPSLOCKON, NUMLOCKON, SCROLLOCKON

.......Probably a bit too obscure/arcane/subtle (whichever you choose) too worry about

Anyway....any thoughts on where this is on your product roadmap???????

[Freddie]

Well somebody's gotta wory about it because every detail no matter how small has to be decided. With names, it's nice to do three things at once: (1) make them long enough so users know their meaning without having to look them up but (2) make them as short as possible and (3) make them consistent with similar names that are already in the program.

As far as (3) goes, the program already uses the names NumLock, ScrollLock, and CapsLock.

If we follow those three guidelines I think the choice makes itself.

Anyway....any thoughts on where this is on your product roadmap???????

I don't know. There are some other things I should probably do first, like add another background send mode and tweak all the background send modes so they work better (e.g. handle mod states properly). Then I should probably add "game guides" to the website that show people how to get started fast with various games. However it's much more fun to add new features to the program.