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

OS X native app #74

Open
nomicode opened this issue Mar 15, 2014 · 4 comments
Open

OS X native app #74

nomicode opened this issue Mar 15, 2014 · 4 comments

Comments

@nomicode
Copy link
Contributor

I demoed jetzt to @janl today and he suggested that an OS X native app would be good. The general idea would be an app that could speed-read any text in any app on OS X. This would be useful for people using desktop clients, like Mail.app.

One possible possible approach would be to hook into the accessibility framework.

I appreciate that this is probably a way out, but creating this issue anyway.

@ds300
Copy link
Owner

ds300 commented Mar 15, 2014

That would be really nice. It's not something I'd want to do personally but would be happy to see it done.

@nomicode
Copy link
Contributor Author

Was talking to @janl again this morning. Perhaps there's a way to get the same JS running in both environments. Would be a shame to have to re-implement things in Objective-C.

@nomicode nomicode mentioned this issue Mar 15, 2014
@zachlatta
Copy link

I don't know if this should be an issue in this repo. Honestly sounds like an entirely separate project. I've never worked with it before, but I know https://github.com/popcorn-time/popcorn-app uses https://github.com/rogerwang/node-webkit to run on the desktop. Maybe something similar would be possible here?

@nomicode
Copy link
Contributor Author

It depends what the scope of the project is.

One option is that we say we are only building a Chrome app, and we'll leave everything else to everyone else. Another option is to say that we are primarily building a Chrome app, but that there are other options we may want to explore, and that maybe the project expands a little to work in more than one environment. I don't think there's a "right" answer here.

My personal take is that if we're building a speed-reading tool, and we have the contributors to port it to different environments, then we should embrace that. If it was just David and people were requesting he port it to environments he doesn't care about, I'd understand him summarily closing those issues. But from the looks of things so far, he seems open to this sort of thing!

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

3 participants