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

Support incompatible applications using fallback mechanisms #8

Open
jrk opened this issue Jan 5, 2010 · 7 comments
Open

Support incompatible applications using fallback mechanisms #8

jrk opened this issue Jan 5, 2010 · 7 comments

Comments

@jrk
Copy link

jrk commented Jan 5, 2010

QuickCursor would be all the more useful if it could support more applications. The existing accessibility-based mechanism is effective for many applications, but, as noted, not some critical ones like Mail.app. Alternate methods (like simply automating copy-paste via Apple Events) would be a great fallback for some applications. An internal greylist of essential apps for which fallbacks are required would streamline this process without user intervention.

@jessegrosjean
Copy link
Owner

I agree this would be a good idea. At the moment I don't have time to do it, but I'll keep it in the back of my mind.

@jrk
Copy link
Author

jrk commented Jan 5, 2010

Indeed, I may one day find time to add this, myself—I mostly filed the request here to be official, and in case someone else got to it first.

@jessegrosjean
Copy link
Owner

Just looked into this a bit... and I think an easier approach will be to just use the accessibility api to call the "Select All", "Copy"... and then on the return "Paste" menu items. The one issue with this approach is that it will overwrite the users pastboard, but I don't really see any other approach, and I think any applescript approach would have the same issues.

@jessegrosjean
Copy link
Owner

Running into a bit of a problem. To get the data back in (paste) doesn't really work. The problem is that paste only works in an app if the app is foreground. And since the text is supposed to be written back in on every save in the external editor, that's not really possible.

@subtleGradient
Copy link

as a fallback I think it's perfectly acceptable to switch back to the originating app, paste, and then switch back. Maybe add a "Disable fallback" pref item if it annoys people.
But it'd be much better to be able to do it a little bit than to sacrifice all if it for only 1 part of it.

@subtleGradient
Copy link

Also, please don't have it do a select all unless there's no selection yet. It'd be ideal to only edit the selected text (if there is a selection)

@jaylevitt
Copy link

+1 on this, in any implementation possible. Instead of dealing with copy/paste, what about using the command-line hooks that many editors provide? You could save to a temporary file, launch a script with mate* or subl or whatever, and when it saves it, you'd have the data in /tmp.

Come to think of it, I wonder if you could generalize https://github.com/robtillotson/EditorClient, which is an ODB shim that does exactly this..

* Obviously you don't need this for TextMate, since it supports ODB, but it's an example.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants