[Rwp] Plug-in hot spots

Wed Mar 9 22:22:09 EST 2016

I was actually reading through the HSC documentation last night 
wondering how hard it would be to port. As you say, it's an insanely 
difficult task, though it's probably easier to write in Python in some 
ways than it was in the JAWS scripting language. Also, NVDA has the 
ability to dynamically bind keyboard commands, hook into global events, 
etc., rather than having to hack jkm or jss files. Still, I suspect it'd 
take me months of work at the very least.

Jamie

On 10/03/2016 1:16 PM, Snowman wrote:
> 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
>>
>
>
> _______________________________________________
> RWP mailing list
> RWP at bluegrasspals.com
> http://bluegrasspals.com/mailman/listinfo/rwp

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