Nick Gammon said:
You are going to have to spell out for me the difference between a plugin callback that gets mouse movements for the whole window, and a "pixel-sensitive hotspot overlaying the whole window" which gives you mouse movements. Sounds the same to me. Is there a terminology confusion here?
I meant that it covers the whole miniwindow. Your callback would be called on every mouse movement whether or not there's a window there; see my response to the next quote below.
Nick Gammon said:
I thought having a single point of reference would help, particularly as you seem to be developing a framework system. All you have to do is do what MUSHclient does itself anyway:
*Iterate through the windows (WindowList gives you that) - in reverse order, so the topmost one is considered first.
*Check the x/y coordinates to be within the miniwindow location (up to 4 integer compares)
*If not, move onto the next one
*If so, stop processing more windows (so you don't get an underneath one too), and then repeat the process for hotspots inside that miniwindow if required to identify a hotspot.
One point to make against doing it myself is that MUSHclient already does it for me. As you said, MUSHclient goes to great lengths to hide these details. (For the record, I don't count pixel-sensitive mousemoves to be an incredibly harsh detail to expose.)
Another issue is that this OnPlugin* callback will be called on every mouse movement within the output area. That means that not only do I have to do work that MUSHclient already does on its own, I also have to do it even when there might not be a window beneath the cursor. This is something MUSHclient does anyways, to pass normal mouseover events, which means we're doing the same work twice.
Lastly, unfortunately the "single frame of reference" doesn't really work out here. The framework is window-based, not plugin-based or output-window-based. Every view has its own state, though it might share descendants with other views. It is -much much much- easier to start with the view than the output window.
Nick Gammon said:
It seemed a more generic solution, somehow.
I still don't fully get why your framework can't just get the mouseover calls for individual hotspots anyway, without going down to the pixel level.
What do you mean by a "more generic solution"?
Here is how my framework works. There is one view, into which all widget canvases are compiled to get the visual elements you see. ('widgets' aren't miniwindows themselves, they are images blitted onto their parent, drawn on hidden canvas miniwindows that are never seen directly). Each widget can add their own logical hotspots, that is, Hotspot objects that are pure data. Hotspot objects have no physical presence on the view window, because it is much easier to manage them separately, and it makes it possible to resize, move, and change the behavior of them very easily.
The view, the physical area on-screen that you see, is sensitive to every movement of the mouse. It catches all events, figures out what hotspots are involved, and passes them along. It also will (not done yet) track the currently moused-over hotspot, firing a cancelmouseover when the mouse leaves its region. Because of the nature of the abstraction layer, Hotspots can be freely moved and resized (i.e. their internal rects changed) without any repercussions.
It is incredibly difficult (bordering on impossible) to literally give each Hotspot its own MUSH hotspot on the view, not least because there can be multiple views that happen to show the same widget, and it would be chaos to figure out what changes go to what view. (If you wonder when this would ever happen, it would be more likely to occur during widget composition, when you're viewing two separate widgets that happen to have the same one as a descendant further down) |
![[Previous page]](/images/thin_prev.gif){kind=small}
1
2
3 ![[Go to top]](/images/gototop.gif){kind=small}
top