[Rwp] Plug-in hot spots
James Teh
jamie at nvaccess.org
Wed Mar 9 06:22:12 EST 2016
The problem is that with high resolution screens growing more popular,
resolutions like 1024 x 768 are not only a little bit lower; they're
*way* lower. My system's default resolution (and it's only a 13 inch
laptop) is 1920 × 1080. Fractions allow you to simply not care about
this because as the resolution goes up, your coordinates simply scale up
in proportion.
Still, I appreciate the thoughts. Certainly, compatibility with other
tools would completely break if you do this, though that could be
mitigated somewhat by providing a facility to convert raw coordinates.
Jamie
On 9/03/2016 8:39 PM, Chris Belle wrote:
> 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
>>
>
> _______________________________________________
> 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
More information about the RWP
mailing list