Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.

Due to spam on this forum, all posts now need moderator approval.

 Entire forum ➜ MUSHclient ➜ Suggestions ➜ Hotspot "passthrough"

Hotspot "passthrough"

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 Fri 26 Feb 2010 06:09 AM (UTC)
Message
Minor suggestion: if a hotspot callback returns false, continue looking for other hotspots to call as well (which may be in other miniwindows logically "beneath" the hotspot). It would be the hotspot equivalent of a trigger's "keep evaluating" option, allowing you to layer hotspots that do different things on top of each-other without causing conflicts. A silly but plausible example use could be a window/hotspot that "follows" the mouse without blocking mouse input on other windows. Coupled with a pixel-precision hotspot, one could also create hotspots with "holes" in them.

I think it's a more general and more functional alternative to (a) miniwindows flagged as not accepting mouse events, and (b) perhaps OnPluginMouseMoved as well, though of course they would still be available.


I'll explain my motives for suggesting this, but please note that I do believe they have uses outside my own personal goals. I also have to give a bit of backstory as to how I got here.

I've been brainstorming my widget framework lately, mostly about how my event system works (or doesn't, as the case may be). I had the idea of dropping the View construct - visible widgets had to be the child of a movable View - and simply extending the widget composition technique to the whole output window. That is, visible widgets would be children of a MainWindow object.

This simplifies a lot of things, and also gives a definite place for system events to "spawn" from, which was one of my annoyances previously: there was no "good" way to tell whether you wanted to listen to a system event on a widget, or a user-created event. But the new approach would make system events identical to user widgets, except that they come from MainWindow.

Anyways, I also need a good way to actually manage MainWindow's children. The approach I first favoured was just maintaining a single visible window for each child, but it felt immensely clunky the more I thought about it. It was hardly any better than simply keeping separate Views; The other approach, that I didn't really want to take, was covering the output window with one big miniwindow and just blitting each child to it on redraw.

The more I've thought about it, the more I think this approach is the better one. It feels so much cleaner implementation-wise - though I must stress that so far everything is just a thought experiment. The two main problems I face are: (1) the main window must not hide anything below it, and (2) the main window must not block mouse events from anything below it. I think I can manage (1) with some creative use of transparency, but (2) is insurmountable as far as I can tell.

And now I've come full circle. This is why I'd like a "passthrough", or "keep evaluating" functionality for hotspot callbacks. From what I know, it's not a major change or addition, just a matter of checking a return value and continuing the search. Of course, I could be wrong: I've still barely touched the MUSHclient source in its entirety.


As a final note on the behavior of such a feature, certain hotspot callbacks would naturally be excluded from this keep-evaluating functionality. Specifically, the callbacks that rely on a previous stimulus on a specific hotspot: cancelmousedown/mouseup both rely on a mouse action on a specific hotspot, as do dragmove/dragrelease and cancelmouseover. Hence, I suppose mouseover and mousedown are the only two affected.

Now that I think about it, mouseover is pretty central, as it marks which miniwindow the mouse is over. I would suggest that if all hotspots on a given miniwindow return false to a mouseover, that miniwindow not be counted as moused over at all. At this point I think it's just a change in algorithm, I don't think any extra state variables would be required.


Now... if you happen to agree with this suggestion, I'd be happy to look into implementing it. And I'm sorry for the long post, tl;dr much?

'Soludra' on Achaea

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

Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #1 on Sat 27 Feb 2010 05:06 AM (UTC)
Message
I think you are over-thinking this.

I have just done my mapper plugin, my health bar plugin, my XP plugin, and previously an inventory plugin, and have never found any need for this functionality.

- Nick Gammon

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

Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #2 on Sat 27 Feb 2010 05:24 AM (UTC)
Message
Well, I've given my logic and rationale for suggesting this idea. What alternatives might you suggest?

It's also worth pointing out that my project is completely different from your recent miniwindow plugins. I'm trying to create a modular widget-based miniwindow framework, whereas you can tailor-fit the code to your purposes.

'Soludra' on Achaea

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

Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #3 on Sat 27 Feb 2010 06:22 AM (UTC)
Message
I also think there's a pretty big difference between information-display windows, and windows that are meant to be highly interactive with controls like scroll bars, buttons, and so forth.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top

Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #4 on Sat 27 Feb 2010 06:34 AM (UTC)
Message
Yes... now, if you think this is bad, wait until you see the key-event proposal I've been working on.

'Soludra' on Achaea

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

Posted by Fiendish   USA  (2,534 posts)  Bio   Global Moderator
Date Reply #5 on Wed 24 Apr 2013 05:07 AM (UTC)
Message
Damn. Now I want to do this too. Oh well.

https://github.com/fiendish/aardwolfclientpackage
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.


20,146 views.

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

Go to topic:           Search the forum


[Go to top] top

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.