The point of my original post was not really to just display a message. I want to be able to run an AS script or applet in a given space, while the script is starting with a complex dialog box to govern the script’s tasks. The script should be able to switch to a space and then display the starting dialog. My original dialog was just a simple example (and so I thought was your even simpler dialog) to graft the space switching code in front of it. The question is about the possibility of scripted space switching and displaying an AS dialog. Unless I miss something in what you say here, I can’t see how a notification message can help me interact with a script (I must confess that I’m not a big fan of being disrupted by all sorts of notifications - other then problem alerts, so I still have to be convinced of the usefulness of their proliferation).
I could settle on the “semi-hack” combination of McUsr’s and my ideas. It works for my main display with one space on it. It is probably possible to adapt it for other spaces as well, but with no space switching capability.
Wow, it just occurred to me that I may be able to graft your switching technic in front of our “hack”; it may just work.
Your idea on the other hand, looks much more professional and versatile. I think that you script at #18 seems to be almost there. What do you think about my idea to add the System Events clicking in the switched space? Is that possible?
on run
activate me
display dialog "hello"
quit
end run
I don’t know why but a non-stay open doesn’t work the same. Here’s the script to run it:
-- switch to desktop 1 with ^1
tell application "System Events"
key code 18 using control down
end tell
delay 2
tell application "LaunchTest1"
launch
activate
end tell
delay 5
-- go back to desktop 5 with ^5
tell application "System Events"
key code 23 using control down
end tell
Just that one thing did it!
Edited: darn that doesn’t jump to desktop 1 when you click on it in the dock. Also, it doesn’t matter if it’s stay open or not. The one thing that it does is that the dialog stays in desktop 1. Back to the drawing board.
Success! There is a workaround. Add a reopen handler to your applet.
on run
activate me
display dialog "hello"
quit
end run
on reopen
-- switch to desktop 1 with ^1
tell application "System Events"
key code 18 using control down
end tell
end reopen
It works !!! This is really a very elegant solution Added 2nd caveat: There are two caveats for using this solution;
The applet must be assigned to the desktop it is supposed to switch to and display the dialog on, in this case desktop 1 on display 1.
The applet must also be enabled in System Preferences > Security & Privacy > Accessibility.
To sum up, the dialog is always displayed on desktop 1 (in this example), regardless:
if desktop 1 is not visible (covered by another desktop), then the applet switches to desktop 1 and displays the dialog on it;
if desktop 1 is visible on display 1 but not in focus (the focus is on a space on another display), then the applet just opens the dialog on the desktop 1.
This is exactly what I wanted
It solves two problems in Mavericks:
Scripted space switching, and
Forces an AS applet to open on the desktop it is assigned to (IMHO, a good workaround a bug in 10.9 when assigning apps to spaces)
I think I might add something like this to the Library. It just allows you to jump to up to 10 spaces if ever needed:
-- DesktopLib
-- digits 1 to 0
property key_codes : {18, 19, 20, 21, 23, 22, 26, 28, 25, 29}
on run {n}
set warp_kc to item n of key_codes
-- switch to desktop n with ^n
tell application "System Events"
key code warp_kc using control down
end tell
return true
end run
I called that compiled script with this:
set script_path to ((path to desktop as string) & "SpaceWarp.scpt")
run script file script_path with parameters {10}
10 shortcuts need to be checked in the Keyboard preferences.
I deleted the last posts because they were off the mark. With regards to caveat 1, That’s what the workaround is for. There might be a way to solve caveat 2.
Think I might have found a workaround for caveat two. If you set up an app as having access, then you change that app or parts of it. Wonder if that would work.
No problem with your deleted post. Just a bit of fun. I was just replying when you deleted it
Regarding the first caveat, I tried it initially without it, but the dialog kept stubbornly appearing on the space in focus. As soon as I assigned it to desktop 1 it is rock solid in always displaying the dialog on the target space. I think that the workaround just made that possible. I give you even higher marks for coming up with this solution without having a 2nd display to test it
Regarding the second caveat, I don’t think that it can be avoided because of the per-app security implemented in Mavericks. Any applet using UI scripting will require enabling. Anyway, I don’t think it is a big deal, it is easy - if its necessary, the system will prompt you to enable the applet and redirects you to the Sys Prefs (and it did in my case).
IMHO, both caveats are really easy to comply with, but any comments or “caveat avoidance” solutions are welcome.
Just thought of a great idea! You know when you want to change spaces and want to do it with one hand. The control key is too far away for one hand. So, I was thinking that you enter a set into the function keys. f1 thru f0. Then, you can switch spaces with one hand.
Good luck with that. I’m really curious if Apple will let go around the UI scripting issue
But if you do it successfully, there will be no problem to cancel the enabling. Just delete the enabled applet, log out and in or reboot (that will clear the applet from the enabled list) and then open the updated script and save it as an app again. If the system thinks that enabling is not required, it will let it run as a normal app.
Please no. That would be a show stopper if I’d have to enter a password each time I run the applet.
Enabling the applet based on the current solution is to me a no-brainer do-it-once-and-forget.
I think you should change the bundle name and bundle identifier for each of the applets that you assign to different spaces. If for no other reason than being coherent with Apples assumptions about applets.
Try swapping the caps lock key and the control key, then you can reach ctrl-1 to ctrl-6 without problems with your left hand. Your keyboard becomes much nicer to type with as well, as a side-effect.
Hi,
The first applet I already updated and tested, runs only in space 1, so I kept the name. A second one I’m thinking about is likely to run in two maybe three spaces. There I will simply append “s2” … to the name, corresponding to the space number.
I can easily reach ctrl-1 to ctrl-5 with one hand for the number of space I have for the time being. But I point to my comment at #37. I do whatever I can to avoid typing
