Objective: installing a Dock icon. (And keeping the installer as Frontmost app.)
I used a particular technique for over 12 months. Two issues I have found:
The installer vanishes. 5, 10 or 15 seconds later I notice the installer bouncing in the Dock. ~ I wish to find a way to keep the installer window active as frontmost app during this install process.
When testing over past day or two I found the Dock on a few occasions seemed to take longer than necessary to reactivate. 5 or more minutes. On one occasion I did not think it was going to reactivate so I rebooted the computer. This might have been due to a lot of script testing and possibly having another Test Account open for same testing. I only noticed this behaviour in my main account ~ Is there something wrong with my approach?
I found a few other techniques for keeping app as frontmost app but not sure how to apply it in this case.
Edit: Removed code since it was not needed anyway as it turned out. And to remove chances of upsetting experienced scriptors by feeding the sharks. Not sure why since for the past year the menu gives them option to not have any aliases, more than I can say about many app installers. Even the app that my script will open originally installed into the dock and desktop by default. That company is now defunct.
There should be some other way, one way I have in mind, which is a kluge, is to start the app, and use clickclick and mousetools, and UIscripting, to set the properties of the icon in the dock, that would work instantanously.
I hope there is a way to accomplish this with AsObjC runner, or something.
Given the work above, killing the dock seems to be a practical way.
The Dock belongs to the user, and it’s for the user to decide what stays there, not an installer.
The defaults/quit hack is based on assumptions that can’t really be relied upon, and I wouldn’t be surprised if 10.8 has made it more fragile.
(I’m not saying there might not be the occasional case where it’s warranted, such as in labs. But if it were made easy and reliable, every software writer and his dog would implement it, and that would be a real pain.)
Should I hide the above code then? lol
The installer menu has 3 options: 1. Dock icon, 2. Desktop alias, 3. None.
3 options is the maximum I can use anyway.
I find a lot of softwares install into the dock anyway these days without asking you. I don’t like it myself. I like to choose what I want in my dock and keep a limited number of items in it. Other apps go into a 3rd party menu bar sub-menu divided into groups of app types or popular folders, etc. Other apps I don’t use much don’t get aliased at all.
I like the drop down menu because I was slow to grow out of OS 7-9 habits.
The purpose of the app that is installed is to act like an alias to another app. ie: it should be used to open the other app. The reason is explained in one of my early posts. It serves a double purpose.
I do agree with Shane about who the dock belongs to. But I see no wrong in it really, if you ask the user if he or she wants to have your app show up permanently.
Well, if you show up that dialog, after you have made your app visible in the dock, then you can have instructions for how to make it show up in dock permanently. That is a step closer at least, and within any Human Interface Guidelines. I also frown upon stuff that install into my dock unsoliticted.
Leaving an alias on the Desktop, is something I accept when I install something, though I have a problem understanding why it happens, but I accept that, as I can just delete it.
