[FeatureRequest] Run script upon start of application (for type status bar)

[phloggu]

Please add the following Feature: Run the script when the application is launched (probably needed only for app type status bar).

When I start an application made with Platypus with the "status bar" UI, it does not call the script bound to the app. The script gets called after the user clicked on the status bar icon. I would like to let the script get executed already when the app gets started by the user.

For this purpose Platypus should have a new option "execute script upon start", which calls the script with an argument "start-up" or similar or maybe a configurable keyword as soon as the app created by Platypus gets executed.

(edit: removed app type droplet from request, it does not apply)

[Bill-Costa]

*> When I start an application made with Platypus with the "status bar" or "droplet" UI, it does not call the script bound to the app. The script gets called after the user clicked on the status bar icon or dropped a file to the droplet. I would like to let the script get executed already when the app gets started by the user.* I don't understand how that would work with a droplet. When the file is dropped on the icon, the Platypus wrapper app is launched, and the filespec of the dropped file is passed to your script as a command line parameter. When your script starts, it reads its command line parameters and acts on that information. So the droplet wrapper app itself is not running until a file is dropped on it. It is not continuously running in the background waiting for a file to be dropped on it. ...BC

…

-- ***@***.*** Just another geek in Northern New England, USA.

[phloggu]

It does already work with a droplet: The script gets called when the starts up. Thank you for pointing it out.
Do you see a possibility for a status bar app, did I miss something there as well?

[Bill-Costa]

*> Do you see a possibility for a status bar app, did I miss something there as well?* I have not used that particular feature of Platypus, but let's take a look at the documentation. For a status bar app, the Platypus wrapper app does the following: 1. Creates a Status Item in the menu bar when the app is launched. 2. Every time the status item is clicked, the script is executed and its text output shown line for line in a menu. 3. If a menu item is selected, the script is executed again with the title of the selected item passed as an argument to the script. So in step #2, your app is executed with no command line arguments which is the signal to your app that it needs to output a set of one or more menu lines. It sounds like what you want is a new step, let's call it "1a". What is it that you want your script to do when it is called during the initial menu setup phase? ...BC

…

-- ***@***.*** Just another geek in Northern New England, USA.

[phloggu]

My app shows predefined entries to mount a remote file system under a status bar icon. Clicking on one of them connects, resp. disconnects, when it is already connected. I would like to add a new feature to connect an entry upon start of the app. For this to work my script should be called when the app starts.

[Bill-Costa]

*> I would like to add a new feature to connect an entry upon start of the app. For this to work my script should be called when the app starts.* So to generalize, it sounds like the new feature for the "Status Menu" interface would be adding a new start-up script configuration field. When the Platypus wrapper app launches a Status Bar Item, it instantiates the status bar icon and service as before, but it would also have the option of calling a start-up script to perform some initialization task, such as starting up a daemon, before exiting. I think providing a new Status Menu Interface configuration field for the start-up script would be cleaner than requiring support for an additional calling method to invoke the current menu-handling script. For one thing the new start-up field eliminates the possibility of breaking any existing apps using the original interface for apps of this type. Another consideration is that the logic for the start-ip may be very different from the menu handling logic, so the ability to have two different scripts allows for a better separation of concerns. But at the same time, there is nothing to prevent the developer from using the same script for both the start-up and menu-handling. The developer is free to use whatever command line options or parameter values to invoke the special start-up mode, using that exclusively within the start-up configuration field. Sounds like a plausible and potentially worthwhile use case. But being unfamiliar with the Platypus code base, I have no idea how complicated it would be to add such a feature. In particular I don't know if having to now support two scripts for an app, instead of just one, would be problematic for the package building phase. ...BC

…

-- ***@***.*** Just another geek in Northern New England, USA.