Build 14: New code for injecting keystrokes

[Fursphere]

So - fired up mojo and saw the auto-update feature kick off and work flawlessly. Nice!

Did some simple 'boxing this morning - everything worked fine. I didn't check out the CTRL - ALT - SHIFT passing, totally forgot about that.

Also notice it was picking up and "showing" each running WoW on each instance of mojo - but it didn't show clients from other PCs. I assume thats a work in progress still?

I was thinking maybe you could code in a hook to Windows Notepad.exe for testing? That way I can just test a crap ton of key combinations and see the output outside of WoW? (sometimes WoW does funny stuff with combinations)

[Freddie]

So - fired up mojo and saw the auto-update feature kick off and work flawlessly. Nice!

Thanks for testing!

Microsoft gets the credit for auto-update -- it's handled entirely by CickOnce.

Also notice it was picking up and "showing" each running WoW on each instance of mojo - but it didn't show clients from other PCs. I assume thats a work in progress still?

Right. I'm having trouble figuring out how much info should be sent from one PC to the others. Here's the problem. My first inclination was to show info from each Mojo on all Mojos. That's a simple rule: everything appears everywhere.

But if all the Mojos know everything about all the WoWs that are configured to be launched, people will expect to be able to change the info on any copy of Mojo. But that won't work because the config info will break if the user makes a change while one Mojo is off and then later turns all the Mojos on and they find themselves out of sync with each other. So there has to be some limitation on info-trading, or some indication that one particular Mojo is in control, and I'm not sure how to do that without making the program seem complicated.

I was thinking maybe you could code in a hook to Windows Notepad.exe for testing? That way I can just test a crap ton of key combinations and see the output outside of WoW? (sometimes WoW does funny stuff with combinations)

I could do that but it will only test a fraction of what needs to be tested. I think the new key broadcast code can only be tested thoroughly with WoW.

Edit: I'll explain what I just said in a second. But first, I don't think it's necessary to test this thoroughly now because it will get tested very thoroughly in normal use as people use the program more and more.

As far as keystroke signals go (which is only part of what this new code does) Notepad would only show whether character keys get shifted properly and whether a handful of Ctrl combos (the ones that are assigned to Notepad's menu items) get received.

There's another aspect to this code that wouldn't get tested very well. In addition to sending keystroke signals, the code maintains something called a keyboard state for each WoW. Normally this is maintained by the operating system but in order to handle shifting on remote PCs (and also things like AltGr keys in foreign languages), build 14 has a system where Mojo counterfeits the keyboard state for each WoW. Different programs (WoW, Notepad, etc.) may use their keyboard states in different ways, and I'm afraid that the only way to see if the code works with WoW is to test it with WoW.

[Pocalypse]

But if all the Mojos know everything about all the WoWs that are configured to be launched, people will expect to be able to change the info on any copy of Mojo. But that won't work because the config info will break if the user makes a change while one Mojo is off and then later turns all the Mojos on and they find themselves out of sync with each other. So there has to be some limitation on info-trading, or some indication that one particular Mojo is in control, and I'm not sure how to do that without making the program seem complicated.

Do you cache the settings in a file somewhere (or in memory somewhere)? Then, when the already open Mojo with changes detects a new Mojo on the network, it can send over all the settings at the same time, and update the new Mojo.

I suppose then you have to start thinking about which Mojo has more up to date information, and the order in which Mojos are opened.

Just a thought.

[Freddie]

Do you cache the settings in a file somewhere (or in memory somewhere)?

Settings are saved in files.

Then, when the already open Mojo with changes detects a new Mojo on the network, it can send over all the settings at the same time, and update the new Mojo.

That works in that case but there are many other cases. Suppose one Mojo has run and been changed and shut down by itself. Then the same thing with the second. Then you start the first. Then you start the second. See the problem?

I suppose then you have to start thinking about which Mojo has more up to date information, and the order in which Mojos are opened.

Exactly. That's the problem. In general, it seems to be impossible to know which file is newer because the files have timestamps based on clocks in different computers.

I think probably the only way to do this is with a central repository for the info which means Mojo would no longer be 100% peer to peer. I'd like to hold on to peer to peer as a "100% design invariant" for the life of the project, if that's possible.

This problem has already arisen with mouseover and I handled it by creating entirely separate settings on each PC. I'm inclined to think the solution lies in that direction.

The basic idea would be, each computer is the master repository for settings that were created on that computer. As a result, each Mojo could have different settings.

It would be easier for me if each computer is the master repository for its own instances of WoW, but then maybe it starts to get complicated for the user.

[TheFallenOne]

Exactly. That's the problem. In general, it seems to be impossible to know which file is newer because the files have timestamps based on clocks in different computers.

I think probably the only way to do this is with a central repository for the info which means Mojo would no longer be 100% peer to peer. I'd like to hold on to peer to peer as a "100% design invariant" for the life of the project, if that's possible.

This problem has already arisen with mouseover and I handled it by creating entirely separate settings on each PC. I'm inclined to think the solution lies in that direction.

The basic idea would be, each computer is the master repository for settings that were created on that computer. As a result, each Mojo could have different settings.

It would be easier for me if each computer is the master repository for its own instances of WoW, but then maybe it starts to get complicated for the user.

Another option (food for thought):

Settings are saved with a version #, starting at 0, incremented by 1 every time the file is updated. The version number is also appended with a unique identifier specifying which computer the settings came from (maybe a MAC ID, some kind of product ID, or something similar).

When multiple computers connect, they compare version stamps. Say we have C1 and C2 connecting to each other. C1 has a settings file with version stamp as, say... 18-C1, and C2 has a settings file with version 16-C1. This indicates that C2 has previously received settings from C1, and automatically updates to 18-C1 from C1.

Now, if you update the settings on C2, they would be saved with the new version stamp 19-C2. This would be sent along with the last NON-C2 version stamp that the settings were updated from, and C1 would look at the incoming stamps, see that C2 has been updated from 18-C1 (which is C1's current version and the last non-C2 version stamp that was used) to 19-C2, and so it determines it should update too (since it's on 18-C1), and now saves it's version stamp as 19-C2.

Now for the part where things might get a little less straightforward... Both computers are on 26-C1, and you disconnect both computers. You do an update on both C1 and C2, and then reconnect them. Version stamps are compared, and since both have been updated independently, a "fork" is created in the settings tree. A dialog pops up, notifying the user that the settings from both of them do not match, and allowing them to choose whether to use the settings from C1, settings from C2, or leave them in a forked state.


I'm running on very little sleep, so I apologize if some of this is a little unintelligible. Anyways, just some food for thought, maybe you'll get some ideas from it.


EDIT: I also actually rather like the idea of "pushing" settings from one Mojo to the others (mentioned by Aragent above), ALA how Jamba handles things. I believe that would work rather nicely.

[Freddie]

Another option (food for thought):

Settings are saved with a version #, starting at 0, incremented by 1 every time the file is updated. The version number is also appended with a unique identifier specifying which computer the settings came from (maybe a MAC ID, some kind of product ID, or something similar).

When multiple computers connect, they compare version stamps. Say we have C1 and C2 connecting to each other. C1 has a settings file with version stamp as, say... 18-C1, and C2 has a settings file with version 16-C1. This indicates that C2 has previously received settings from C1, and automatically updates to 18-C1 from C1.

Now, if you update the settings on C2, they would be saved with the new version stamp 19-C2. This would be sent along with the last NON-C2 version stamp that the settings were updated from, and C1 would look at the incoming stamps, see that C2 has been updated from 18-C1 (which is C1's current version and the last non-C2 version stamp that was used) to 19-C2, and so it determines it should update too (since it's on 18-C1), and now saves it's version stamp as 19-C2.

Now for the part where things might get a little less straightforward... Both computers are on 26-C1, and you disconnect both computers. You do an update on both C1 and C2, and then reconnect them. Version stamps are compared, and since both have been updated independently, a "fork" is created in the settings tree. A dialog pops up, notifying the user that the settings from both of them do not match, and allowing them to choose whether to use the settings from C1, settings from C2, or leave them in a forked state.

Maybe I'm missing something, but it seems to me there are basically two main cases. In one case, the Mojos are running simultaneously and talking to each other. In that situation, whenever you change one Mojo, it tells the others. All changes immediately propagate. There's no need for version numbers or anything else.

The second case is what you call "less straightforward." It occurs when you change Mojo A while it's not talking to Mojo B, and then you change Mojo B while it's not talking to Mojo A. When they find themselves in communication again, they have no way to know which one was updated more recently.

If the first case doesn't require a solution, and your solution doesn't solve the second problem, what is it useful for?

Those two cases aren't logically exclusive so there must be other circumstances, but I'm having trouble getting a sense of how common they would be. Can you give me an example where version numbers would help?

EDIT: I also actually rather like the idea of "pushing" settings from one Mojo to the others (mentioned by Aragent above), ALA how Jamba handles things. I believe that would work rather nicely.

I'll look into Jamba. Thanks for suggesting it.