Build 16: Alt-tab bug fixed

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

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

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/m...pExample01.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)