[Rwp] Plug-in hot spots

[alan escola]

Good morning,

I haven't much experience using hotspotclickers, etc, but I'm just
trying to deal with a htc for kontakt (with still no luck). Perhaps
I'm wrong, but as I understand as a programer, the problem is this
kind of software doesn't use window coordinates, but screen
coordinates. If it's the case, the only reason I can imagine for that,
is because the software itself has not enough complexity and is not
able to receive window sizes, dealing with the windows api, etc.
Obviously, if you want to make your hotspot solution multiplatform,
it's still more complicated, cause you have to re-write some code to
access window sizes for each operating sistem, but, well, does someone
use reaper on the mac here? Interesting question.

Minimum capabilities for a hsc would be as follows, in my opinion it needs to:
1. Move the mouse around to given coordinates.
2. Clicking, right or left button.
3. Dragging, after a button is virtually pressed.
4. Timers, to allow pauses in the workflow.
5. Audio output, screen reader friendly for anounce messages.

However, in a perfect world it could scan the screen for some
reference points, according to its colour and relative position,
calculating a patern for the current window, so, once created, each
hsc set would recalculate coordinates for different window layouts.

Just a bit of brainstorming, or brainmorning, too early here...

Have a nice day.

2016-03-09 5:49 GMT+01:00, James Teh <jamie at nvaccess.org>:
> Hi plug-in hot spot creators (HSC, AutoHotkey, whatever),
>
> As I've watched discussion about creation of hot spots for plug-ins and
> associated problems, I've been starting to wonder about why they aren't
> done in a way which makes them more reliable across different
> configurations. I don't have much experience in this area, so there may
> well be a good reason and I'm just not seeing it. So, I'd appreciate
> some thoughts on the below.
>
> In the following discussion, let's assume we're dealing with simple hot
> spots; i.e. spots which don't change such as the program browser button
> in Dimension Pro, the load button in SFZ, etc. I realise there are many
> cases where this isn't the case, but that's beyond the scope of what I'm
> getting at here.
>
> As I understand it, there are two main problems that cause basic hot
> spots to be unreliable:
>
> 1. Different screen resolutions/DPI settings. If hot spots are created
> for one screen configuration, they sometimes don't work on other
> configurations.
> I notice that even though some hot spots use relative coordinates,
> they're still absolute as far as the window is concerned. That is, they
> don't account for the window being a different size, only the window
> being in a different starting position. So, why not use width and height
> fractions? So, if the coordinate is half way across the width of the
> window, you would store 0.5 instead of an absolute value like 200. This
> way, if the window shrinks to half size, you can still calculate the
> correct coordinates. In practice, some windows probably don't resize
> everything in direct proportion, but I would have thought this would be
> more rare than not.
>
> 2. Different applications. Hot spots created for Sonar don't work in
> REAPER and vice versa. Even in REAPER, hot spots created for bridged
> don't work in non-bridged.
>  From what I've seen, even hot spots that are relative are calculated
> relative to the top level window. The problem is that the top level
> window is part of the host (e.g. REAPER), not the plug-in. That means
> it's going to be different for every host. So, why not calculate the
> coordinates relative to the window for the plug-in itself? The plug-in
> should render exactly the same way no matter where it's hosted.
> Therefore, if coordinates are all relative to the plug-in window, they
> will work the same regardless of the host used.
>
> On a related note, I'd be interested to know whether it'd be worth
> implementing some kind of basic hot spot support into OSARA. The
> question is what kind of complexity is needed for the majority of
> plug-ins. I know HSC has support for searching for colours, etc., but I
> never quite grasped how this was applied in practice.
>
> I'd appreciate any thoughts.
>
> Jamie
>
> --
> James Teh
> Executive Director, NV Access Limited
> Ph +61 7 3149 3306
> www.nvaccess.org
> Facebook: http://www.facebook.com/NVAccess
> Twitter: @NVAccess
> SIP: jamie at nvaccess.org
>
> _______________________________________________
> RWP mailing list
> RWP at bluegrasspals.com
> http://bluegrasspals.com/mailman/listinfo/rwp
>