Build 16: Alt-tab bug fixed

[Freddie]

At least I think it's fixed.

For the folks who helped me figure out how to fix it, you might find this funny. I must have spent a month thinking about how to fix it. Then we discussed it at length in the last thread.

When I finally wrote the code today, it took about a minute.. Here's a screenshot of the source code. The changes are in blue. That's the entire fix.

On the other hand, I spent the entire freaking day screwing around with the balloon tooltips (the pop ups you see when you click "Hotkeys are off") trying to make them behave like the ones that the OS displays. They are better but still not exactly right

http://mojoware.org/art/build-16-source.gif

[Freddie]

Good thing I posted that screenshot because I just reread it here on the forum and realized I made a mistake. The current build is now 17. :o

This is what I should have written -- of course I may change my mind in fifteen minutes and post build 18. :)


http://mojoware.org/art/build-17-source.gif

[Fursphere]

lol

Freddie, you rock!

[Fursphere]

tooltips seem to be fixed.

[Freddie]

tooltips seem to be fixed.
They don't work right if you slide the mouse off the balloon onto another program's window or if Active Window Tracking is on. But I wasted eight hours of my life on them today and I think that's enough. :)

I put a timer on them so they disappear after 5 seconds (more or less depending on your system settings) so it doesn't matter that much.

Is Alt Tab fixed? That was the important thing.

[Fursphere]

Haven't gotten that far yet. Input Director just released a new beta build as well, so I'm installing that as well (do you two know each other or something? your release schedules are scary similar)

[Freddie]

Haven't gotten that far yet. Input Director just released a new beta build as well, so I'm installing that as well (do you two know each other or something? your release schedules are scary similar)
Heh no.

[Fursphere]

From what I can tell, the alt-tab (sticky alt) bug is fixed. I haven't been able to reproduce it in the newest build.

Nice job!

[Freddie]

From what I can tell, the alt-tab (sticky alt) bug is fixed. I haven't been able to reproduce it in the newest build.

Nice job!
Phew. :)

We have to split the credit on this one. You found the bug and if you hadn't reminded me about HotkeyNet, I honestly don't know if I would have remembered this solution.

[Fursphere]

thx. :)

I spend a good hour or two last night trying to break it (lots of alt-tabbing and other weirdness) - no issues.

So what's next? :D

[zenga]

The two of you should team up and start a business. Seen many situations where large projects would die to get a coder and dedicated tester with such an interaction :p

[Freddie]

thx. :)

I spend a good hour or two last night trying to break it (lots of alt-tabbing and other weirdness) - no issues.
Great.


So what's next? :D
Like Zenga says, let's get rich! :)

Let me try to remember recent requests.

The next thing on your list was keymaps. I think the next thing on Moorea's list was no-pass. That's sort of the same, right?

I might have to do "launch WoW" before keymaps make much sense.

Other people asked for visible cursors, status overlays, um, what else.

Edit: mouse broadcast.

Edit: Set a PC not to receive incoming (as opposed to the existing mode buttons and hotkeys which all affect outgoing).

Edit: re-enable WoW window and finish the code that tracks scheduled and running WoWs.

Edit: Triggers need to be finished. They don't yet include an option for "trigger when key is released" and "allow or disallow typematic presses to trigger this hotkey."

Edit: There are two remaining bugs on the bug list but I'm inclined to leave them for now since they will be a pain in the ass and nobody has complained about them.

Moorea, if you're reading this, you know what would help me in the FAQ? If you could figure out some way to include a running summary of requests with a count of how many people asked for each one. A top-ten requests list. Right near the beginning of the FAQ.

Does the word "keymap" come from Keyclone? Can someone post a screenshot of what a keymap config screen looks like so I have a better idea of what's being requested?

[zenga]

The next thing on your list was keymaps. I think the next thing on Moorea's list was no-pass. That's sort of the same, right?


How i see it is that keymaps and don't pass are essential functionalities for a boxer and it would take mojo to the next level.


Keymaps: e.g. map ctrl+A to jump on toon A and B and move forward on C while both ABC have exactly the same ingame keybinds

Do not pass: respective keypresses are not passed to all clients, only to the active window. If we could decide to which clients it should be passed and to which not, would even be more awesome. For example i have my arrow keys set as main movement keys on all clients and i have ZQSD as my secondary movement keys on my slaves (not on my main). The arrow keys are not passed to slaves. This means i can just move around with my main with the arrow keys and have my slaves on follow. If i need to move my slaves out of a puddle in a bossfight, i just use ZQSD. On the other hand if i switch to a slave i can just use the arrow keys to move around like i'm used to without my alts responding.

[UNIXman]

Liking Mojo, a lot.

In case it wasn't suggested, would like to see:


Broadcast window and mouseover at the same time.
The option on whether or not to send certain keys (like movements keys, on WoW) is really needed to completely replace HKN.

[ElectronDF]

My request from the past that started the whole lot of something was a key to HOME the mouse pointer. So when you are doing mouseover, you can push a key to cancel it and put the mouse back in the middle of the main screen. It doesn't have to be middle, just it takes like 10-15 secs to find out where my mouse was, move it to the main screen, move my head back to main screen (multiple computers) and then figure out what is going on. It would make me happier to just push "SOMEKEY" and bam, back on main screen and ready for anything. I like to mine and herb on my alts, so when I come to an item, I want, I need to use my alts mouse to get the item. But the best items are in PVP zones. So when I land and get the item, people want to attack me. So I have to be ready for attack and getting items quickly.

[Freddie]

My request from the past that started the whole lot of something was a key to HOME the mouse pointer. So when you are doing mouseover, you can push a key to cancel it and put the mouse back in the middle of the main screen. It doesn't have to be middle, just it takes like 10-15 secs to find out where my mouse was, move it to the main screen, move my head back to main screen (multiple computers) and then figure out what is going on. It would make me happier to just push "SOMEKEY" and bam, back on main screen and ready for anything. I like to mine and herb on my alts, so when I come to an item, I want, I need to use my alts mouse to get the item. But the best items are in PVP zones. So when I land and get the item, people want to attack me. So I have to be ready for attack and getting items quickly.
This was done a couple of builds ago. You need to set a trigger from the Settings Menu : Predefined Hotkeys.

That reminds me, I have to make it possible to set the trigger from the Mousever screen.

Instructions here:

http://www.mojoware.org/help/predefined_hotkeys.html

[Freddie]

Liking Mojo, a lot.

In case it wasn't suggested, would like to see:


Broadcast window and mouseover at the same time.

This is now enabled in build 18.

I also re-enabled the WoW button. You'll see some stuff that isn't finished.

[Freddie]

Keymaps: e.g. map ctrl+A to jump on toon A and B and move forward on C while both ABC have exactly the same ingame keybinds
Could you please clarify that for me? For any trigger, there are three things involved:

-- the key or key combo that's pressed by fingers physically

-- the key or key combo that Mojo sends to WoW

-- the in-game action .

Could you restate that example in terms of those three things?


Do not pass: respective keypresses are not passed to all clients, only to the active window. If we could decide to which clients it should be passed and to which not, would even be more awesome. For example i have my arrow keys set as main movement keys on all clients and i have ZQSD as my secondary movement keys on my slaves (not on my main). The arrow keys are not passed to slaves. This means i can just move around with my main with the arrow keys and have my slaves on follow. If i need to move my slaves out of a puddle in a bossfight, i just use ZQSD. On the other hand if i switch to a slave i can just use the arrow keys to move around like i'm used to without my alts responding.
That will definitely be in the program. That's why I said above that I might have to do "launch WoW" before no-pass. The program will need to launch WoW in order to provde the user with config screens that refer to individual WoWs.

[Freddie]

Be sure to include "ActiveWindow" and "!ActiveWindow" in your options - Sometimes I mouse over to a slave machine and start playing from there, and I would love it if it just mapped my keys accordingly.
Definitely, the program should provide these options.

The problem is designing an interface that makes it easy to choose. Do you have any ideas about that?


PiP, and PiP "Positional Awareness/Preference" - the second part is a little difficult to explain but let me try:
In Octopus I have 2 screens setup - 4 WoWs in a 2x2 config and 1 WoW that takes the whole screen. If I have the WoWs configured as:
A is Main Screen
B is Top Left Secondary Screen
C is Top Right Secondary Screen
D is Bottom Left Secondary Screen
E is Bottom Right Secondary Screen
[B|C][AA]
[D|E][AA]

If I press the PIP button associated with B, it will swap A with B:
[A|C][BB]
[D|E][BB]
If I then press the PIP button associated with C, it will swap B with C:
[A|B][CC]
[D|E][CC]

The problem with this, is that I want B to either be Main or Top Left, I never want it to be Top Right (which is where it is now). I can get around this by ALWAYS pressing the PiP associated with A first and then the PiP assocciated with the WoW of my choice ... but I would rather it take care of that in the background so I can hit it quickly when I need to.
Since some people may not want this (because it means moving 2 screens sometimes, which may take longer) it would need to be an option that could be set either way.

Let me know if this is clear.
Yeah, it's crystal clear. People should be able to define keys that change their PIP setup in any way they want. That includes such things as defining which WoW's window goes where, which window-by-current-location goes where, conditions such as which WoW is currently in the foreground, etc. (And do this without using the script language. Of course users will be able to do anything whatsoever with the script language).

Do you have any ideas for how to design the interface where people create their PIP layouts and their PIP hotkeys?

I'd like to give people completely generalized choices, so there are a lot of permutations, but I'd also like the screen(s) to be extremely easy to use.

[Freddie]

What I try to do is push everything I know technically out of my head -- forget everything I know about the code -- and imagine using the program. Then I ask, "What would be the easiest thing to see on the screen and move with the mouse?"

The bad thing is, usually there's no answer.

The good thing is, my advancing Alzheimers makes it easy to forget what I know. I'm great at that part!

[ElectronDF]

Just guessing, since I don't do PIP. What about a layout choice, then a hotkey entry item.
(1 1 window
(2 2 windows
(3 4 windows
(they are just used for the size of the windows)
Make them graphics grab objects. You have 8 blank spaces (layouts) that you can drag the objects to.

Each blank spot (layout) would be a window that is like the mouseover option. It would let you layout the windows like you would like. Sorta like a drag and drop layout system. Also you can select the tiny windows and name them if you want so you could always put your tank/healer in a specific spot (which is what I thought the person was asking for).

Then below each blank space, you can select a hotkey button, that you type in your hotkey to select that look. So if you selected 1 in the first blank space and put in SHIFT-A, it would make the layout you selected happen.

[Fursphere]

Wow... I've got some new features to test! :D

[Fursphere]

Great.


Like Zenga says, let's get rich! :)



Deal!



Let me try to remember recent requests.

The next thing on your list was keymaps. I think the next thing on Moorea's list was no-pass. That's sort of the same, right?

I might have to do "launch WoW" before keymaps make much sense.


Actually yes, the "Launch WoW' feature would be really really cool. :)

Do not pass lista and keymaps are similar - but still different.

Do not pass has been described as a "white" and "black" list as well. THe most often used feature of this is for movement keys. WASD. So on the "boardcasting" mojo (current focus or main) - all keys would be broadcast (white list keys) EXCEPT "WASD" (blacklist). Its basically a list of keys you would tells mojo to "not boardcast".

The benefit here is you don't have to redo keybindings within WoW. And if you make a new WoW your "focus" or "main" - your movement keys are already setup - no rebinding. A seamless transfer.

Keymaps are changing the logical mapping of keys from one mojo to the next (or wow to wow on same pc setups).

Example:

WoW1 = A is pressed
WoW2 = A is mapped to B
WoW3 = A is mapped to C
WoW4 = A is mapped to D

So when you press A on the main, B, C, or D gets pressed on "alt" WoW's depending on there individual keymappings. I personally don't like this concept - but a lot of others have come to love it with the other broadcasting soloutions.



Other people asked for visible cursors, status overlays, um, what else.

Edit: mouse broadcast.


I don't think you've even written the code for mouse broadcasting yet? I'm not sure how many people actually use this on a day ot day basis vs. a "neat toy to have" feature. Would be interesting to find out.



Edit: Set a PC not to receive incoming (as opposed to the existing mode buttons and hotkeys which all affect outgoing).

Edit: re-enable WoW window and finish the code that tracks scheduled and running WoWs.


This is going to be very handy for multi-client users (more than one WoW per PC). It looks like you're half way there with the new "WoWs" button info.



Edit: Triggers need to be finished. They don't yet include an option for "trigger when key is released" and "allow or disallow typematic presses to trigger this hotkey."


You can currently do creative binding IN GAME to do "on release" stuff. How many people actually use it? Not many I would suspect. I really don't know a practical use for binding "on press" vs "on release"



Edit: There are two remaining bugs on the bug list but I'm inclined to leave them for now since they will be a pain in the ass and nobody has complained about them.


Oh? I haven't notice them yet. What are they? :D



Moorea, if you're reading this, you know what would help me in the FAQ? If you could figure out some way to include a running summary of requests with a count of how many people asked for each one. A top-ten requests list. Right near the beginning of the FAQ.


I was considering doing this myself. Let me talk to Svper and see if I can get some mod access to clean things up a little on this forum.



Does the word "keymap" come from Keyclone? Can someone post a screenshot of what a keymap config screen looks like so I have a better idea of what's being requested?

I dont' know where the term came from. As far as a UI goes... hmm.... with the amount of keys available on a keyboard, the UI could get HUGE. I'm almost thinking some sort of spreadsheet type layout with a list of "input key" in one column, then multiple "output" columns on a per WoW basis (multi PC aware). So you can just type in what key you want output based on the input key.

Maybe even a dynamic hotkey system like you do in the other menus - that add boxes as you use them?

[Freddie]

EDIT:

I think Innerspace uses ActionTargetGroups (don't know, never used it) and Keyclone uses Keymaps. The thought I had was this:
A small screenlet (tab/popup/doesn't matter) to define "KeyTokens" or "Keymaps" or whatever you want to call them. The idea is that the client that has focus will call this "token" when a key is pressed or a mouse-region is clicked. On this screen you click an Add button and you get a name screen and an "input" box, which has a checkmark for "Keyboard-In" and "Mouse Region-In" with Key In pre-selected and "Mouse Region-In" unselected. Under "Keyboard-In" is a key-input box. Under "Mouse Region-In" is a 4xBox for X,Y,Height,Width along with a "click-trigger" (left mouse, ctr-left mouse, etc). Finally, there is a button at the bottom that says "view mappings" - this pulls any "client" that currently has this "Token" mapped. This is just a convenience click-through.

http://s333.photobucket.com/albums/m397/Ghallo/?action=view&current=KeyMapExample01.jpg

Thanks for the screenshot and for pointing out the edit in a later post. I would have missed it otherwise.

I'm confused here about a basic point. There are three "things" involved in key injection.

1. The key combination (button, whatever) that the user presses with his fingers.

2. The key combo that Mojo sends to WoW. This appears in WoW on the right side of its key bind screen.

3. The action that number 2 is bound to in WoW. This appears in WoW on the left side of its key bind screen.

Are you suggesting that 2 should be hidden from the user and that Mojo should set keybinds in WoW without the user worrying about it (in other words, Mojo should change the in-game key bind screen)?

[Freddie]

I don't think you answered my question. I apologize if I'm missing it.

Let me try again.

You say, Q - Move Left.

That's a binding in WoW.

What our program is actually going to do is send Q to WoW.

But your window doesn't say "Send Q." Your window says "Move Left."

Q is bound to Move Left in Wow, not in our program.

How does our program know that Q is bound to Move Left in WoW?

(The number of instances, the fact that the choice of Q instead of some other output is conditional, etc. etc, is not the issue. The issue is how our program knows or sets any WoW binding whatosever. I'm using Q-MoveLeft as an example of a binding.)

[Fursphere]

I think the problem here is Ghallo is trying to get you to copy how other programs handle keymaps.

Lets start from scratch instead, and just make it completely logical by key name. (forget what WoW calls keys - who gives a crap about what wow is doing - lets do it at the OS level).

[Freddie]

Your'e saying "only tell the user Q."

I understand this suggestion. Maybe that's the way to go.

But I don't understand Ghallo's suggestion and I would like to understand it.

[Freddie]

Ghallo, somebody just suggested to me in an email that you're probably basing your idea on Innerspace and (if I understood the email) Innerspace bypasses WoW's keybinding screen.

I've never seen Innerspace, but if that's correct, then Innerspace is hiding what I called step 2, the part of the data flow where the the multiboxing program communicates with WoW.

That was what I asked you originally -- whether you wanted this part of the data flow to be hidden.

Probably most people here know what "hide" means but just in case, let me explain.

"Hide" is a software concept that means "don't show this to the user."

The opposite is "expose." It means "we show this to the user."

Part of designing an interface is deciding what gets hidden and what gets exposed.

If you think step (2) of the data flow should be hidden, that's fine, I'm just trying to understand.

By the way, if Mojo bypasses WoW's keybinding screen then the question arises, "How is that implemented?"

[Freddie]

Independant of WoW, the application simply maps between 1 key and another. The screens I sent you were a kludge example of how that might look (very rough, just to get the basics across).
But your screens don't show a key getting mapped to a key.

They show a key getting mapped to an in-game WoW command.

[Freddie]

Example:

WoW1 = A is pressed
WoW2 = A is mapped to B
WoW3 = A is mapped to C
WoW4 = A is mapped to D

So when you press A on the main, B, C, or D gets pressed on "alt" WoW's depending on there individual keymappings. I personally don't like this concept - but a lot of others have come to love it with the other broadcasting soloutions.
I think the program should do that. I think also that this sort of setting should nest. I.e., a single setting of this type for all WoWs. Then individual settings for individual WoWs that might override only a few keys. (I think all config info in the program should work that way.)


I don't think you've even written the code for mouse broadcasting yet? I'm not sure how many people actually use this on a day ot day basis vs. a "neat toy to have" feature. Would be interesting to find out.
I haven't written it yet but I've written this kind of code before in HotkeyNet.


This is going to be very handy for multi-client users (more than one WoW per PC). It looks like you're half way there with the new "WoWs" button info.
Unfortunately I just decided to rewrite the code that underlies that button. The xml file for config info, the data structures that represent WoWs and all other config'd objects -- out it goes. I've been having a lot of trouble getting it designed in a way that will make the rest of the program easy to write (it has to support the nesting stuff above and some other operations).

(Continued in another post)

[Freddie]

?
What in-game WoW command?

Quoting from your drawing:

AllAttack
Heal1
Heal2
Heal3
Heal4
FrostNova

[Freddie]

You can currently do creative binding IN GAME to do "on release" stuff. How many people actually use it? Not many I would suspect. I really don't know a practical use for binding "on press" vs "on release"
It's necessary for some very simple things in the script language. For example, making a hotkey that causes movement in a game. I won't work on the script language for a while, but the trigger code I wrote last week is the same code that will be used for the script language.


Oh? I haven't notice them yet. What are they? :D
Actually there are three known bugs now. Somebody told me one last night in a game.

1. When you close a Mojo, a connected Mojo may not close both its socket connections. Then when you reopen the closed one, the connection may not get fully reestablished.

2. If you close a Mojo whlie moused over, one or both cursors may get disabled or trapped.

3. Last night somebody reported that remote mouseover cursor gets trapped in a window belonging to Dark Age of Camelot.


I was considering doing this myself. Let me talk to Svper and see if I can get some mod access to clean things up a little on this forum.
Omg you're going to mod again! :)


I dont' know where the term came from. As far as a UI goes... hmm.... with the amount of keys available on a keyboard, the UI could get HUGE. I'm almost thinking some sort of spreadsheet type layout with a list of "input key" in one column, then multiple "output" columns on a per WoW basis (multi PC aware). So you can just type in what key you want output based on the input key.
That's kinda what I was thinking too. Except with the nesting idea maybe the entries should be color coded to show whether they are inherited (defined in a parent setting) or overriden in the current setting. And maybe there should be tabs to look back at parents from which the current settings are inherited.

And then I think -- this is too complicated for Mojo.

I never counted but the OS probably defines something like 150 or 200 key codes.. In addition some hardware devices (by mistake) use non-existent key codes so in a way there are 512 because the codes are defined by nine bits.


Maybe even a dynamic hotkey system like you do in the other menus - that add boxes as you use them?
We can draw the boundary between "broadcast" and "hotkeys" anywhere we like.

Broadcast is just a subset of hotkeys, and it can include as much hotkey stuff as we want.

I'm thinking that the input to broadcast (the trigger) should always be a single key press or release. Whether the output can be a combination... I dunno, that's something to decide.

Certainly, the program will be able to do that, but I dunno which part of the program should do that ... which screen the user does it on, whether it's called broadcast or something else.

[Freddie]

Ah!

Those are user input "names" - there is no correlation to wow. AllAttack would simply be a friendly name the user gave something so they knew what it was. "FrostNova" isn't bound to "Frost Nova"...
There is nothing in WoW called AllAttack or Heal1...

Does that help?

Edit:

I just realized:

Your first screen defines the key(s) that the user presses with his fingers.

Your second screen defines the key codes that Mojo sends to WoW.

Is that right?

[Fursphere]

I personally fell that you should do this in two seperate stages.

1) Do not pass list. This is _very_ handy and should be built.

2) Keymaps - these IMO should only be used for things you CAN NOT DO ANY OTHER WAY. (which seems kinda like cheating to me? meh - vehicles mostly). if you can move buttons around IN GAME - you should do it there. Vehicle buttons cannot be moved, so thats where keymaps shine.

Keymaps are also used _AS_ do not pass lists in Innerspace, simple because they can be toggled on and off with a hotkey, where do not pass lists in innerspace cannot be toggled in that fashion.

[Freddie]

Like I said, Many-to-many is always a difficult subject to wrap the brain around, let alone get an app to do it in a way users can understand.
When you open a folder and see a bunch of files, that's a one-to-many relationship. . One-to-many doesn't mean anything more complicated than that.

I have three daughters. They each have one father. That's a one-to-many-relationship.

The hard thing about designing a simple screen that lets the user map physical key presses to Mojo's output is that the user has to specify conditions under which different output gets generated. But specifying conditions has nothing in particular to do with one-to-many.


As Fur is saying start with Whitelist/Blacklist - that's the "master" and the bare minimum necessary to get a multiplexer working in a meaningful way. From there an "advanced" setting could be available to take the user into a config that would allow them to do the complex mappings. Marking it as "advanced" would have the advantage of detering users from that section that would really only get them into trouble.

Most of Mojo will probably be designed with progressive disclosure of increasingly complex features.

If you want to see an example that's already in Mojo, go to Connection Settings and click the first two radio buttons. Also see the "More options" button at the bottom.

(Microsoft advises software designers to say "More options" instead of "Advanced" because it's less intimidating.)


I just had an idea for a new feature request ... If I could just post a mojo.config file that will gracefully import on the user's end (so they don't have their settings lost, etc) then the community will quickly be able to assist on getting new users up to speed - even when there is a good deal of complexity .

I think that's a good idea. The data structures and algorithms that are used for Mojo's config info have been designed to make it easy to remove a branch of config info from the overall tree and graft it onto some other tree, so this should be very easy to implement. .

[Akoko]

I've officially replaced Keyclone with Mojo. I love you!!

(Still have to use HotKeyNet to launch the windows though... :))

[Moorea]

Moorea, if you're reading this, you know what would help me in the FAQ? If you could figure out some way to include a running summary of requests with a count of how many people asked for each one. A top-ten requests list. Right near the beginning of the FAQ.

I've been burried by work this week (didn't even play wow at all tonight or previous day!) but I'll see what I can do - I think though that maybe google code or curse have things for voting on features that may be more maintainable than me trying to count who requested what ?


ps: agree with fur (!) that DNP is high on priority - a way to launch wow and resize/reframe would be next (and the pause/unpause/broadcastall toggles) - I haven't tried the latest build though, so maybe all that is already in :-)

[Freddie]

I've officially replaced Keyclone with Mojo. I love you!!

(Still have to use HotKeyNet to launch the windows though... :))
, I can't believe it! It has so few features at this point. :) That's great.

It's very fun to hear this. It's a shot in the arm to crank up the compiler and work on it. Thanks.

Launch is coming soon. (It would have been today probably except I ran into a problem and have to rewrite some stuff. So it wil be a few days.)

[Freddie]

I've been burried by work this week (didn't even play wow at all tonight or previous day!) but I'll see what I can do - I think though that maybe google code or curse have things for voting on features that may be more maintainable than me trying to count who requested what ?
Whatever you think is best. My two cents would be, it's better if people can give all their feedback in one forum. If they have to go to another website, that discourages a lot of people.


ps: agree with fur (!) that DNP is high on priority - a way to launch wow and resize/reframe would be next (and the pause/unpause/broadcastall toggles) - I haven't tried the latest build though, so maybe all that is already in :-)

I'd like to do DNP next but for technical reasons there are three pre-requisites that have to be done first. Here's the schedule for the next couple of weeks:

1. Rewrite the underlying data structures for config info.

2. Finish "launch WoW" because DNP and choosing particular output key combinations for particular WoWs is the same code, and I can't write it unless the program can identify particular WoWs, and its method for doing that will be launch.

3. Make a spreadsheet kind of control that will be used for the DNP/key-assignment screen.

4. Write the DNP/key-assignment screen.

I might throw in a few little things whlie those four big things get done.

[Freddie]

(and the pause/unpause/broadcastall toggles) -
Which toggles? Different from the existing predefined hotkeys in which way?

Edit: oh sorry, never mind, you say you haven't tried the lastest build. This went in a few days ago.

[Fursphere]

Question about how "mouseover" works.

When you use Mojo to mouse over to another mojo (basically software KVM), does the new PC become the "focus" point from where things are broadcast?

PC 1 mouses to PC 2. Assuming broadcast is turned on on both mojos

Are keys now boardcast from the focal point of PC 2? or Still from PC 1?

[Moorea]

I saw later the build15 post :-)

About DNP... while a different DNP for different Wow is maybe nice; the basic DNP I need is just same DNP for every window (but the one that has the mouse, which obviously gets all the keys)

ps: not sure if that's in but a cool feature would be to automatically pause broadcasting if I mouse out of a wow window (maybe with a small time delay so it doesn't stop if I mouse travel from 1 wow to another while going over other windows) - the idea there is that if I switch to my web browser to check wow head; I wouldn't have to pause bcasting manually to type a search

[Fursphere]

This is what Freddie and I have been dicussing offline for the "keymap / DNP" interface. This is just a basic mockup, but it'll give you an idea.

http://img714.imageshack.us/img714/1669/keymapscreen.jpg

As Freddie has stated, there are a few items that need to come first.

[Freddie]

Question about how "mouseover" works.

When you use Mojo to mouse over to another mojo (basically software KVM), does the new PC become the "focus" point from where things are broadcast?

PC 1 mouses to PC 2. Assuming broadcast is turned on on both mojos

Are keys now boardcast from the focal point of PC 2? or Still from PC 1?

From PC2. At least that was my intention. I didn't test it too carefully.

How do people think it should work?

[Ghallo]

This is what Freddie and I have been dicussing offline for the "keymap / DNP" interface. This is just a basic mockup, but it'll give you an idea.

http://img714.imageshack.us/img714/1669/keymapscreen.jpg

As Freddie has stated, there are a few items that need to come first.

Does WoW Client 1/2/3/4/5 change based on Focus?

[Fursphere]

Does WoW Client 1/2/3/4/5 change based on Focus?

No - but sorta.

This is a keymap from MOJO #1's point of view (PC1 in my case).

PC2 would have a slightly differnet keymap. Same for 3,4,5.

But you bring up a good question about same-box multiboxing. Hmm....

EIDT: I'm thinking make it based on which window has "FOCUS" (windows focus, not WoW focus) at the time. But thats a question for Freddie.

[UNIXman]

From PC2. At least that was my intention. I didn't test it too carefully.

How do people think it should work?

I love it that the machine with the focus gets the keyboard. If it can be made an option, even better!

[Owltoid]

Sorry if this has been covered (I try to keep up to date on the Mojo news), but will Mojo be as efficient in mouse broadcasting as ISBoxer? I love the flexibility of HKN, and given the scripting nature I doubt ISBoxer can do all that I'm doing through HKN, but the consensus is ISBoxer is the clear winner for mouse broadcasting. I'm not sure why it works as well as it does, so all I can ask is an uneducated question of if Mojo will work as well.

[Freddie]

EIDT: I'm thinking make it based on which window has "FOCUS" (windows focus, not WoW focus) at the time. But thats a question for Freddie.
edit: on second thought let me rewrite my answer

edit: this is complicated, I'm drawing pictures. :)

[Freddie]

Sorry if this has been covered (I try to keep up to date on the Mojo news), but will Mojo be as efficient in mouse broadcasting as ISBoxer? I love the flexibility of HKN, and given the scripting nature I doubt ISBoxer can do all that I'm doing through HKN, but the consensus is ISBoxer is the clear winner for mouse broadcasting. I'm not sure why it works as well as it does, so all I can ask is an uneducated question of if Mojo will work as well.
I don't know how ISBoxer is written (I've never seen it let alone looked at it in a debugger) but I suspect it hooks DLLs and injects code. Mojo won't do those things.

Given that difference, I don't know if I can make Mojo inject mouse events as quickly as Lax's software. All I can say is that I'm going to try. Wish me luck. :)

I'm planning to use different code in Mojo for injecting mouse events than the code in HotkeyNet.

Also, I may add a device driver to Mojo at some point which would let me do some low-level chicanery, and that might help too.

Something to think about is, Mojo will probably get "finished" in 2012. Then figure it's widely used for five years before it becomes obsolete compared to its competition.

During Mojo's lifetime, 16 and 32 core CPUs will be normal. On that kind of hardware, I think any method of injecting mouse events, even crappy methods, will be fast enough to appear instantaneous.

[Freddie]

Funny note: Microsoft may "suggest" that you stay away from the word advanced... but even Win7 has an Advanced Find :p.

This reminds me. Some people might find this fun, and it could help.

Microsoft has a division that publishes design guidelines. It's a big document -- 800+ pages -- and it consists mainly of suggestions that have to be applied with judgment.

I usually try to follow it. If anybody wants to read it and help make Mojo stick to it better, that would be great.

Download at:

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=e49820cb-954d-45ae-9cb3-1b9e8ea7fe8c

[Freddie]

About DNP... while a different DNP for different Wow is maybe nice; the basic DNP I need is just same DNP for every window (but the one that has the mouse, which obviously gets all the keys)

I have to write code in an efficient way. Sometimes that means the first iteration of a feature has to have a mimimum level of complexity so I can be sure the basic design will work for everything that it will be used for.

In this case, if I tried to write code that only handled DNP, it's extrremely likely that I'd end up throwing that code away and writing something new from scratch when I tried to add the other features we're talking about.

[Freddie]

No - but sorta.

This is a keymap from MOJO #1's point of view (PC1 in my case).

PC2 would have a slightly differnet keymap. Same for 3,4,5.

But you bring up a good question about same-box multiboxing. Hmm....

EIDT: I'm thinking make it based on which window has "FOCUS" (windows focus, not WoW focus) at the time. But thats a question for Freddie.
We have to back up and think about the problem in a very general way.

Here's the deal.

Basically, this screen represents a lot of individual decisions. Each decision has three variables:

1. Which WoW has the focus.

2. Which WoW is the target.

3. Which key gets pressed.

These things are represented graphically as:

1. The WoW on the left.

2. The WoW on the right.

3. The line (row) of the spreadsheet.

To make this post easier to understand, let's pretend the user has five WoWs on the same PC.

There can be five WoWs on the left.

There can be five WoWs on the right.

In addition, the user might want to set a default for any WoW being on the left.

In addition, the user might want to set a default for any WoW being on the right.

That's 36 permutations.

I've said a couple of times that I think the program should use the metaphor of "nested" settings to simplify things, where one setting is a default and another setting "inherits" and "overrides" the default.

I know this sounds jargony and complicated but the idea is actually simple, and if it's used throughout the program, and if the screens represent the idea in a good graphical way, I think it might be the easiest thing.

So here's what I'm coming up with.

Fursphere's drawing gets simplified. It has a new basic form with only two columns. The column on the left is the default for the focus WoW. The column on the right is the default for the target WoW.

In other words, if the user only uses those two columns, they define what happens when any WoW is in the foreground (left) and what gets received by all WoWs (right).

But if the user wants, he or she can add columns on either the left or right for individual WoWs.

Once columns are added, the user can click on them to highlight them.

When that happens, it sets the permuation for the entire table.

Actually I'm not sure that works -- I need to drink a cup of coffee and draw some examples. :)

[Freddie]

There's a problem with the scheme I just outlined, but it has two possible resolutions.

Suppose the user defines the key mapping for a particular key with WoW1 on the left and default (any WoW) on the right.

And suppose the user defines the key mapping for that same key with default (any WoW) on the left and Wow2 on the right.

Now he's playing. WoW1 is in the foreground. He presses that key. What gets sent to WoW2?

Mojo looks at its settings to answer that question. Unfortunately it discovers that there are two different answers. One answer is the setting in "Default left, WoW2 on right." The other answer is the setting in "WoW1 left, default right."

(If the user defined a setting for "WoW1 on left, WoW2 on right", there isn't any problem, but let's supposed he didn't.)

How does Mojo pick one of those two solutions?

Either Mojo resolves the ambiguity by choosing the setting that is more narrowly defined on the left (in other words, it cares more about the foreground than the target), or else Mojo looks higher in the inheritance hierarchy and uses the "default on left, default on right" setting.

You and I are probably thinking the same thing right now. This is way too complicated. This is nuts.

But I don't know how to avoid this.

Because this "problem" is just math. If the program allows people to choose these settings, then mathematically, this problem arises. It's not part of the way we're drawing the screens or anything like that.

Reactions, please! :)

Edit: Another possible solution would be Mojo to look for ambiguities of this sort when the user changes settings. If Mojo finds one, it highlights the key mapping and asks the user to choose which mapping to use.

This is how programming tools handle this kind of problem . But this seems awfully complex and confusing for the average multiboxer.

[Fursphere]

This is why I spoke "DNP" list first, "keymaps" second. A DNP list can be static and simple - you don't have logic loops.

Foreground WoW takes priority, and thats it.

You could probably write some code to check for logic loops - and in the even of one happening saying "hey dummy - check your keymaps!" :) but thats more work.

[Freddie]

This is why I spoke "DNP" list first, "keymaps" second. A DNP list can be static and simple - you don't have logic loops.
Edit:

I have to figure out the design of the whole thing before I write code for the simplest case.

Otherwise, like I told moorea a few minutes ago, that would be more work for me, not less.


Foreground WoW takes priority, and thats it.
As far as that goes, that's fine, but the user might want to define things more narrowly and the program has to make clear in some comprehensible way how to do it.


You could probably write some code to check for logic loops - and in the even of one happening saying "hey dummy - check your keymaps!" :) but thats more work.
It's not any more work because it's basically the same work the program will do every time you press a key.

Edit: This is a microscopic amount of work for the CPU. It's complicated to explain but it's the kind of thing that takes very few CPU cycles.

[Freddie]

How about we separate the WoWs from the columns. Then we always have two columns and the screen looks simpler. People could pick the WoWs from a drop down lists (as shown here) or I could make litte rectangles with an icon for each WoW.

The right hand column is color-coded to indicate whether the setting is inherited from a "higher" screen or whether it was set on this one.

Edit: red could be used to indicate ambiguity, but if the user ignores red, the program would use the "left-first" rule described above.

Edit: By the way, for peope who are thinking this is too complicated, this screen is all that most users need to look at.

http://mojoware.org/art/keymap.gif

[Freddie]

Freddie,
Go back and look at my two screenshots... and add the "in foreground" and "in background" under "Key Out" and "Mouse Out" sections. Then, I think it would solve this problem.
Your design was so confusing to me that I didn't understand what it did even after I asked you to explain three or four times.

[Moorea]

consider KISS principle :-) for 99.9% of users and case; the only thing you need is

- all the keys always go to the window where the mouse is

- some keys (the DNP) don't go to all the other windows

if you can do the more complicated cases above while still preserving this use case simple to achieve, then the more power - otherwise split the ui so the above is ez to get (and hopefully we can get that faster than the rest :-p)


ps: the spreadsheet was scary

[Freddie]

consider KISS principle :-) for 99.9% of users and case; the only thing you need is

- all the keys always go to the window where the mouse is

- some keys (the DNP) don't go to all the other windows

if you can do the more complicated cases above while still preserving this use case simple to achieve, then the more power - otherwise split the ui so the above is ez to get
How about we work on the design for a single window for a while and see how easy we can make it.


ps: the spreadsheet was scary
Which spreadsheet? Fur's or mine?

[Moorea]

fur's but I should have added a smiley - not that scary - just a bit

[Freddie]

If Fur's design is confusing, do you also find WoW's window confusing?

They use the exact same visual metaphor.

All three windows show (1) the user's key press side-by-side with (2) the action that they trigger.

The only differences are that WoW reverses left and right, and different columns get duplicated, and WoW uses the output column to establish the order whereas Fur's and mine use the input column.

Also, to nullify a trigger, WoW shows "not bound" in the input column whereas Fur's and mine show something in the output column (either "Do not pass" or "nothing").

By the way I am inclined not to use the word "pass" anywhere in Mojo. I think it's a bad metaphor for how multiboxing programs work,.

I'd rather use the metaphor of trigger and action. When the user presses a key with his finger, that triggers Mojo to send signals to his WoW's. That's closer to the truth and it makes a lot of features easier to understand.

In all three windows, one column is the trigger and another column is the action. The trigger is always a key or key combo.


http://mojoware.org/art/wow-key-binding.jpg

[Fursphere]

By the way I am inclined not to use the word "pass" anywhere in Mojo. I think it's a bad metaphor for how multiboxing programs work,.

Ok, i'll bite. I don't see "action" or "trigger" representing the fuctionality either though. Getting rid of "pass" makes sense - but we should replace it with a proper term that defines the function.

"send" ? (because you're sending keystrokes to one or more targets?)
"broadcast" - obvious to us, but what about non techy geeks?
"inject" - meh - sounds too much like botting
???

[Freddie]

Ok, i'll bite. I don't see "action" or "trigger" representing the fuctionality either though. Getting rid of "pass" makes sense - but we should replace it with a proper term that defines the function.

"send" ? (because you're sending keystrokes to one or more targets?)
"broadcast" - obvious to us, but what about non techy geeks?
"inject" - meh - sounds too much like botting
???
When Mojo broadcasts, its action is sending. (I like "send" the best on your list.)

But Mojo will also rename windows and toggle PiP layouts. It does a lot of different actions.

Trigger and action are general ideas that appy to everything.

They are analogous to "input" and "output" on your spreadsheet.

The mere fact that there IS an input and there IS an output is the essential thing.

That there is a cause and effect. The user moves a finger and the multibox program performs some action.

This is an incredibly simple idea, and a lot of people don't understand this. I think this is one of the things that confuses them.

I think the design of the program can educate users just by choosing terms and laying out screens in a particular way.

[Freddie]

I changed the header of the second column. Now it says "send."

I'm trying to show two things:

1, The layout shows cause and effect without saying anything about it in words.

(I added "trigger" and "actions" only for us here. They aren't part of the window.)

2. It's basically the same as WoW's screen.

http://mojoware.org/art/keymap2.gif

http://mojoware.org/art/wow-key-binding.jpg

[Fursphere]

I changed the header of the second column. Now it says "send."

I'm trying to show two things:

-- The visual layout shows cause and effect, trigger and action.

This is shown visually. The words don't have to be used.

-- It's basically the same as WoW's screen.




I like it. :D

[Freddie]

I like it. :D
It's the same thing you did.

I'm just trying to explain why I think it's a good way. :)

[Freddie]

I love it that the machine with the focus gets the keyboard. If it can be made an option, even better!
Optional compared to what other option?

What are the two ways?

[Moorea]

the other way is sticky focus but I'm not sure it's needed for playing

[Freddie]

the other way is sticky focus but I'm not sure it's needed for playing
I'm sorry, I just don't understand either idea. (Either this one or UnixMan's.) Can somebody explain?

[Moorea]

sticky focus is where even if you move the mouse from window to window the focus stays on the original window; until typically you click or otherwise decide to change it (in this case some hotkey could be how to trigger change of focus - but again I think the default of moving focus with mouse movement is the best for wow)

[Freddie]

sticky focus is where even if you move the mouse from window to window the focus stays on the original window; until typically you click or otherwise decide to change it (in this case some hotkey could be how to trigger change of focus - but again I think the default of moving focus with mouse movement is the best for wow)
Sounds like your "sticky mouse" is just Windows's default behavior, what you're calling the default is Windows's behavior with Active Window Tracking turned on. Am I misunderstanding?

Active Window Tracking (also called X-Mouse or Focus Follows Mouse) is built into Windows as an option but the operating system doesn't provide a way to toggle it, so I can add that to Mojo.

HotkeyNet has that already.

But UnixMan said, "I love it that the machine with the focus gets the keyboard. If it can be made an option, even better! " and that has to do with a machine, not windows, so I think he may have been talking about something else.

[Fursphere]

I think he means that with zero configuration, the machine with the keyboard physically attached is the one that broadcasts by default.

When you mouseover to machine #2 - that becomes the "boardcasting" machine. (assuming broadcasting it turned on on all machines)

[Freddie]

Okay, then back to my first question. When UnixMan said make it an option, what's the alternative?

Maybe he just meant that broadcasting would be off on the remote machine.

[Fursphere]

I *think* he means two ways to use the program.

One requires changing the active window to be Window's "Focus" to accept input - the other would reqiure the "Mouse cursor" to just be over a window for it to accept input. (changing focus without chaning focus)

The later could be used for like mouseover healing or something - although I don't know if WoW itself will work that way.

[Freddie]

I *think* he means two ways to use the program.

One requires changing the active window to be Window's "Focus" to accept input - the other would reqiure the "Mouse cursor" to just be over a window for it to accept input. (changing focus without chaning focus)

The later could be used for like mouseover healing or something - although I don't know if WoW itself will work that way.
Okay, that's Active Window Tracking. Like I just said somewhere ellse, I'll add a toggle for that to the next build.

[UNIXman]

I *think* he means two ways to use the program.

One requires changing the active window to be Window's "Focus" to accept input - the other would reqiure the "Mouse cursor" to just be over a window for it to accept input. (changing focus without chaning focus)

The later could be used for like mouseover healing or something - although I don't know if WoW itself will work that way.

Touché! Thanks!