Added a (very) basic tree walking functionality for Mac #49
Conversation
lib/mac/mac_inspect.i
Outdated
|
|
||
| %include <std_unique_ptr.i> | ||
| %unique_ptr(mac_inspect::AXAPINode) | ||
|
|
There was a problem hiding this comment.
wow was this move necessary to get this to work? you mentioned you were having trouble with the shared pointer
There was a problem hiding this comment.
Hmmm, I thought it was, but I just moved it back, and it still worked. It looks like the actual fix was prefixing AXAPINode with mac_inspect:: in the %unique_ptr macro.
| chars = ns_chars ? ns_chars : ""; | ||
| } | ||
| return std::string(chars); | ||
| } | ||
|
|
||
| AXAPINode::AXAPINode(AXUIElementRef ax_element) : ax_element_(ax_element) {} | ||
| AXAPINode::AXAPINode(AXUIElementRef ax_ui_element) | ||
| : ax_ui_element_(ax_ui_element) {} |
There was a problem hiding this comment.
just curious the motivation for this name change?
There was a problem hiding this comment.
Just making it match the platform type name more closely, because I was confusing myself :)
| (AXUIElementRef)CFArrayGetValueAtIndex(children_ref, index); | ||
| if (!child_ref) | ||
| return nullptr; | ||
| return AXAPINodePtr(new AXAPINode(child_ref)); |
There was a problem hiding this comment.
So I think all of these helper functions, ultimately, might only be implemented in AxapiNodeImpl, like the AtspiNodeImpl: https://github.com/Igalia/AXAccess/pull/43/files#diff-3d31a27d5b501604330a8b1dd58434d1a6848428ec6b28afdefc85002e1e439b
And ultimately a goal for the test suite is to surface AXUIElementCopyAttributeValue almost directly, in order to test?
I wonder if the next step is to for you to copy the outline presented in Edu's PR?
There was a problem hiding this comment.
Also I wonder if "GetChildCount" and "GetChildAt" are the right abstractions for the "cross platform" part of the API.
There was a problem hiding this comment.
[...] And ultimately a goal for the test suite is to surface
AXUIElementCopyAttributeValuealmost directly, in order to test?
Yeah, makes sense!
I wonder if the next step is to for you to copy the outline presented in Edu's PR?
Yeah, once that change lands I can work on making the Mac version of NodeImpl, moving these functions over there and making this a much thinner wrapper around the Mac APIs.
Also I wonder if "GetChildCount" and "GetChildAt" are the right abstractions for the "cross platform" part of the API.
Yeah, good question. Do you think potentially returning a std::vector<NodePtr> might be more ergonomic?
There was a problem hiding this comment.
It just seems to make more sense from a scripting language perspective. We can change it at a future time!
No description provided.