Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Popup at input cursor #150

Open
foray1010 opened this issue Aug 18, 2020 · 15 comments
Open

Popup at input cursor #150

foray1010 opened this issue Aug 18, 2020 · 15 comments
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@foray1010
Copy link

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

@p0deje p0deje added the enhancement New feature or request label Aug 24, 2020
@p0deje
Copy link
Owner

p0deje commented Sep 13, 2020

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.

@ashisherc
Copy link

much required feature 💯 I have seen copyclip2 doing this @p0deje

@p0deje
Copy link
Owner

p0deje commented Feb 8, 2021

It's closed source and ain't free so I can't figure out how to implement it.

@kthchew
Copy link
Contributor

kthchew commented Feb 25, 2021

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.

@p0deje
Copy link
Owner

p0deje commented Feb 26, 2021

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.

@p0deje p0deje changed the title Feature Request: popup at input cursor Popup at input cursor Jul 5, 2021
@wysokinskim
Copy link

wysokinskim commented Mar 23, 2022

I think as a workaround showing at the center of currently active window is fine because text cursor must be in currently active window.

@farzadmf
Copy link

farzadmf commented Apr 17, 2022

+1 for showing the popup relative to the active window because that's usually (if not always?) where you want to paste

@p0deje
Copy link
Owner

p0deje commented Aug 24, 2022

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.

@p0deje p0deje closed this as completed in 8389d02 Aug 29, 2022
@p0deje
Copy link
Owner

p0deje commented Aug 29, 2022

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.

@weisJ
Copy link
Contributor

weisJ commented Oct 16, 2023

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?

@p0deje
Copy link
Owner

p0deje commented Oct 19, 2023

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.

@weisJ
Copy link
Contributor

weisJ commented Oct 21, 2023

I figured as much. I’m running a local build anyway so I’ll just keep my patch in the local version :)

@weisJ
Copy link
Contributor

weisJ commented Feb 1, 2024

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

@p0deje
Copy link
Owner

p0deje commented Feb 2, 2024

@weisJ Have you managed to find any examples of how to do so?

@weisJ
Copy link
Contributor

weisJ commented Feb 2, 2024

Not yet. I'll look into it once the follow up post with a more in depth explanation is available.

@p0deje p0deje reopened this Feb 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

7 participants