Overall, I wonder if we should push that much into Robot keywords, rather than directly into the library?
I mean, a lot of the keywords in the .resource are implementation details, I would say we should limit the API surface to things we actually want exposed to the procedure.
Like, Get Pointer Position wouldn't even be needed if Walk… was implemented in the library. WDYT?
Realized there's at least one reason why some of those keywords actually fit into a resource… and that's combining functionality from multiple libraries (like Move To ${template}, Walk To ${template}). Don't think we necessarily want WaylandHid to hard-depend on Screencopy, but rather on its interface. Say we want to introduce a VNC client to read the frames.
I suppose it could be done through library arguments somehow, but not sure it's worth it. And any case, not this PR.
Overall, I wonder if we should push that much into Robot keywords, rather than directly into the library?
I mean, a lot of the keywords in the
.resource
are implementation details, I would say we should limit the API surface to things we actually want exposed to the procedure.Like,
Get Pointer Position
wouldn't even be needed ifWalk…
was implemented in the library. WDYT?Originally posted by @Saviq in https://github.com/canonical/mir-ci/pull/99#pullrequestreview-1895192387