[Rwp] Plug-in hot spots

Wed Mar 9 22:08:55 EST 2016

A few comments from the HSC side.

About the fractional positioning method, I have used this before, thinking 
it was a good idea, but kept finding that it did not apply.  I dont' know 
enough to comment on the general case, world wide. But, in the applications 
I worked with, the fraction did not stay constant, as you resized the 
window.  That was especially true for  maximize, and Normal states.  For 
cases where individula borders are dragged around, who knows how that works.
So, I wrote HSC from the viewpoint that what was most likely to stay 
constant was the distance to a particular corner.  HSC will let you decide 
what corner to use as the reference.
But, I think HotSpot developers are not careful enough to look at things 
like that, and tend to just settle on what is working, given the current 
configuration, and call it good.

Similarly, HSC provides several different ways to determine which window is 
used as the reference.  top level window, The application main window, the 
window that contains the control with focus, a window identified by a 
particular set of criteria like name, control id, class etc.  Such windows 
do not need to be part of the application family tree.  And again, most 
developers I have worked with are not terribly aggressive on kicking the 
tires if the solution happens to work.  The fact is that, for a given 
configuraition, any number of those approaches will work.  Question is, 
which one keeps working. So, while HSC gives you the tools, you really need 
to dig in, and see how things change in order to find the best approach. 
Often, that is purely a question of development time, and developers are 
eager to move on, since there are usually tons of individual controls that 
need to be identified.  So, they just get in a hurry, and take the expedient 
approach.
Application main window, seems to be a very commonly used method, which is 
the worst for pluggIns.

I have been told that some PluggIn windows are actually rendered slightly 
differently invarious hosts, leading to such things as slight offsets.  I 
dont' know the root cause of that.  Conceivably, that is a jaws quirk, who 
knows which versions.  But, HSC gives you  the ability to shift hotSpots by 
a fixed offset, x and y.  That tool should allow one to correct for such 
cases.  But, what I need to do is actually take on the task of adapting a 
set some time to see how well that actually works out.  But, it's not for 
the faint of heart, and a far less manageable task for one who is not 
intimately familiar with the hotspot set.

As for screen resolution, I have been struggling for some time to really 
understand how that works.  In my experience, using standard 96DPI, screen 
resolution doesn't seem to matter.  I know that sounds surprising.  But, I 
never had any method that routed to a set of x y coordinates fail as I 
changed resolution.  It seemed like the scaling JAWS was dealing with stayed 
fixed relative to the applicaition.  What changed, as you modified the 
resolution,  is where that point actually turned up on the physical screen.
However, I am told that, with newer high-DPI settings machines, that is no 
longer the case.  But, I dont' have any experience with that.
It may well be that hotSpots defined on a 96DPI machine would not work on a 
high resolution laptop, for example.  And, it seems to depend on the 
application itself being written in a DPI-aware fashion.  But, I'm engaging 
in uninformed speculation.

----- Original Message ----- 
From: "James Teh" <jamie at nvaccess.org>
To: "Reapers Without Peepers mailing list" <rwp at bluegrasspals.com>
Sent: Tuesday, March 08, 2016 10:49 PM
Subject: [Rwp] Plug-in hot spots

> 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
> 