Maccy
Maccy copied to clipboard
p0deje
Popup at input cursor
I use keyboard a lot, mouse cursor is usually far from the input cursor, so I have to look far away from the input cursor If the popup can show right under input cursor, it will be much more convenient
I think mouse cursor can be used as fallback when no input cursor
I don't think it's possible to retrieve coordinates of the input cursor position on the screen. Maybe there are some ways, but I am unaware of them. I'll be glad to merge PR which adds it though.
For now, maybe setting the popup position to the center will be more convenient for you.
It's closed source and ain't free so I can't figure out how to implement it.
According to these Stack Overflow questions, it may be possible to get the text cursor location using the accessibility API:
https://stackoverflow.com/questions/19315250/how-to-find-absolute-value-of-caret-position-in-pixels-using-cocoa-in-macos https://stackoverflow.com/questions/50214342/native-caret-position-macos-cocoa https://stackoverflow.com/questions/6544311/how-to-get-global-screen-coordinates-of-currently-selected-text-via-accessibilit
...however I'm not sure if these solutions work with the App Sandbox enabled.
I looked through the answers and the proposed solutions are far from perfect and known not to work in Mail/Safari/non-Cocoa apps. If someone is willing to spend some time playing around with them to see how they work with Sandbox, I'll happily merge a PR with the most reliable solution possible.
I think as a workaround showing at the center of currently active window is fine because text cursor must be in currently active window.
+1 for showing the popup relative to the active window because that's usually (if not always?) where you want to paste
The initial attempt to implement this via accessibility failed because App Sandbox blocks the calls, even though the app has accessibility permissions 🤷♂️ See http://www.openradar.me/10961566 for an open ticket.
In the upcoming version, there will be a "Window center" option that should pop up Maccy centered in the focused application window, falling back to the cursor when no windows can be found.
I have an implementation which works if sandboxing is disabled (Maccy needs to be manually given the accessibility permissions). https://github.com/weisJ/Maccy/tree/text-cursor
Some thoughts: It still isn't possible to make use of the accessibility api if sandboxing is enabled. However there still is a way one could go forward with this for the non-store version. The accessibility API is only needed in a single function call, which doesn't depend on any application state. Hence an option would be to have a helper process which is not sandboxed which acts as a daemon providing the result of this function. This way the non-sandboxed code only consists of a few lines. Not sure if the complexity is worth the feature.
Of course an alternative "solution" is to provide a non-sandboxed build on GitHub for people who feel comfortable using it.
Any thoughts?
Thank you for looking into this even deeper, but I don't want to differentiate between open-source and App Store versions that much. In both scenarios, providing some of the code in a non-sandboxed environment would mean that it would never be accepted in the App Store so two versions would need to be maintained. My goal was always to let people use whatever version they prefer. They could use a free one or support the project by buying the app in the App Store, but creating a deliberate difference between the two versions would defeat the goal.
I figured as much. I’m running a local build anyway so I’ll just keep my patch in the local version :)
So there might actually be an option to do this without breaking sandboxing using the InputMethodKit. See https://x.com/stephancasas/status/1751530563171741874?s=20
Not yet. I'll look into it once the follow up post with a more in depth explanation is available.