[Home] [Downloads] [Search] [Help/forum]

Gammon Software Solutions forum

See www.mushclient.com/spam for dealing with forum spam. Please read the MUSHclient FAQ!

[Folder]  Entire forum
-> [Folder]  MUSHclient
. -> [Folder]  Suggestions
. . -> [Subject]  Hotspot "passthrough"
Home  |  Users  |  Search  |  FAQ
Username:
Register forum user name
Password:
Forgotten password?
(New message)
Subject: Hotspot "passthrough"
Name:
Your forum user name.
Register forum user name
Password:
Your forum password.
Forgotten password?
Message:
Message to be posted (in English, please).
Forum codes:
Check this if your message uses 'forum codes' or templates (auto-detected for new posts).
Forum codes Templates

Save this message ...

Subject review (reverse sequence)

Posted by Fiendish   USA  (851 posts)  [Biography] bio   Global Moderator
Date Wed 24 Apr 2013 05:07 AM (UTC)  [ quote  ]
Message
Damn. Now I want to do this too. Oh well.
http://aardwolfclientpackage.googlecode.com/
[Go to top] top
Posted by Twisol   USA  (2,230 posts)  [Biography] bio
Date Sat 27 Feb 2010 06:34 AM (UTC)  [ quote  ]
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
[Go to top] top
Posted by David Haley   USA  (3,881 posts)  [Biography] bio   Moderator
Date Sat 27 Feb 2010 06:22 AM (UTC)  [ quote  ]
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
[Go to top] top
Posted by Twisol   USA  (2,230 posts)  [Biography] bio
Date Sat 27 Feb 2010 05:24 AM (UTC)  [ quote  ]
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
[Go to top] top
Posted by Nick Gammon   Australia  (18,800 posts)  [Biography] bio   Forum Administrator
Date Sat 27 Feb 2010 05:06 AM (UTC)  [ quote  ]
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
[Go to top] top
Posted by Twisol   USA  (2,230 posts)  [Biography] bio
Date Fri 26 Feb 2010 06:09 AM (UTC)  [ quote  ]
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
[Go to top] 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.

1,744 views.

[Reply to this subject]  Reply to this subject   [New subject]  Start a new subject   [Refresh] Refresh page

Go to topic:           Search the forum

[Go to top] top

[Home]

Written by Nick Gammon - 5K

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( http://www.gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Internet Contents Rating Association (ICRA) - 2K]    [Web site powered by FutureQuest.Net]