search

asmagill / hs._asm.axuielement

Accessing Accessibility Objects with Hammerspoon
33 stars 2 forks source link

Feature Request - Last Count #3

Closed latenitefilms closed 6 years ago

latenitefilms commented 7 years ago

The _count key in searchPath is really handy. However, it would be really great if you could tell it to use the "last" item. For example, I have a case where there might be one or two scrollbars depending on the UI configuration - but I always want to grab the last one. As far as I can tell, there's currently no easy way to do this with searchPath. Thoughts?

asmagill commented 7 years ago

I haven't review the code again yet, I plan to do that tomorrow, but your comment reminded me...

Something that always kind of bothered me about _count was that it was in effect skipping elements in its search... for example, if we have a table of { 1, 2, 3, 4, 5, 6 }, then a _count of 2 would mean that it would first check 2, then check 4, then check 6... and I don't recall if it would actually wrap and catch the others if we're still missing the required element...

What I think I should do is remove _count and switch to the following keys: _increment -- replaces _count and indicates how many to skip after a check fails (defaults to 1) _startAt -- specifies which index to start at, but if that fails increment by _increment. If startAt is negative, start from the end of the list, so -1 means the last element, -2, the second to last, etc. This negative indexing is consistent with Lua's string position functions. (defaults to 1) _wrap -- specifies whether or not the iteration should wrap around and catch missed possibilities if all other paths have failed so far. (defaults to false? not sure... which is preferable - a fast fail or a slow success? both indicate that you need to re-work the query, but which would be better during trial-and-error testing?)

To truly replicate what I think I remember_count as doing, you would set _startAt = n and _increment = n.

Note that these are all predicated on the idea that we're having to search... as you suggest in the other thread, there also needs to be a way to specify "absolute paths" for at least part of the query.

At any rate, your thoughts? I hope to work on this again tomorrow, so hopefully there will be something to test in a couple of days. I will try to maintain backwards compatibility as much as possible (probably putting these additions into a new function so the old ones continue to work), but at some point, when this gets reliable and fast enough to add to the core, I'll probably cull the slowest and least useful portions to make it a more manageable size.

latenitefilms commented 7 years ago

To be perfectly honest, even though I've read through your Exploring and Crafting Queries for hs._asm.axuielement document quite a few times, I still don't think I fully have my head around it. I still don't really understand how patterns work - for example:

{ role = "TabGroup$", _pattern = true }

...and this also confuses me:

{ role = "AXGroup", _id = 1 }, -- any key which starts with _ won't affect the actual
{ role = "AXGroup", _id = 2 }, -- criteria matching, but will show up in the logs

I just ASSUMED that if I used:

{ role = "AXGroup", _id = 1 }

...it would "select" the first AXGroup, but I don't think that's actually the case?

Regardless... For me, the most important thing is SPEED. I'm happy to spend a lot of time carefully crafting the GUI Scripting code, if it will run as quick as possible for the end-user. Unlike most Hammerspoon developers, I'm not really making the Hammerspoon script for MYSELF - I'm trying to basically write a script that acts as "normal software" that anyone can use.

Does that make sense? Any questions let me know!

Thanks SO MUCH for all your on-going help, support, and serious brain-power.

asmagill commented 7 years ago 
{ role = "AXGroup", _id = 1 }

The _id field is ignored for the actual search -- it is just there to show up when logging is enabled so you can see which entry (if many look similar) was tested.

What { role = "AXGroup" } does is search for the next AXUIElement which has the "AXGroup" role from the current location.

latenitefilms commented 7 years ago

@asmagill - No worries - yes, that all makes sense after reading your Queries documentation properly. However, it would be great to have something like _forceid = 1 so that it will always pick the first AXGroup, for example.