[Rwp] Plug-in hot spots

[Snowman]

Seems like I have been contacted a few times, by various parties who wanted 
to adopt HSC to NVDA.  I promise to help, as best I can.  But, they go off 
and wowrk on it, and thenI never hear from them again.  I'm not even sure 
they are still alive.  So, if you take on a challenge like that, you might 
want to buy some good life insurance first.  It apparently has it's risks.
It's a bunch of work, that's for sure.

----- Original Message ----- 
From: "Chris Belle" <cb1963 at sbcglobal.net>
To: "Reapers Without Peepers" <rwp at bluegrasspals.com>
Sent: Wednesday, March 09, 2016 4:09 AM
Subject: Re: [Rwp] Plug-in hot spots


> Haven't used that tool yet, the one I used the most is autohotkey.
> That
>  a great tool,
> but having tight integration with the screen-reader like hsc has it's 
> definite advantages.
> But these third party tools have the advantage of working even with no 
> screen-reader in place.
> Snowman's hotspot clicker tool is the most sophisticated,
> and versatile tool to date, but it's a jaws only solution.
> Kontakt does crazy stuff like leave windows open when you open other 
> stuff,
> and it covers up what you want, so you have to check for things to be 
> right when you load libraries,
> I know NVDA can do this sort of thing,
> technically, but it has to be invented.
> My vote would be to build a tool which isn't specifically tied to Osara, 
> but can be used in any NVDA thing,
> then other apps can built on it not just reaper.
> Building on the concept of golden cursor but make it be able to tell child 
> windows, and search for text, and color and do all that stuff eventually.
> A lot of work I know,
> but this would eventually make NVDA the equivalent of
> jaws and window-eyes such,
> for this sort of screen-scraping.
> I suspect with NVDA's
> abilities now, some things could probably be done with it that the big 
> guys can't do,
> once we catch up on the basic stuf.
> of just differentiating windows and such.
>
>
> On 3/9/2016 2:15 AM, Gavin Grundlingh wrote:
>> Hi,
>>
>> I created hot spots for Kontakt 5 in AutoIt, using a similar method for 
>> calculating coordinates to what Jamie used in the NVDA add-on for Sonar. 
>> So far, at least, it appears to work under very different screen 
>> resolution / DPI settings on different versions of Windows running on 
>> different machines. I calculated the coordinates according to the actual 
>> plug-in window, so the spots work for bridged and non-bridged modes, too. 
>> My next test will be to see if different hosts freak out when using the 
>> spots, or if they'll just be nice and work.
>>
>> Of course, I realise Kontakt is way, way more complex than Dimension Pro 
>> or Sfz, but I thought I'd mension my spot creation for it here to outline 
>> my methods.
>>
>> Regards,
>>
>> Gavin
>>
>>
>> On 2016-03-09 06:49, James Teh wrote:
>>> 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
>>>
>>
>> _______________________________________________
>> RWP mailing list
>> RWP at bluegrasspals.com
>> http://bluegrasspals.com/mailman/listinfo/rwp
>>
>
> _______________________________________________
> RWP mailing list
> RWP at bluegrasspals.com
> http://bluegrasspals.com/mailman/listinfo/rwp
>