Gammon Forum : MUSHclient : Suggestions : Miniwindow key events

Entire forum ➜ MUSHclient ➜ Suggestions ➜ Miniwindow key events

Miniwindow key events

It is now over 60 days since the last post. This thread is closed. Refresh page

Posted by

Twisol USA (2,257 posts) Bio

Date

Mon 29 Nov 2010 01:46 AM (UTC)

Amended on Mon 29 Nov 2010 02:20 AM (UTC) by Twisol

Message

I'm not sure if I've written anything much about this yet, though I know I've mentioned it in passing in posts. But recently someone else (Retnur, who posted here previously) asked me about the very same thing. So I may as well explain it in detail and hope for the best.

Synopsis: Currently, the only ways to get input from the user are using the input box (i.e. aliases or catching it in an OnPlugin* callback) or using a modal dialog from utils.*. It is desirable to direct key events directly to individual handlers in order to handle user input more efficiently. For example, a tabbed IM miniwindow with a drawn text box for each conversation, which a plugin can draw text into as the user types.

Details: To implement this effectively, I propose that two new mechanics be created.

1) The hotspot with "focus" be tracked internally. Focus may be tracked by the more typical "whatever I clicked last" mechanic, or a script function (WindowFocus?) might be created to let scripts decide when something has focus.
2) A new hotspot-based callback that receives key events.

Whichever hotspot has focus when a key is pressed will receive the key event. If no hotspot is focused, the key event is processed as normal. In addition, if the callback returns false, the key event is processed as normal.

Conclusion: I think that enabling capture of user input directly would be a boon to miniwindow developers, allowing users to manage multiple "typing" activities more effectively, and in other ways than the "type stuff and hit enter" method.

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol

Top

Posted by

Nick Gammon Australia (23,072 posts) Bio Forum Administrator

Date

Reply #1 on Mon 29 Nov 2010 03:24 AM (UTC)

Amended on Mon 29 Nov 2010 03:25 AM (UTC) by Nick Gammon

Message

I see where you are coming from, but I wonder what other plugin developers, or client users, think?

As usual, when something like this is proposed I try to think of ways it could go wrong (not in a negative way, but trying to anticipate problems).

For example:

If a miniwindow "dialog" box was created you would want the focus - maybe - to go into an input box somewhere. So simply clicking may not be an appropriate mechanism. (You might need to command the focus to move).
However if a dialog did pop up, and move the focus away from the command window, this might be annoying if you were half-way through typing some important command (eg. "flee").
You probably want <tab> to move between "input" fields - in which case it changes the current behaviour for <tab> which is to put the cursor into the command window. (And, tab-completion).
If the miniwindow happens to be not visible (eg. they have resized the output window), or if the input field (where the focus is) is not visible (perhaps it is just off the screen, or something else is on top of it) then they might be typing but not see any visible results.
How would you get the focus back to the command window if you needed to respond to a tell, for example? And then back to the miniwindow?
Would special sequences like tab-completion be disabled if the focus was not in the command window?
Would accelerator keys have their original meaning, or some new meaning, if the focus was not in the command window?
Will the next sequence in this train of thoughts lead to text boxes, with wrapping at the edge of the box, insert or overwrite modes, etc?
What about copy and paste? Would you expect those to be trapped so that the miniwindow could handle them?
Even if you trap Ctrl+C and Ctrl+V keystrokes, what about the menu items which do the same thing?
If you hit F1 for help, will that bring up the standard output-window help, or some miniwindow-defined help?

I can see the attraction of wanting input areas in miniwindows. But I wonder if this is turning what is basically a text client with some nice graphical widgets (eg. maps) into a fully-fledged GUI interface? And if so, will it work? Is it worth the effort?

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Top

Posted by

Nick Gammon Australia (23,072 posts) Bio Forum Administrator

Date

Reply #2 on Mon 29 Nov 2010 03:25 AM (UTC)

Message

Also, what if two plugins both want to grab the focus? Which one takes priority?

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Top

Posted by

Twisol USA (2,257 posts) Bio

Date

Reply #3 on Mon 29 Nov 2010 04:36 AM (UTC)

Message

Nick Gammon said:
I see where you are coming from, but I wonder what other plugin developers, or client users, think?

Well, I came up with the idea a long time ago, but Retnur suggested it to me just today (and I'm pretty sure he didn't know I had come up with it too). So that's two individual developers who would like to see it.

Nick Gammon said:
*If a miniwindow "dialog" box was created you would want the focus - maybe - to go into an input box somewhere. So simply clicking may not be an appropriate mechanism. (You might need to command the focus to move).

If clicking is insufficient for some tasks, there's always the WindowFocus()-based alternative I suggested. The idea is to enable non-modal dialogs, though. If you want some kind of modal inputs, you can either use one of the utils.* functions or implement WindowFocus().

Nick Gammon said:
*However if a dialog did pop up, and move the focus away from the command window, this might be annoying if you were half-way through typing some important command (eg. "flee").

You can already do far worse to someone's computer with plugins, and (as far as we know) nothing severe has happened. The power is there, but it's being used responsibly. This seems like a similar case: give them the tools, and let them build things. People just won't use the un-useful and/or destructive plugins.

Nick Gammon said:
*You probably want <tab> to move between "input" fields - in which case it changes the current behaviour for <tab> which is to put the cursor into the command window. (And, tab-completion).

Currently, tab-completion depends on the input area having the focus anyways (which it always does), so I'm not sure that's a huge issue. If you're not typing in it, you don't expect it to be tab-completed.

As for tabbing between inputs, that's actually an excellent case for WindowFocus. I'm not sure I've ever used the "tab into command area" functionality you mention...

Nick Gammon said:
*If the miniwindow happens to be not visible (eg. they have resized the output window), or if the input field (where the focus is) is not visible (perhaps it is just off the screen, or something else is on top of it) then they might be typing but not see any visible results.

That's an already-existing problem; the only difference is that it's more pronounced because you're typing, which usually has a much higher speed than clicking buttons. The best thing to do is design your miniwindow to stay on-screen, I guess. Under my proposal, it's also possible to create miniwindows that don't show any typed text at all.

Nick Gammon said:
*How would you get the focus back to the command window if you needed to respond to a tell, for example? And then back to the miniwindow?

To return to the command window manually, I'd imagine you would just click it, as would now if "all typing goes to command window" disabled). To return to what you were doing in a miniwindow, that's something the author needs to handle. Probably just clicking on it would suffice again.

Nick Gammon said:
*Would special sequences like tab-completion be disabled if the focus was not in the command window?

As per above, yes. Tab completion only applies to content inside the command window, unless I'm very mistaken. If there's no focus in the command window, it doesn't make sense to hit tab and have something unrelated happen. All key events (with potential exceptions?) would be directed to the hotspot event.

Nick Gammon said:
*Would accelerator keys have their original meaning, or some new meaning, if the focus was not in the command window?

Good question. This is a good reason to allow for event fall-through with a false return value: the handler can filter events rather than hog them all. If the author wants to catch everything, that's their prerogative.

Nick Gammon said:
*Will the next sequence in this train of thoughts lead to text boxes, with wrapping at the edge of the box, insert or overwrite modes, etc?

Probably, but that can be built on top of the basic building blocks. You could already build text-wrapping windows (and I know at least one person who already has). The only difference is that we can provide input through the keyboard now.

Nick Gammon said:
*What about copy and paste? Would you expect those to be trapped so that the miniwindow could handle them?

Yes. After all, what is the user copying? The last thing they clicked, most likely. If they're taking text from the output window, it's the output window that has "focus". Likewise, "paste" has a definitive destination as well, and it's typically the last thing you clicked (or somewhere therein once you use the keyboard to navigate inside it).

Nick Gammon said:
*Even if you trap Ctrl+C and Ctrl+V keystrokes, what about the menu items which do the same thing?

If a hotspot currently has "focus", it's up to the associated event handler to decide what it uses and what it lets MUSHclient deal with.

Speaking of which, I think a flag would need to be added to WindowAddHotspot in order to make the hotspot eligible for focus. It probably makes sense to have a focus callback too, so it knows when it's focused and blurred so it can animate accordingly.

Nick Gammon said:
*If you hit F1 for help, will that bring up the standard output-window help, or some miniwindow-defined help?

That might be one of the keypresses you want to leave to MUSHclient. But then, you already have an "F1, F6 are macros" option in Global Preferences, so just leave it dependent on that.

Nick Gammon said:
Also, what if two plugins both want to grab the focus? Which one takes priority?

I'm inclined to say "the last one to ask for it". It seems like that's how Windows works too [1].

Nick Gammon said:
I can see the attraction of wanting input areas in miniwindows. But I wonder if this is turning what is basically a text client with some nice graphical widgets (eg. maps) into a fully-fledged GUI interface? And if so, will it work? Is it worth the effort?

Well, I understand if this idea is pushing MUSHclient away from what you want it to be. MUSHclient is also fifteen years old. MUDs are really fun, but the various means of playing them don't measure up to games and clients in other fields. I think this would be a good way to keep MUSHclient evolving.

[1] http://msdn.microsoft.com/en-us/library/ms646311(VS.85).aspx

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol

Top

Posted by

Nick Gammon Australia (23,072 posts) Bio Forum Administrator

Date

Reply #4 on Mon 29 Nov 2010 09:04 PM (UTC)

Message

Twisol said:

Well, I came up with the idea a long time ago, but Retnur suggested it to me just today (and I'm pretty sure he didn't know I had come up with it too). So that's two individual developers who would like to see it.

Going back over his posts, he hasn't mentioned it here. I don't want to see resistant to good ideas but it would be nice to have a few of the plugin developers offer support here.

Thinking about your idea a bit more, I think it probably can be done fairly simply along these lines:

Any miniwindow can request the focus (eg. WindowGetFocus). It would succeed if:
- The miniwindow exists
- It is currently visible
- It doesn't already have the focus
- It doesn't have the "create_underneath" flag set
If a plugin which previously had the focus loses it, an OnPluginLostMiniwindowFocus callback would be called. This lets the plugin change the visible look of the window (eg. removing a cursor, changing the border).
On successfully claiming the focus an OnPluginGotMiniwindowFocus callback would be called. This lets plugins draw the focus visibly (eg. drawing a cursor, changing the border of a text window).
From a Windows point of view, the focus will be moved to the output window, thus removing the flashing cursor from the command window, and changing relevant menu activations to whatever they normally are if the focus is in the output window.
It would be up to the plugin to handle mouse-clicks, key events etc. that might move the focus around inside a particular miniwindow (eg. from one text field to another) by using hotspots and detecting keystrokes. From the point of view of the client, the entire miniwindow has the focus, not a particular part of it.
If any miniwindow has the focus, then mouse-down, mouse-up, and key events (these are three separate Windows events) will be directed to suitable plugin callback functions.
Ditto for certain other events like copy/paste commands activated.
If the callback function exists, and returns true on handling the event, then it will be assumed to have been processed by the miniwindow and no further processing will take place. If the function returns false (or no value) then the usual processing will take place. The "usual processing" is whatever would have happened normally. For example, macro keys like F7 could return false so the usual macro still works.
If a miniwindow is destroyed, or becomes invisible (ie. WindowShow (win, false) or the auto-positioning makes it invisible) then that miniwindow loses the focus.
If a miniwindow loses the focus, and not in favour of another miniwindow gaining it, then the command window regains the focus.
If the user clicks on the command window it gains the focus.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Top

Posted by

Twisol USA (2,257 posts) Bio

Date

Reply #5 on Mon 29 Nov 2010 10:24 PM (UTC)

Message

Nick Gammon said:
Going back over his posts, he hasn't mentioned it here. I don't want to see resistant to good ideas but it would be nice to have a few of the plugin developers offer support here.

No, he doesn't have reliable internet access right now, so he asked me to do it.

Nick Gammon said:
*It doesn't already have the focus

This case should not be a failure, but an implicit success.

Nick Gammon said:
*If a plugin which previously had the focus loses it, an OnPluginLostMiniwindowFocus callback would be called. This lets the plugin change the visible look of the window (eg. removing a cursor, changing the border).

*On successfully claiming the focus an OnPluginGotMiniwindowFocus callback would be called. This lets plugins draw the focus visibly (eg. drawing a cursor, changing the border of a text window).

But there isn't a 1:1 correlation between plugins and windows. It seems easier just to create a per-hotspot focus handler that's called on both focus and blur.

Also, it's not the window that has focus, but the hotspot on a window. It would be harder to create a window with multiple input areas if it was per-window, especially because windows can't be composited except as images.

In essense, a WindowFocusHandler function should be created, much like WindowDragHandler works now.

Nick Gammon said:
*From a Windows point of view, the focus will be moved to the output window, thus removing the flashing cursor from the command window, and changing relevant menu activations to whatever they normally are if the focus is in the output window.

Sensible, yep.

Nick Gammon said:
*It would be up to the plugin to handle mouse-clicks, key events etc. that might move the focus around inside a particular miniwindow (eg. from one text field to another) by using hotspots and detecting keystrokes. From the point of view of the client, the entire miniwindow has the focus, not a particular part of it.

It's easier to manage and track these sort of focus change events when the callback is directly associated with the hotspot. Otherwise, I need to implement some kind of routing logic in the plugin callback where "if it's hotspot 1, do this, else if it's hotspot 2, do that", which the client is perfectly capable of doing itself with hotspot callbacks.

Nick Gammon said:
*If any miniwindow has the focus, then mouse-down, mouse-up, and key events (these are three separate Windows events) will be directed to suitable plugin callback functions.

Replace plugin with hotspot and I'm with you. ;)

Nick Gammon said:
*If a miniwindow loses the focus, and not in favour of another miniwindow gaining it, then the command window regains the focus.

Assuming "all typing goes to command window" is enabled. If it's not, does it go to the output window? Or if this disregards that option, then what purpose does it serve anymore? (I'm in favor of disregarding/removing it, myself - it doesn't make sense for typing to -not- go to the command window IMHO)

Nick Gammon said:
*If the user clicks on the command window it gains the focus.

Or otherwise regains the focus, e.g. via scripting, or a key event left unhandled that the client happens to interpret as giving the command window focus. (Like how you said 'tab' works now.)

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol

Top

Posted by

Nick Gammon Australia (23,072 posts) Bio Forum Administrator

Date

Reply #6 on Tue 30 Nov 2010 01:05 AM (UTC)

Message

Twisol said:

Nick Gammon said:
*It doesn't already have the focus

This case should not be a failure, but an implicit success.

Well, no. It isn't getting the focus. If you go to turn your computer on, and it is already on, you don't succeed in turning it on. You actually do nothing.

I suppose it could return a "success" code, but it wouldn't raise the event "just got focus" because it already has it.

Twisol said:

Also, it's not the window that has focus, but the hotspot on a window.

Actually, hotspots are not visual elements at all. There are rectangular areas that respond to mouse-clicks. When you type something it doesn't have an x-y coordinate that can be linked to a hotspot.

If you are writing a framework you can work out which hotspot (if any) "has the focus". Things like tab-forwards and tab-backwards, for example, really belong to the window, not the hotspot. That is, the owner (the window) is moving the focus from one sub-window (hotspot) to another. Other keys, like a help key might bring up help for the entire window, or <esc> would probably dismiss the entire window, not the hotspot.

Twisol said:

It would be harder to create a window with multiple input areas if it was per-window, especially because windows can't be composited except as images.

I don't understand that. You could make an window of text as prompts, and rectangles for the typing into. Images don't have to come into it.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Top

Posted by

Nick Gammon Australia (23,072 posts) Bio Forum Administrator

Date

Reply #7 on Tue 30 Nov 2010 01:11 AM (UTC)

Message

Twisol said:

MUDs are really fun, but the various means of playing them don't measure up to games and clients in other fields. I think this would be a good way to keep MUSHclient evolving.

Whilst I have been pushing the same thoughts myself, there are some that don't agree with this. For example, the "No Graphics" MUD support group:

http://nogfx.org/

Also an interesting alternative that got mentioned the other day was IupLua - a cross-platform GUI interface, involving Lua:

http://www.tecgraf.puc-rio.br/iup/

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Top

Posted by

Twisol USA (2,257 posts) Bio

Date

Reply #8 on Tue 30 Nov 2010 02:00 AM (UTC)

Message

Nick Gammon said:

Twisol said:

Nick Gammon said:
*It doesn't already have the focus

This case should not be a failure, but an implicit success.

Yes, that's what I meant by "implicit success". It's certainly not an error (you have what you wanted), but it shouldn't necessarily do anything either. All the calling code needs to know is that it has focus.

Nick Gammon said:

Twisol said:

Also, it's not the window that has focus, but the hotspot on a window.

Actually, hotspots are not visual elements at all. There are rectangular areas that respond to mouse-clicks. When you type something it doesn't have an x-y coordinate that can be linked to a hotspot.

"Focus" is just a mechanism for routing events to the right place. I see no reason to separate the location of "focus" from the place the key events are sent. As I said before, windows can't be composited except as images. If it's the window that has focus rather than the hotspot, then you force the developer to write code to determine which region is focused (and hence, which functionality is enabled). This work will be replicated over and over again, every time there are multiple places on a window that the user may be "focusing" on. Since we already have a built-in mechanism for routing events to the associated place - hotspot callbacks - I fail to see what gain there is to making focus per-window.

Nick Gammon said:
If you are writing a framework you can work out which hotspot (if any) "has the focus". Things like tab-forwards and tab-backwards, for example, really belong to the window, not the hotspot. That is, the owner (the window) is moving the focus from one sub-window (hotspot) to another. Other keys, like a help key might bring up help for the entire window, or <esc> would probably dismiss the entire window, not the hotspot.

MUSHclient -is- the framework. That's what the scripting API is. And MUSHclient is in a better position to determine where the focus is than the user, because it has more relevant information.

On another tack: if hotspots are a bad place to assign focus, where is focus assigned? Windows, yes, but windows don't have callbacks. So you propose using OnPlugin* callbacks, which are quite far removed from the location being focused.

You make good points about window-generic responses. One possibility is that a hotspot callback would simply use its specific handling first, and call a shared handler for window functionality if it didn't use anything. Another method is to let the client do this: Instead of returning control directly to the default handling when a handler returns false, just find the hotspot immediately "under" this one and see if it will handle it, repeating until there are no more hotspots or the event is handled. Both suggestions basically induce event propagation.

By the way, I'm pretty sure that this (the second suggestion) is how Javascript events work. (Actually, I'm pretty sure event handlers are per-element in the DOM, too.)

Nick Gammon said:

Twisol said:

It would be harder to create a window with multiple input areas if it was per-window, especially because windows can't be composited except as images.

I don't understand that. You could make an window of text as prompts, and rectangles for the typing into. Images don't have to come into it.

I meant that you can composite windows - like piecing together a background, an IM history widget, and a text-entry widget - using WindowImageFromWindow and then drawing them together. But then they lose their identities: they're a single window, and you have the same problem of routing events to the right place.

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol

Top

Posted by

Nick Gammon Australia (23,072 posts) Bio Forum Administrator

Date

Reply #9 on Tue 30 Nov 2010 02:39 AM (UTC)

Message

Twisol said:

(Mon 21 Dec 2009)

I seem to be unable to create 1x1 hotspots, i.e. hotspots that only affect a single pixel. I'm trying to layer a window entirely in 1x1 hotspots for fine-tuned tracking of the mouse using the below code, and for testing purposes I'm using the hotspot's ID as the tooltip text. The problem is that no tooltip appears at all, no matter where I point the mouse.

How would this work with your previous idea then? The letter "M" alone would cover around 100 hotspots. Which one would have the focus?

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Top

Posted by

Nick Gammon Australia (23,072 posts) Bio Forum Administrator

Date

Reply #10 on Tue 30 Nov 2010 02:41 AM (UTC)

Message

Twisol said:

Since we already have a built-in mechanism for routing events to the associated place - hotspot callbacks - I fail to see what gain there is to making focus per-window.

Mouse-clicks have a location. Keypresses don't.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Top

Posted by

Twisol USA (2,257 posts) Bio

Date

Reply #11 on Tue 30 Nov 2010 03:09 AM (UTC)

Amended on Tue 30 Nov 2010 03:17 AM (UTC) by Twisol

Message

Nick Gammon said:

Twisol said:

(Mon 21 Dec 2009)

I seem to be unable to create 1x1 hotspots, i.e. hotspots that only affect a single pixel. I'm trying to layer a window entirely in 1x1 hotspots for fine-tuned tracking of the mouse using the below code, and for testing purposes I'm using the hotspot's ID as the tooltip text. The problem is that no tooltip appears at all, no matter where I point the mouse.

How would this work with your previous idea then? The letter "M" alone would cover around 100 hotspots. Which one would have the focus?

There's no sensible reason to use a grid of 1x1 hotspots anymore, because we now have pixel-sensitive hotspots. And the grid was a hack anyways. I wanted to implement window composition in my widget framework: windows can be turned into images and drawn onto other windows, but hotspot information is lost. By using the pixel-sensitive hotspot I could manage virtual hotspots behind the scenes, plus implement event propagation.

Nick Gammon said:

Twisol said:

Since we already have a built-in mechanism for routing events to the associated place - hotspot callbacks - I fail to see what gain there is to making focus per-window.

Mouse-clicks have a location. Keypresses don't.

No, but key events have to go somewhere. That somewhere is the place with focus. And the place with focus usually responds in some way (likely visually) to the keypresses. It may not be visible, but it's not arbitrary.

As I mentioned, events in a web DOM are sent to the element it makes the most sense to send to. I'm writing this post in a textbox (one of a few on this page), which currently has focus (shown by a faint orange margin). There's no Javascript handler here, but the default behavior for this element is to display and record the keypresses the user makes.

It's not really very different with miniwindows. Whatever element of the window has focus gets the key events.

At any rate, what you proposed works. My personal belief is that it's not optimal. Since a similar system works so effectively elsewhere, why not use it here?

[EDIT]: I'll make a metaphor for you: The cursor is to the mouse as focus is to the keyboard. Clicks don't -really- have a location, but the cursor does. When a click occurs, the event goes to wherever the cursor is. It's the same with focus: you move the focus around, and key events go where ever it happens to be.

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol

Top

Posted by

Twisol USA (2,257 posts) Bio

Date

Reply #12 on Tue 30 Nov 2010 03:16 AM (UTC)

Amended on Tue 30 Nov 2010 03:17 AM (UTC) by Twisol

Message

Nick Gammon said:

Twisol said:

MUDs are really fun, but the various means of playing them don't measure up to games and clients in other fields. I think this would be a good way to keep MUSHclient evolving.

Hmm, I completely missed this post.

I've been to NoGFX before, and I don't see much of a "support group" there. As I understand it, it's a place to post logs. I certainly believe that text should remain an important part of MUDs, else they wouldn't be MUDs anymore. But presentation and interaction can surely progress, can't they?

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol

Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

29,917 views.

It is now over 60 days since the last post. This thread is closed. Refresh page

Go to topic: Search the forum

top