Build 11 -- Hotkey triggers

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

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