Build 11 -- Hotkey triggers

[Freddie]

ElectronDF suggested the other day a hotkey to bring the cursor home during mouseover. To do that, we need a dialog box where people choose a "trigger." Triggers are key combinations that make hotkeys fire.

I tried hard to make the dialog box as simple and easy as possible. I think there's room for improvement. Please tell me if you have any suggestions. To use the dialog box, go to the Debug menu and choose the first item.

In build 11, the dialog box looks like this:

http://mojoware.org/art/build-11-1.gif

In addition to the dialog box, there's a lot of code behind the scenes that checks whether the user's choices are valid or not. If you play around with different key combinations, you'll generate a lot of error messages. For example, you might see this one:

http://mojoware.org/art/build-11-2.gif


Finally, there is a new help page on Mojo's website that explains a little bit about triggers. If you have any suggestions for improving the page, please let me know. It's here:

www.mojoware.org/help/triggers.html (http://www.mojoware.org/help/triggers.html)

[Coltimar]

I can't get Mojo to pickup WoWs, lol. I'm gonna try it on another PC.

[airlag]

Hi, nice to see you here :)
I use HKN for a while now. Of course I'd like to see Mojo being as mighty as HKN. Don't kill me for asking too much with my first posting ;)

So here is my suggestion for improvement:
We have basically 3 types of keys

1) Hotkeys - trigger once when pressed or released. Maybe 2 different actions when possible? You already need 2 actions for just mirroring a standard keybord action, key down and key up. So it would be natural to allow free programmed actions on pressing/releasing a hotkey.

2) Modifiers - "natural" modifiers are capslock, scrolllog and numlock. It would be nice to define modifier keys freely. I made capslock of the keyboard to a normal hotkey to prevent SHOUTING ACCIDENTLY AT PEOPLE IN CHAT. I made pause to a modifier that pauses HKN. You see what I mean. If you implement this you need to create the "Execute the hotkey only when" section of the above window dynamically.

3) Movement keys - are special in HKN, but with 1) fully implemented they are only a subclass of Hotkeys. Instead you may need a key repeating trigger (delay and repeat time freely defined for every repeating hotkey). That would be an improvement of Hotkey triggers again :)

[Aragent]

Just Checked the Dialog box out, Am I correct in assuming (I hate to assume But the jest I got was) this is only a test of the menu and nothing is actually being stored yet from the dialog box.

It definitely appears that we will be ably to have enough combinations to get the job done.

My one question, (since you have stated before you would like to keep the average user out of the mojo directory)
are you planing a way for users to see what Hotkeys have been set in the past, by maybe graying out an established key combination and or give waring if were about to overwrite an existing key combination with one thats already established?

I understand this is very early in the stages of hotkeys
Just trying to get a feel how you planed to handle the storing of the key combinations.

[Ghallo]

Instead of manually choosing the hotkeys, how about having an input box where the user just types in the hotkey and you detect the mods?

[Freddie]

1) Hotkeys - trigger once when pressed or released. Maybe 2 different actions when possible?
Both HotkeyNet and Mojo can perform millions of actions when you press or release a key. But the key can only be pressed or released because that's all a key does. The key can only be pressed or released because that's how they build keyboards at the factory.

Pressing or releasing a key is input. What Mojo does is output.

Most of your comments here about about output -- what Mojo does. This dialog box is only about input. This dialog box has absolutely nothing to do with output.


So it would be natural to allow free programmed actions on pressing/releasing a hotkey.
HotkeyNet does this and Mojo will also do it. It's going to have a powerful programming language, much more powerful than HotkeyNet's.


2) Modifiers - "natural" modifiers are capslock, scrolllog and numlock. It would be nice to define modifier keys freely.
Edit: I misunderstood this because you're using "modifier" in an unusual way. "Modifier" usually means Shift, Ctrl, or Alt. The three "lock" keys don't have a name, so I call them lock keys.

These three keys generate states that are built into the computer. If you have a desktop keyboard you can see that these three states are built into the computer because the keyboard has LEDs for them. These three states are *input* to Mojo because they are external to Mojo.

You will be able to create additional states with Mojo, just like you can with HotkeyNet, but additional states are output. They are something that Mojo does. This dialog box is only about input, things that are given to Mojo.

As for "modifiers" in the normal sense of the word (Alt, Shift, and Ctrl), Mojo can use any key as a modifier now, and if you play with the dialog box you will see that it accepts any key as a modifier. This is explained on the documentation page I linked at the bottom of my previous page.


I made capslock of the keyboard to a normal hotkey to prevent SHOUTING AT PEOPLE IN CHAT. I mad paus to a modifier that pauses HKN.
You will be able to do that sort of thing with Mojo. If you think this dialog box limits that, you are misunderstanding it.


You see what I mean. If you implement this you need to create the "Execute the hotkey only when" section of the above window dynamically.
No, the section doesn't need to be dynamic to allow those features. That section corresponds to states that are built into the computer. Mojo's abilities are not limited to what is built into the computer.

Once again, this dialog box is only about input, i.e., things that are external to Mojo, i.e., the keyboard.

[Freddie]

Instead of manually choosing the hotkeys, how about having an input box where the user just types in the hotkey and you detect the mods?

Edit: Let me clarify something just in case it's unclear. You can press keys in this dialog box and the dialog box will record them.

That was the first thing I tried but it doesn't work for at least three reasons..

1. The user may want to enter Shift instead of LShift or RShift, and there is no Shift key. Same for the other modifiers.

2. The user may want to enter mouse buttons, but at least one button can't work that way because at least one button has to be "meta" to the entry field for navigation in the dialog box.

3. The user may want to enter keys that don't exist physically on the keyboard. (There are many dozens of such keys.) This is very useful when making hotkeys that get triggered by other programs or hardware devices.

What I've thought of doing is making two dialog boxes, a simple one that works the way you say and the current one. The simple one would come up by default, and it could contain a button that brings up the second one.

But even if I end up doing that, this first dialog box needs to be tested and improved and debugged.

[Freddie]

Just Checked the Dialog box out, Am I correct in assuming (I hate to assume But the jest I got was) this is only a test of the menu and nothing is actually being stored yet from the dialog box.
That's correct.


It definitely appears that we will be ably to have enough combinations to get the job done.
Yes, especially if the user is willing to "sacrifice" some keys to be used as modifiers. In that case the number of triggers is many millions.


My one question, (since you have stated before you would like to keep the average user out of the mojo directory)
are you planing a way for users to see what Hotkeys have been set in the past, by maybe graying out an established key combination and or give waring if were about to overwrite an existing key combination with one thats already established?
Yes, any time the user enters a setting that could inadvertently affect a different setting, the program will issue a warning.

If you try this dialog box and look at the many warning messages it generates, I think you'll see that I'm pretty compulsive about checking the user's input and warning about potential problems.

[Freddie]

I can't get Mojo to pickup WoWs, lol. I'm gonna try it on another PC.
I'd sure like to find out why it's not picking up your WoWs.

Can you help me test that and figure out the reason so I can fix it?

[Coltimar]

Sure, I'll PM you.

[Freddie]

Sure, I'll PM you.
Great, thanks! :)

[TheFallenOne]

That was the first thing I tried but it doesn't work for at least three reasons..

1. The user may want to enter Shift instead of LShift or RShift, and there is no Shift key. Same for the other modifiers.

2. The user may want to enter mouse buttons, but at least one button can't work that way because at least one button has to be "meta" to the entry field for navigation in the dialog box.

3. The user may want to enter keys that don't exist physically on the keyboard. (There are many dozens of such keys.) This is very useful when making hotkeys that get triggered by other programs or hardware devices.

What I've thought of doing is making two dialog boxes, a simple one that works the way you say and the current one. The simple one would come up by default, and it could contain a button that brings up the second one.

But even if I end up doing that, this first dialog box needs to be tested and improved and debugged.


I definitely think you should do this, setup two dialog boxes (manual selection and key press detection). It would definitely make things a lot easier to work with. :)

Great work so far, let us know if there's anything above and beyond testing you could use help with!

[Freddie]

I definitely think you should do this, setup two dialog boxes (manual selection and key press detection). It would definitely make things a lot easier to work with. :)
How do you know it would be easier? Have you tried this one?

You can type keys directly into this one. It does see your key presses.

Has anyone here tried this one?

Edit: I'm getting the impression that almost nobody here has tried this dialog box. Are people assuming that because the fields have triangles on them (they are comb box controls), you can't type into them? You can type into them.

[Freddie]

In case my impression is correct, that most people here aren't trying the dialog box, let me describe how it works.

If the hotkey consists of typeable characters, you simply type the hotkey one keystroke at a time and it gets entered. Each time you press a key, the cursor advances to the next field automatically.

But if you need to enter a key or mouse button that can't be typed, you can left click a field with the mouse and select the item from a drop down list.

This dialog combines direct typing with mouse selection. It can be used both ways.

[Flekkie]

Wow I really like this.

In particular, you can set up.. did you call them 'chords'? So basically pressing any combination of keys, like using any key as a modifier. I'm assuming that's where you're going with it?

I'll give it a proper test tomorrow, but wanted to say I like :)

[Freddie]

Wow I really like this.
Thanks. :)


In particular, you can set up.. did you call them 'chords'? So basically pressing any combination of keys, like using any key as a modifier. I'm assuming that's where you're going with it?
That's right. You can do this with HotkeyNet now, but HotkeyNet requires that the user declare in a script that the key is used as a modifier and from that point on, the key can't perform its normal function.

Mojo won't require this, so a key can (if the user wants) be used in chords while retaining its normal use, or maybe it will be possible to selectively disable it from its normal use (for example, it might work one way if a certain window is in the foreground but another way at different times).


I'll give it a proper test tomorrow, but wanted to say I like :)
Thanks. :)

[TheFallenOne]

How do you know it would be easier? Have you tried this one?

You can type keys directly into this one. It does see your key presses.

Has anyone here tried this one?

Edit: I'm getting the impression that almost nobody here has tried this dialog box. Are people assuming that because the fields have triangles on them (they are comb box controls), you can't type into them? You can type into them.


Of course I tried it. :)

However, it was not noted anywhere in the dialog that you could press keys to select input. Generally I assume that comboboxes are intended to be mouse-selected (at most they take alphanumeric input to select an item via first letter), and either way, I read this thread first. The post I quoted was implying that there was currently no way to input keys via keystroke, so I didn't attempt it.

[Freddie]

Of course I tried it. :)

However, it was not noted anywhere in the dialog that you could press keys to select input. Generally I assume that comboboxes are intended to be mouse-selected (at most they take alphanumeric input to select an item via first letter), and either way, I read this thread first. The post I quoted was implying that there was currently no way to input keys via keystroke, so I didn't attempt it.
Well, you asked what else you could do. You could go back and really try it and if you can think of a way to make THIS dialog better, please let me know.

[TheFallenOne]

Well, you asked what else you could do. You could go back and really try it.

I did? I'm not sure what you're asking me to do. I did try it. Multiple times. :p I tested it again with keystroke input after I read your post. I found no problems with the dialog. The only real thing I could mention was the lack of something mentioning that you can press a key to select input, which I already said...

The only other thing I could even think of to mention, which felt too "nitpicky" to bring up, is that you could organize the keys in the comboboxes by groupings instead of alphabetically (I.E. put the modifiers together in one portion, alpha keys in another, numeric keys in another, etc.), which may make selecting them easier.


EDIT: To clarify what I meant on my last point, the combo boxes are currently organized like so (just a snippet of the entire thing):

A
Accept
Alt
Apps
Attn
B
Backspace
...etc


Where I think it would be cleaner if it was:

0
1
2
...
8
9
A
B
C
...
X
Y
Z
Alt
LAlt
RAlt
Ctrl
LCtrl
RCtrl
...etc.


Also, the Clear button isn't clearing the checkboxes for the locks (AKA "Capslock is On", "Numlock is Off", etc).

[Freddie]

I did?
No, sorry, I misquoted you. You said, "Great work so far, let us know if there's anything above and beyond testing you could use help with! "

But what I need help with the most is design suggestions from the user's point of view.


The only real thing I could mention was the lack of something mentioning that you can press a key to select input, which I already said...
I got the impression that you were misled before you looked at the dialog by the earlier part of the thread. Am I wrong? I'm wondering if you would have misjudged the dialog if you came to it without preconceptions?

The combo boxes are the type that have edit controls at the top and so far as I know, they have a distinctive appearance that always means "you can type into me." I think the ones that you can't type into have a sort of 3D shiny appearance.


The only other thing I could even think of to mention, which felt too "nitpicky" to bring up, is that you could organize the keys in the comboboxes by groupings instead of alphabetically (I.E. put the modifiers together in one portion, alpha keys in another, numeric keys in another, etc.), which may make selecting them easier.
Nothing is too nitpicky. :) That might be a good idea. I'll keep it in mind and see how people feel it after this dialog box is in real use. That may be a while.



Also, the Clear button isn't clearing the checkboxes for the locks (AKA "Capslock is On", "Numlock is Off", etc).
Great, thanks, I'll fix that now.

[Pocalypse]

From testing:


If I press lctrl + lalt + lshift together simultaneously (or as near to it as I can), mojo only sees one of them as being pressed. If I press them more slowly, it sees all of them.
Not sure if this is something you can, or want to, fix.
When I press the same key twice, mojo let's me know (You entered X twice. That will have to be changed.) I would suggest at this point you remove the last duplicate key, so the user can hit the new one straight away, rather than now having to use the drop downs, or clear and start over (just realized you can click into the last input box and continue typing, but I still think clearing the last key would be better).


Will continue testing.

Edit: The 'Released' option for hotkeys is grayed out. I assume this isn't ready yet?

I completely admire you for doing this Freddie. Hotkeynet is amazing, I can barely imagine what this program will be capable of.

[Fizzler]

This looks very interesting.

When I hold down Left Mouse and another key say H. The input box shows the H highlighted in blue. I get the same when I do a Right Mouse and hold a key down. Is this on purpose? Is that how a Left Mouse key would look in the input box?

I read the help page, I am trying to understand exactly how this works and what uses it would have. If I create an input of <capslock> Rshift M if I hit that input what would happen? would a keymap or bind in the game be triggered? or would this be something specific to Mojo?

[Pocalypse]

Issue: Pressing shift and a numpad number results in 3 buttons: Shift, NumpadEnd (number converted by shift), and shift again (which now gives an error). I know with windows generally you can't use shift with numpad, I don't know how you want to handle that.

Slightly unrelated to hotkeys.

Freddie, after the program is installed, going into 'Show License Dialog' still gives Accept and Decline buttons. Surely you can't decline after you've already installed the program (although I suspect declining doesn't even do anything yet at startup either :))

[Pocalypse]

Suggestion regarding the 'Your last action' window and mouse motion.

As it is now, moving the mouse overwrites whatever the last action was. Also, if you want to determine a point on the screen, and then write it down, you need to make sure you mouse doesn't move from the point, otherwise you lose the location.

So my suggestion is this:
Between the 'Your last action' and 'Connections' windows, have a smaller window for Mouse motion. This will always have the current scrn and win mouse positions. Then also show these positions in the 'Your last action' screen, if the last action was a mouse button press (similar to Hotkeynet), and don't overwrite them until another key is pressed.

Sorry for chain posting, but I'm always reluctant to edit posts after some time has gone by, since someone replying might miss the edit.

[Freddie]

From testing:


If I press lctrl + lalt + lshift together simultaneously (or as near to it as I can), mojo only sees one of them as being pressed. If I press them more slowly, it sees all of them.
Not sure if this is something you can, or want to, fix.
I think I can do that but it will take a bit of work so didn't try yet. (All key events and mouse events are getting intercepted by Mojo's keyboard hook, they aren't getting handled normally by the dialog box code). I'll try to do this in the next build.

When I press the same key twice, mojo let's me know (You entered X twice. That will have to be changed.) I would suggest at this point you remove the last duplicate key, so the user can hit the new one straight away, rather than now having to use the drop downs, or clear and start over (just realized you can click into the last input box and continue typing, but I still think clearing the last key would be better).
Good idea, I'll clear it in the next build and we can see how that looks.


Edit: The 'Released' option for hotkeys is grayed out. I assume this isn't ready yet?
Right. It might seem strange that I bothered since this dialog doesn't really do anything anyway. But actually the dialog is building the data structure that will get used "for real" by the keyboard hook to determine whether the keyboard state matches a defined trigger, and I didn't build "press" or "release" into that data structure yet.


I completely admire you for doing this Freddie. Hotkeynet is amazing, I can barely imagine what this program will be capable of.
Thanks, I really appreciate that. :)

Thanks very much for the suggestions here, this kind of feedback helps a lot.

[Freddie]

This looks very interesting.

When I hold down Left Mouse and another key say H. The input box shows the H highlighted in blue. I get the same when I do a Right Mouse and hold a key down. Is this on purpose? Is that how a Left Mouse key would look in the input box?
I think that's Windows's default behavior. I haven't tried to alter it yet. You can select LButton from a list by clicking it with the mouse. You will see "LButton" in the field.


I read the help page, I am trying to understand exactly how this works and what uses it would have. If I create an input of <capslock> Rshift M if I hit that input what would happen? would a keymap or bind in the game be triggered? or would this be something specific to Mojo?
Both. Anything.

Mojo is not only a broadcasting program (like other multiboxing programs) and a KM program (like Input Director or Kavoom) but also a hotkey program. That means you can define hotkeys and tell Mojo to do anything you want when you press the hotkey. There will be a programming language that you can use to describe what you want Mojo to do when you press a hotkey.

I'll probably also use this dialog box (or a similar one) to automate (as much as possible) the process of creating FTL keys etc. for WoW.

I think people will tell me what they want to use this for as the test goes on. :It will find a lot of uses.

[Freddie]

Issue: Pressing shift and a numpad number results in 3 buttons: Shift, NumpadEnd (number converted by shift), and shift again (which now gives an error). I know with windows generally you can't use shift with numpad, I don't know how you want to handle that.
Wow, you're really testing. :) Thanks. If I can think of an easy way to stop that I will.


Freddie, after the program is installed, going into 'Show License Dialog' still gives Accept and Decline buttons. Surely you can't decline after you've already installed the program (although I suspect declining doesn't even do anything yet at startup either :))
It's like that because it's on the Debug menu. Anything on the Debug menu is only there for testing. It's not a real part of the program. Since this is a GPL program I'm not sure whether that license means anything at ll. I'm hoping a lawyer will come along and tell me during this test. :)

[Freddie]

Suggestion regarding the 'Your last action' window and mouse motion.

As it is now, moving the mouse overwrites whatever the last action was. Also, if you want to determine a point on the screen, and then write it down, you need to make sure you mouse doesn't move from the point, otherwise you lose the location.

So my suggestion is this:
Between the 'Your last action' and 'Connections' windows, have a smaller window for Mouse motion. This will always have the current scrn and win mouse positions. Then also show these positions in the 'Your last action' screen, if the last action was a mouse button press (similar to Hotkeynet), and don't overwrite them until another key is pressed.
A number of people have asked for this. If that keeps up I'll do it. The reason I did it this way is because mouse movement is an input to Mojo, so if the last thing a person did was move the mouse, then the last action was mouse movement. But if people want it changed I'll do it.


Sorry for chain posting, but I'm always reluctant to edit posts after some time has gone by, since someone replying might miss the edit.
No problem, I think it's a good idea.

Makes it easier for me too because somtimes I overlook things in long posts. This way I'm more likely to see everything you say.

[Boogieman]

Looking good Freddie

I have a suggestion

The dialog box is awesome for defining hotkeys though i don't mind the scripting actually I kind of enjoy it
It gives me a sense of accomplishment when i script a long action or multiple actions for a hotkey like my log in script i like to figure out how to make it work like I want it to

Anyway to the point I suggest that when the dialog box is opened that a secondary text window opens that is a listing of the current hotkey definitions

You could make this very user friendly easy for a non coder to read
something like a a set of columns one for the hotkey trigger and one for the output

something like


Hotkey = output




__________________________________________________ _______________________________
Hotkey | Output |
_______________________|__________________________ _______________________________|
Shift alt apps | Launch 5 wows and rename the windows |
| Resize and reposition the windows |
_______________________|__________________________ _______________________________|
Rctrl 1 | key 1 sent to all wow windows |
_______________________|__________________________ _______________________________|
Lctrl 1 | key 1 sent to active wow window only |
_______________________|__________________________ _______________________________|
Ralt 1 | key 1 sent to non active wow windows |
_______________________|__________________________ _______________________________|
Lalt 1 | key 1 sent to specified wow windows wow1 wow2 wow4 |
_______________________|__________________________ _______________________________|
Or something similar

I think I need a visual of the existing keys while i use the dialog box to edit the "script"

[Freddie]

New build

A new build (12) is up. Based on what people said here, I made three changes.

1. It's now possible to press a bunch of keys simultaneously and they all get entered. They don't have to be entered one at a time.

2. There are now instructions, a line of text above the entry field that says, "Press keys or select from list with mouse."

3. If you enter a duplicate key, the field now becomes blank and that field retains the focus after the message box is closed.

Thanks very much for the suggestions.

I'm very curious to know whether people think change 1 eliminates the need for a second easy-mode dialog box.

[Freddie]

Looking good Freddie
Thank you sir.


The dialog box is awesome for defining hotkeys though i don't mind the scripting actually I kind of enjoy it
I noticed that, you've turned it into an art form. :)


It gives me a sense of accomplishment when i script a long action or multiple actions for a hotkey like my log in script i like to figure out how to make it work like I want it to
Be careful, you'll end up being a programmer. That's what happened to me. :)


Anyway to the point I suggest that when the dialog box is opened that a secondary text window opens that is a listing of the current hotkey definitions
My response is a little complicated because on the one hand, there won't be a single list of hotkeys to display. A person might have a list of hotkeys that are active when he's playing EQ2; but he's also got a second list that's active when he's playing WoW; except there's a third list that partly overrides the second list when his toon Henry is in the foreground window ... etc.

In addition, inside a single list, some hotkeys may be active when a particular window is in the foreground but inactive under other circumstances. In other words, both whole lists and hotkeys within lists will have variants.

Another way of saying this is that your illustration shows two things, (1) triggers and (2) actions. But in addition, there will be (3) various kinds of conditions under which definitions get applied.

Another complication is that the window for displaying hotkeys should probably be the same window that's used for entering hotkeys.

I don't know yet what all the possibilities and complications will be, but I know that for many people, it will be a lot more complicated than just one list.

But I can tell you this. The user will always be able to open a window of defined hotkeys (assuming they were defined through the program's GUI) and examine them.

When the time comes to design that window, we'll have threads here about it. You and I and other people will talk about it and together, over time, we'll design a terrific window.

I don't want to talk about the hotkey list window in this thread, but when the time comes, we'll talk. :)

[Moorea]

I saw only the new build and the dialog is very clear to me - and you can just start typing and it fills up

Only problem is I don't know what a "hotkey trigger" really is :-) [well I guess from hkn experience I guess it's a command trigger but I would vote for a clearer term (why not command trigger? or action trigger?), or an explanation inlined or as mouse over]

[Freddie]

Only problem is I don't know what a "hotkey trigger" really is :-) [well I guess from hkn experience I guess it's a command trigger but I would vote for a clearer term (why not command trigger? or action trigger?),
I wrote "hotkey trigger" from habit, from HotkeyNet. In HotkeyNet commands and hotkeys are different things, and triggers only applied to hotkeys, not commands. Hence the name.

I think you're right that the name can be changed for Mojo. As Mojo evolves we'll see what these triggers are used for. Maybe they should just be called triggers.


or an explanation inlined or as mouse over]

You came to this dialog box with no context except "Go to the Debug menu and press Test." But in real life, users will only see this dialog box if they want to create a trigger for some particular reason and they press a button for that purpose. They will know what their trigger is for because otherwise they wouldn't have opened the dialog box.

There is a link at the bottom of the dialog box. It leads to a full page of text about triggers.

[Flekkie]

I'm worried that some of my observations are a bit nit-picky, because I want to re-iterate that the overall impression for me was very good! In terms of its basic function I have not been able to break it yet, so it seems functionally sound.
I don't necessarily want to distract you from the core programming (unless you want me to).

I also thought the triggers help page was very clear and well written.

Anyways, onto the niggly things I thought of..


'Typing in' the mouse-clicks
It's a bit of a pain going through the list to find 'LButton'. I wonder if the mouse buttons could be grouped at the top of the list (since they cannot be 'typed' into the drop-box)? (Also liked the suggestion to group other keys instead of listing alphabetically.)

Alternatively, is it worth considering a 'Click area' to click on in order to input mouse clicks? Would that avoid the needing-a-meta-button-to-navigate-the-window problem?
I couldn't see such it in the list of controls here http://msdn.microsoft.com/en-us/library/aa511482.aspx but I know that such a thing exists. If you look in Control Panel -> (Hardware and Sound) -> Mouse -> Buttons Tab -> Double Click Speed Section then you can see such an area to test the mouse double-click speed.


Clearing
The clear all button is very nice. I wonder if it would be easy/appropriate to be able to clear a single drop-box and leave the rest? Probably the easiest way would be to have the very first drop-down option be a blank/clear option?


Setting up ranges of hotkeys
One of the nice things about scripts (in HKN) is that you can set up a range of hotkeys very easily.

I can still see a need for this even with a broadcasting option also available. For example, setting up FTL systems where input is a defined hotkey, and output is decided per %Trigger% and per window. (Windows = Wows according to Mojo's screens I think?)

I was curious if you wanted to give users the ability to set up ranges by using the GUI, or keep it to scripts? However, I won't try thinking up how to do that unless you need the input.


Max # of keys registered at once
[Edit: Sorry, scratch this section, you already covered it on the triggers help page! ]

My keyboard will not register more than 4 keys being pressed at once. If I hold down 4 keys and press a fifth key on the same keyboard, it does not transmit it. (I am pretty sure this issue is keyboard/input-device specific, but going by memory.)

However, the screen still lets me set up chords of more than 4 keyboard keys.

It's probably a non-issue, because why on earth would someone set up a longer chord? I really don't know if there are keyboards/input-devices out there which restrict below 4.
I can't really think of a solution either. Not without bumping into the LShift/RShift/Shift issue or the entering keys that don't exist on the input device issue. Best to ignore maybe?


The NumLock issue
This might be the wrong thread to bring this up. In a nut-shell, in order to set up a standard keyboards numberpad for hotkeys to work 'the same way' regardless of numlock state, I have to set it up twice (eg I would have to set up NumpadUp and Numpad8 both as separate hotkeys but which do the same thing).

Again, this might be easiest/best just left as it is. I was just wondering, in case there were any ideas kicking around to make this type of thing easier.

[Flekkie]

On another topic, good news: I was not able to reproduce the broadcasting issue I reported before (after updating). After updating to build 11 and build 12, Mojo was broadcasting correctly without having to restart.

[Owltoid]

Sorry if this has been covered.

I noticed the box that says "Execute the hotkey only when"

This leads me to believe that the six choices are the only options for a toggle. Some of us use many keys to toggle different states. For example, some use toggles to tell one of our slaves to start casting other spells while the other slaves continue doing what they were (moonkin eclipse proc). I hope that like HKN there will be more than just these predefined toggle switches.

[Flekkie]

I think Freddie has included these 6 states because they are hard-wired into any keyboard, or kept track of by the OS (he will no doubt correct me ;) ).

A toggle I think (hope I get this right) is purely a hotkey action, not a state. So you can define the hotkey (with the GUI as is, or within the script I presume) and then define the toggling behaviour that happens when you press that hotkey later.

I might be completely wrong, it's just how I pictured it to myself.

[Freddie]

I'm worried that some of my observations are a bit nit-picky...
Please don't ever feel that way! Be very nitpicky! Let's make this software as wonderful as we can. :)

I really want to stress this. No detail is too small. I'd like Mojo to one of those programs where people smile when they use it because it just feels great, it's so easy and natural to use, and that depends on tiny details.


'Typing in' the mouse-clicks

I'm planning to let people type in mouse clicks. I just haven't implemented it yet.


(Also liked the suggestion to group other keys instead of listing alphabetically.)
Did you notice that alphabetical order helps you find things? For example you can type L, then open the list, and you'll be at the Ls.


Alternatively, is it worth considering a 'Click area' to click on in order to input mouse clicks? Would that avoid the needing-a-meta-button-to-navigate-the-window problem?
How about we wait and see how the dialog box feels after typed mouse buttons are added. I'll keep this in mind till then. We may feel that this idea is not necessary for most buttons but it might still be useful for LButton since LButton is a special case (it's used for navigating the dialog box).


I couldn't see such it in the list of controls here http://msdn.microsoft.com/en-us/library/aa511482.aspx but I know that such a thing exists. If you look in Control Panel -> (Hardware and Sound) -> Mouse -> Buttons Tab -> Double Click Speed Section then you can see such an area to test the mouse double-click speed.
Wow you are really doing some work here! Thank you!

The control in that dialog box is probably just a static picture control. Almost any kind of control tells its window that somebody clicked on it, and that's all that control is doing. It could also be an owner drawn button. It could really be any control that draws a picture, and lots of controls can do that. (In fact it could just be a picture drawn on the background of the dialog box itself.)

There's a difference between that dialog box and our dialog box. This idea might work okay for Mojo anyway but I'm just pointing it out. That one doesn't have the concept of a cursor. Ours does. With that one, the clicks always affect the thing you're clicking on. With ours, the clicks will affect different fields depending on where the cursor was before you clicked the new control you're talking about. This might work anyway but I'm just pointing it out. :)


Clearing

I'll add that and we can see if we like it.


One of the nice things about scripts (in HKN) is that you can set up a range of hotkeys very easily.

I can still see a need for this even with a broadcasting option also available. For example, setting up FTL systems where input is a defined hotkey, and output is decided per %Trigger% and per window. (Windows = Wows according to Mojo's screens I think?)

I was curious if you wanted to give users the ability to set up ranges by using the GUI, or keep it to scripts? However, I won't try thinking up how to do that unless you need the input.
I think FTL should definitely go in the GUI (in addition to scripts).

Ranges probably should also go into the GUI (in addition to scripts) but I find that it's easier to design things if there's a context for their use and we dont' have that yet in Mojo for ranges. I designed this "set trigger" dialog box to go along with the new option at the bottom of Mouseover Settings. We can imagine clicking the button on Mouseover Settings and popping up the Set Triggers dialog.

As soon as we have a place in the program where the user will want to enter a range, I think it will be easier to think about a design for entering ranges.


This might be the wrong thread to bring this up. In a nut-shell, in order to set up a standard keyboards numberpad for hotkeys to work 'the same way' regardless of numlock state, I have to set it up twice (eg I would have to set up NumpadUp and Numpad8 both as separate hotkeys but which do the same thing).

Again, this might be easiest/best just left as it is. I was just wondering, in case there were any ideas kicking around to make this type of thing easier.
I agree that it's weird but it's done this way because this is the way that keyboards and the operating system work. It's an irregularity caused by history (the way IBM designed its earliest keyboards).

In general I think the least confusing thing for the greatest number of people is to do things the standard way defined by the operating system and/or history. That's what you see here with the number pad.

Over the years I've thought many times about adding something to my programs to compensate for this irregularity. The best "solution" I've come up with is the following. (I use quotation marks because I think the cure is worse than the problem.)

Mojo would have 11 additional "keys" that don't exist in Microsoft's specification. These 11 keys would represent the number pad keys without regard to their shift state.

For example, with the program as it is now, you can define these two hotkeys which both get triggered by the same piece of plastic:

NumpadInsert
Numpad0

With the 11 new keys, you could use one of them to write this instead:

NumpadInsertWithoutRegardToShiftState

I see two problems with this idea. First, the new "key" conflicts with the old ones. (It's a little bit like the problem with Shift and LShift conflicting each other which is handled by the error message shown in a picture earlier in this thread). A lot of people have trouble understanding these conflicts, and it's extra work for me (possibly in many places in the program) to worry about the need for warning messages to advise people that they can't do something.

Another problem is the names of the new keys. It's hard to think of names that will be self-explanatory without being very long.

[Freddie]

On another topic, good news: I was not able to reproduce the broadcasting issue I reported before (after updating). After updating to build 11 and build 12, Mojo was broadcasting correctly without having to restart.
The code that maintains connections is incomplete, and if you close one copy of Mojo while they are connected and then restart it, it's possible for the connection not to get recreated properly. It will work in one direction but not the other. (This can make the cursor get trapped on the remote PC during mouseover, so I really ought to finish it!) You may have seen this problem. The current buld is still like this.

[Freddie]

I noticed the box that says "Execute the hotkey only when"

This leads me to believe that the six choices are the only options for a toggle. Some of us use many keys to toggle different states. For example, some use toggles to tell one of our slaves to start casting other spells while the other slaves continue doing what they were (moonkin eclipse proc). I hope that like HKN there will be more than just these predefined toggle switches.
Actually this is like HotkeyNet. HotkeyNet has six keywords for the three built-in states that corresopnd to LEDs on a keyboard:



NumLockOn
NumLockOff
CapsLockOn
CapsLockOff
ShiftLockOn
ShiftLockOff
These new checkboxes in Mojo are the same as those keywords.

Mojo will be more powerful, not less powerful, than HotkeyNet. You'll be able to do everything you want.

[Freddie]

I think Freddie has included these 6 states because they are hard-wired into any keyboard, or kept track of by the OS (he will no doubt correct me ;) ).
You're exactly right.

The two people who brought up this issue are both HotkeyNet users, so let me add something from their perspective.

The dialog box that we're talking about here corresponds to the <Hotkey> statement in HotkeyNet.

The only things you can put in a <Hotkey> statements are (1) lock states (2) modifiers and (3) keys.

This dialog box is exactly like Hotkeynet's <Hotkey> statement. The six check boxes are the lock states.

HotkeyNet has a lot of other stuff besides the <Hotkey> statement, and Mojo will have a lot of other stuff besides this dialog box.

[rocnroll]

Something I have noticed is that ever so often Mojo will start flashing in the Taskbar. I seem to remember that HKN2 did the same thing. What is Mojo doing? It's mildly annoying, but certainly not a show stopper.

Oh, the overall progress is really good Freddie, I just need to do some more thorough testing. :)

[Freddie]

Something I have noticed is that ever so often Mojo will start flashing in the Taskbar. I seem to remember that HKN2 did the same thing. What is Mojo doing? It's mildly annoying, but certainly not a show stopper.
When does that happen? What are you doing when that happens?

(In general that flashing means that the program is trying to come to the foreground but the operating system won't let it.)


Oh, the overall progress is really good Freddie, I just need to do some more thorough testing. :)
Thanks. :)

[Freddie]

New build 13

I made some changes that people suggested including a new name for the dialog box.

I also changed the text a little bit to try to avoid giving people the impression that the lock checkboxes are the only things that will be in the program for toggling conditional states.

The main change is mouse buttons. You can enter them all directly now. Two questions:

1. LButton has to work normally in order to navigate around the dialog, so I decided to require a double click in order to enter it. Is this a good solution?

2. You can enter WheelForward and WheelBackward by turning the mouse wheel. Should this be disabled? I think it's confusing.

[Pocalypse]

1. LButton has to work normally in order to navigate around the dialog, so I decided to require a double click in order to enter it. Is this a good solution?

2. You can enter WheelForward and WheelBackward by turning the mouse wheel. Should this be disabled? I think it's confusing.

1. I like how LButton works.

2. On my Logitech MX mouse, this is incredibly frustrating. The scroll wheel is very sensitive, in that as soon as I try to use it once to input ScrollWheelUp, it sees multiple presses and gives me an error. Often it activates even if I don't want to enter a ScrollWheel button.

Also, am I correct in thinking that with this hotkey system, we can set up actions for left click while right click is pressed, or right click while left click is pressed? That could be really useful (I'm thinking of other things than WoW here, it probably won't be good to set those up for WoW because of the camera tilt with mouse buttons).

[Freddie]

1. I like how LButton works.

2. On my Logitech MX mouse, this is incredibly frustrating. The scroll wheel is very sensitive, in that as soon as I try to use it once to input ScrollWheelUp, it sees multiple presses and gives me an error. Often it activates even if I don't want to enter a ScrollWheel button.
Thanks for the feedback. The wheel is annoying for me too on a cheapo mouse. I'll probably change it after we hear from a few more people.


Also, am I correct in thinking that with this hotkey system, we can set up actions for left click while right click is pressed, or right click while left click is pressed?
Do you mean the user would press LButton and Mojo will send a signal to a game that makes the game think you pressed RButton?

Yes, that will be possible with hotkeys and maybe also with broadcasting. (Hotkeys can do everything that broadcasting does, so I don't know yet how much work I'll put into the broadcasting screens.)

The trigger (what you do with your fingers) is input. The action (what Mojo does when it sees the trigger) is output. They are completely different things.

By default, in Broadcast mode, Mojo makes its output match the trigger. For example, if you press A, the program sends A to games. This is what dual-boxing's Wiki calls "multiplexing."

But there's no reason why they have to match. The software generates the output by computation. The output can be anything.

[Pocalypse]

What I was thinking of are called rocker gestures, though don't ask me where that term is from, because I can't remember :).
I'm thinking of holding down the right button and then pressing left button, or holding down the left button and then pressing the right button.
Hmm, I think firefox gestures are where I used these last.

The way the dialog is now, these will be possible to create. It's just a nice option to have.

[Freddie]

Oh, I see. I never heard of that, but it sounds great. Yep, this lets you do that.

Edit: The thing that prevents that in HotkeyNet is that it won't allow people to put a modifier at the end of a trigger. I'm trying to remove all the restrictions in Mojo.

[Aragent]

Freddie

I know you have talked about this back in HKN and HKN2 Development talks, And possibly already in the early stages of Mojo.
(If my memory serves correctly. These days i am not always sure it does)

Have you done any more Thought about having mojo be able to differentiate between 2 keyboards connected to the same pc,
thus allowing them to act as 2 seperate keypads ?

[Freddie]

About a year ago I wrote some test code to see what would be needed to implement this. I only found one way that it can be done, and it would increase the complexity of the program quite a bit and take a lot of work, so I don't think think this will be in Mojo any time soon.

[Flekkie]

Hi Freddie, sorry for the delay.

Personally, I'm not sure about having to double-click the LButton. But I assume it's not possible to distinguish between clicks on the drop arrow and on the body of the input box?

[Freddie]

Hi Freddie, sorry for the delay.

Personally, I'm not sure about having to double-click the LButton. But I assume it's not possible to distinguish between clicks on the drop arrow and on the body of the input box?
That's not the problem. The problem is that left clicks already have an essential meaning when they occur in the body of the input box. They mean, "move the cursor to this location."

[Flekkie]

Oh yeah, I didn't think of that.

[Freddie]

I tried giving single left clicks two different meanings. If they occurred in a field that already contained the cursor, they meant "type the LButton character." But if they occurred in a field without the cursor, they meant "move the cursor here."

The result was bewildering. Even though I knew what was happening, it seemed as if the program was broken.

I think the idea of moving the cursor by left clicking is so natural and familiar, that it's just not possible to mess with it without confusing people.

[Moorea]

wtb new build ;-) with basic feature like a DNP list and I could get my daughter started multiboxing !

[Freddie]

Soon. :)

[Moorea]

Yeah ! xmas is coming soon !