[Rwp] Plug-in hot spots

[Chris Belle]

Here's my thinking.
If there's a compelling reason to go to fractions then we should, but 
right now jaws and window-eyes use cordinates which you can easily look 
at and translate say you want to re-produce
the hard work
of an hsc guy,k you can look in the file and say ok, the load button for 
sfz is 193,86
relative to the child window cordinates.
So that's easy to do, and it doesn't seem child windows resize that much 
or if they do those cordinates seem to always work,
maybe they stay relatively the same in ahk and hsc,
that no matter how the windows shrink or grow the cordinate amounts stay 
the same.
At least it seems to do so in sonar.
I don't know how they're pulling this trick off,
because I change display sizes and it doesn't usually break the hsc sets.
But if it does, then the bottom number seems to be more critical,
like 1024 by 768
if you change the 768 it breaks more hsc sets.
But that's the whole screen, the numbers of pixels across and down a 
child window seem to stay the same.
Anway it's easy to see what been done, and if we stay compatible with 
other tools doing this already, then we can share a lot more and not 
re-envent the wheel, unless there's a good reason to do so.
Just thoughts,
both jaws and window-eyes can use cordinate related to other windows 
than just the child window,
and maybe we could take advantage of NVDA's object nav and use container 
edges when they're available, and other stuff to zoom in on stuff even more.
With the jaws version there are lots of criteria you can use,
but like I said, even though I've done some hsc dev, the tool I am most 
familiar with is auto hot key.
It uses the title window you are working with,
and it can defferentiate between the parent and child windows
where it can fall down is when you need to drill down further than that 
and say you have different windows that open up in a child window say 
for instance sessindrummer 3 has a drumkit page and
a mixer page, but both have the same title window.
I hacked around it in autohotkey,
which can use hot strings and so doesn't limit the number of hotkeys you 
can use,
but I ran out of hotkeys in the jaws vesion and tried to make another 
hsc set for the mixer window but I had to hard-wire manually loading 
that set since the title windows were the same.
Hsc has come a ways since i did that a few years ago, but being able to 
designate a certain conrol or string, or something to say, hey, this set 
of controls is active now, use this set of commands and ignore those  
others,
  I hope I'm making sense.


On 3/9/2016 4:14 AM, Chris Belle wrote:
> I meant the plug-in window.
> Not the application main window.
> Yes, we need to zero in on the closest container,
> for some reason I was thinking hot spot clicker called the top level 
> window the child window,
> but yeh, when I made my sfz ahk thing for reaper years ago I did it 
> for the
> window opening up in a separate window, and the sfz window title.
> Like it's supposed to be.
>
>
> On 3/9/2016 3:59 AM, James Teh wrote:
>> My point is that the top level window isn't good enough. That's why 
>> it breaks when you use a different host or change bridging modes. The 
>> plug-in itself has a window beneath the top level window and I'm 
>> arguing that coordinates should be based off that window, not the top 
>> level.
>>
>> As for fractions being difficult for humans, that's certainly true, 
>> but I'm imagining a tool would calculate this for you. This is done 
>> already to some extent with HSC.
>>
>> Sent from a mobile device
>>
>>> On 9 Mar 2016, at 5:18 PM, Chris Belle <cb1963 at sbcglobal.net> wrote:
>>>
>>> Hey Jamie,
>>> You are right, I am not the top dog developer of the pack,
>>> but I have used both hsc, and ahk and also hotspots from window-eyes
>>> and golden cursor and I can see the differences in each method.
>>> You definitely want that top level window going on,
>>> hsc can slice it any way you want to,
>>> with lots of criteria for determining cordinates, but the most 
>>> common used is the plug-in name, or immediate application name.
>>> And yes, doing it with the plug in a separate windows is best.
>>> When I did my spots for golden cursor I was racking my brain on how 
>>> to make the plug express in a separate window, I have done this 
>>> before as I made the ahk script for sfz a while back for reaper, but 
>>> I'll be darned if I can remember where that setting is, maybe it's 
>>> not there anymore.\
>>> I look in vst and compatibility, and plug-ins,
>>> but I can't find that open plug in a separate process anymore.
>>> Huh, it's hell getting old,
>>> but anyway, I did the best I could,
>>> but the way I did it depends on the limits of golden cursor which 
>>> can only ping the main application,
>>> so if the plug moves around, or changes some how, it won't account 
>>> for that.
>>> But Rome wasn't built in a day,
>>> we got to start someplace right?
>>> I think a good first move would be to have that top level window 
>>> name and I think it will be easier for folks to remember cordinates 
>>> when programming instead of fractions, that seems to be the way 
>>> everyone else does it,
>>> going by the top left corner,
>>> of the window, other wise, you'd have things like what the heck 600 
>>> by 800, and I'm at 125,136 what the heck is the fraction for that?
>>> Maybe some sort of way to auto-resize,
>>> anyway, people with higher pay grades than me can figure out the 
>>> inner gears of this stuf,
>>> I can squeeze the oil can, and turn a screw driver, and wipe a rag, 
>>> but someone else will have to build the engine from the whole frame 
>>> 'grin'.
>>> Thank you for your attention to this, one final thought,
>>> I think hsc and ahk do searches by color and such from matching 
>>> patterns, and they set restrictinss on how far to search up and 
>>> down, it can get terribly complicated,
>>> but for us just having basic find me here in this location will be a 
>>> great start.
>>>
>>>
>>>> On 3/8/2016 10:49 PM, 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
>