Build 11 -- Hotkey triggers

[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.