Build 16: Alt-tab bug fixed

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



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

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



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.

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

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.