So, CGSessionCop圜urrentDictionary is going to get the same values. Now, what if you've ssh'd into a Mac, and you're also currently logged into that Mac's GUI console (as the same user)? In that case, your ssh login session can communicate with the console login session in exactly the same way that a local Terminal login session would. Or, turning it into a one-liner you can put directly in a shell script: python -c 'import sys,Quartz d=Quartz.CGSessionCop圜urrentDictionary() sys.exit(d and d.get("CGSSessionScreenIsLocked", 0) = 0 and d.get("kCGSSessionOnConsoleKey", 0) = 1)' So, this should give you what you want: #!/usr/bin/pythonĭ=Quartz.CGSessionCop圜urrentDictionary()ĭ.get("CGSSessionScreenIsLocked", 0) = 0 andĭ.get("kCGSSessionOnConsoleKey", 0) = 1) But if you're looking for "don't try to display a dialog because the user will have to unlock the screen first", both of those cases mean "don't display a dialog". And I'm not sure if there's a way to distinguish between these cases. In that case, either you've put the screens to sleep and locked them, or someone else has taken the console and locked the screens (with or without putting them to sleep). The one problem case is where kCGSSessionOnConsoleKey is 0 (or missing) and CGSSessionScreenIsLocked is 1. If the dictionary has CGSSessionScreenIsLocked = 1, the screens are locked.If the dictionary has kCGSSessionOnConsoleKey = 0, or not present, either your GUI session doesn't own the console, or the console's screens are asleep.If you get nothing back, then you don't have a UI session.Here's an example using Python: #!/usr/bin/pythonĭ = Quartz.CGSessionCop圜urrentDictionary() However, you can use your favorite bridge (PyObjC, MacRuby, ASOC, etc.) to call it indirectly. There's no direct way to call this from bash or AppleScript. This is the only mechanism I know of that works for all OS's from 10.5 (actually 10.3) to 10.8 (but that doesn't mean it's the only one there actually is…). If you don't have a GUI session (e.g., because you're running in an ssh shell), or your session doesn't own the console (e.g., because someone has fast-user-switched you out), you won't be able to get this information, but you will at least be able to detect those cases. IIRC, on Lion, by default, neither one will ever lock the screen-but if you leave the screen asleep for longer than the time set in Security & Privacy, that will lock it.Īnyway, the API CGSessionCop圜urrentDictionary allows you to get information about both screen sleep and screen lock, for your GUI session. Depending on your other settings, this may also entail locking the screen, but that's a separate issue. Both Shift+Control+Eject and Energy Saver put the screens to sleep, which isn't the same thing as locking them. First, there's a bit of confusion in your question.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |