Update MacOS title logic#29
Conversation
| To log current window title the teminal needs access to macOS accessibility API. | ||
| To log current window title the terminal needs access to macOS accessibility API. | ||
| This can be enabled in System Preferences > Security & Privacy > Accessibility, then add the Terminal to this list. If this is not enabled the watcher can only log current application, and not window title. | ||
|
|
There was a problem hiding this comment.
Oops, the extra changes here were due to prettier, I believe. Let me know if you want them reverted. Not sure why it would remove the trailing line...
ianobermiller
force-pushed
the
macos-window-title
branch
from
49daf00 to
73a4273
Compare
|
Ok, that took entirely too long. The issue was that I had moved the app around, and ended up with the accessibility permissions disabled. |
ghost
assigned
|
Hey, this looks great. Does it work well? I'd rather do it like this than with the |
|
One downside is that it requires MacOS Yosemite or higher. But I do agree
the JavaScript is much nicer. If we are ok with that limitation I’ll clean
this up.
…On Mon, Feb 12, 2018 at 2:20 AM Erik Bjäreholt ***@***.***> wrote:
Hey, this looks great. Does it work well? I'd rather do it like this than
with the printAppTitle.scpt
<https://github.com/ActivityWatch/aw-watcher-window/blob/master/aw_watcher_window/printAppTitle.scpt>
.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#29 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AA2ziwRSsTqsj_aDF_RA93_qpIznYgEZks5tUBBigaJpZM4SBOHJ>
.
|
|
The Yosemite limitation is fine. However, I'm curious if running it as JS would have a significant performance impact since you'll be spinning up a JS VM on every call. Would be interesting to see how it compares to the |
|
One way to reduce the load might be to keep the VM alive? I think we need to benchmark this. But yes the |
|
I am trying to understand how osascript works but then started wondering, wouldn't it be possible to find the underlying OS API call which these applescript/javascript files by using dtruss? (the mac alternative to strace) |
- Switch from the opaque scpt file to a normal JS file using JavaScript for Automation. - Grab the first window (which is the active one) and get its name as the title. This worked across all apps I tried, including Sublime, Atom, Chrome, Safari, and iTerm - Clean up the api to the macos.py file (have it return the dict directly) - Fix a typo in README
ianobermiller
force-pushed
the
macos-window-title
branch
from
2b6bfc2 to
aac4f88
Compare
|
Did some digging, it wasn't too bad to do with Python only :D |
exoji2e
left a comment
exoji2e
left a comment
There was a problem hiding this comment.
Looks great! Just some minor nitpicks :)
| cmd = ["osascript", os.path.join(os.path.dirname(os.path.realpath(__file__)), "printAppTitle.scpt")] | ||
| p = subprocess.run(cmd, stdout=PIPE) | ||
| return str(p.stdout, "utf8").strip() | ||
| app = NSWorkspace.sharedWorkspace().activeApplication() |
There was a problem hiding this comment.
activeApplication is deprecated: https://developer.apple.com/documentation/appkit/nsworkspace/1530411-activeapplication,
and is replaced by frontmostApplication: https://developer.apple.com/documentation/appkit/nsworkspace/1532097-frontmostapplication
|
|
||
| def getTitle(info) -> str: | ||
| return info.split('","')[1][:-1] | ||
| return {"appname": app_name, "title": title} |
There was a problem hiding this comment.
Not sure if it ever happens that the pid isn't found in window_list, but maybe it can occur because of realtime problems. We should probably move the return to the break, so we don't get a name-error here.
|
The Travis build is failing because the Just remove the relevant tuple from the |
|
Some more thoughts: I think However I'm guessing the most problems will occur with the binary release for macOS-users, since those might not have Xcode, not really sure what to do about that. |
|
@exoji2e It should be possible to include the right pyobjc dependency in the PyInstaller build. I remember we used something like this before, can't remember why we switched but probably worth investigating. Or maybe I just played with it when I had a macOS machine at work long ago? Can't recall. @ianobermiller Don't feel discouraged by the above. It might take a while to merge your commits, but we will do it sooner or later. If you don't have the time to look into it: just let us know and we'll build on your commits when the time comes. |
|
I have zero experience with Python installs, so it would probably be a poor
use of my time :). Let me know if there is more I can do.
…On Thu, Feb 15, 2018 at 6:51 PM Erik Bjäreholt ***@***.***> wrote:
@exoji2e <https://github.com/exoji2e> It should be possible to include
the right pyobjc dependency in the PyInstaller build.
I remember we used something like this before, can't remember why we
switched but probably worth investigating.
@ianobermiller <https://github.com/ianobermiller> Don't feel discouraged
by the above. It might take a while to merge your commits, but we will do
it sooner or later. If you don't have the time to look into it: just let us
know and we'll build on your commits when the time comes.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#29 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AA2zi97O78bW79SdX_8XCm7dPfA3Mp02ks5tVO0VgaJpZM4SBOHJ>
.
|
|
Closing, work continued in #40 |
4 participants
Fixes #28
Test Plan: