I want to be able to call the automator or unix commands like ls from a mono app and ge the results back.
This can be accomplished on windows easily. The question is how is this done on the mac??
caveat: I've never written a char of mono in my life.
I imagine it's a matter of redirecting stdout and firing up a process. this linux forum shows that you can do pretty much that - OSX will behave mostly as a UNIX-like system for you, I reckon.
Oh by the way, if you want to fire up an OSX application, have a dig around inside the ".app" bundle. OSX shows these as a file, but they're actually directories. In the finder you can right-mouse click and "show package contents", or you can open up a terminal / command prompt and cd into them. For instance, you can launch the Automator like this from the terminal:
/Applications/Automator.app/Contents/MacOS/Automator
I don't know if you would want to go down this route, but if you're going to be interfacing with OSX (gui) apps, you might want to look at using Applescript as some "glue" between Mono and the app.
Related
I have a cross platform need to open a gui application programmatically, but keep it hidden from the user. Effectively, I want a command line driven interface to act as a wrapper over this gui app, and insulate the end user from seeing or interacting with it. The program is from a third party, I did not write it, and I can't edit it.
I can do this one way or another on Windows, on Linux, and (in theory) on older versions of Mac, but not the most recent ones. On Windows, I can use the native api ShellEx with a hide window parameter. It's very easy and straight forward. In Linux, I can can render a gui app to a virtual frame buffer (using xvfb).
On macOS, the open command has a --hide and --background option, but they don't have any effect (at least on this app...)
I tried changing the plist file and found that LSUIElement will hide the app from the docker, but it still shows up on the screen. LSUIPresentationMode=4 or 3 OUGHT to work for exactly this, but apparently that doesn't do anything anymore as of a few os versions ago...
I tried the approach of moving the .app off of the screen with AppleScript. That works, but you have to manually grant permissions for such a thing to occur via System Preferences. In prior versions of Mac, those permissions could be twiddled on the fly via sqlLite (so long as you had sudo rights), but now they blocked that too. You can only pull that off apparently through a process of disabling "SIP" and forcing a reboot. That is totally outside the realm of what I want.
I've tried using the xvfb approach on Mac (jumping through hoops to acquire the binary they use to include stock, and now dropped), but I'm not having luck with that. I don't think it's possible to direct a mac .app to another display is it? A .app does not render on X11 by it's nature right?
What other clever ways might there be to hide a third party app on a mac? (and that still works in most recent os versions!)
I have a Mac OS X project (a game using SDL), and for debugging purposes when not running in xcode, I'd like to open up a terminal window that I can send text to and get line input from the user.
Is there a quick way to do this that doesn't involve creating a custom window (which is slightly problematic since the game uses SDL and I don't directly create windows)?
Opening up the standard OS X terminal would be fine, or even connecting to a separate terminal process and then sending output and reading input would also be OK.
The one criteria is that it needs to work when the application is run outside of xcode, or even on machines that don't have xcode installed.
I've spent the last few hours trying to Google this, but my searches are all returning unhelpful results. I'm clearing not seaching on the right keywords.
Thanks.
Actually every app has ability to interact with console, your just need to run it in a proper way (from a terminal or console)
Locate folder with your application. For XCode you can do it in a "Project Navigator" folder "Products", then for your app in context menu press "Show in Finder". For installed application it probably will be in the folder /Applications/. Let it be, for example, /Applications/MyBigProgramm.app.
Open console or terminal make cd to your app folder /Applications/MyBigProgramm.app/Contents/MacOS
There will be an executable file of your app.
Run it from console. After it stdin and stdout will be linked to your app.
Work with stdin and stdout as you want.
UPD 1
A bit of automation.
Create applescript with the following content:
tell application "Terminal" set currentTab to do script
("/Applications/MyBigProgramm.app/Contents/MacOS/MyBigProgramm")
end tell
Save your applescript either as app or script.
Run your base application ("MyBigProgramm") by starting your applescript.
Work with stdin and stdout as you want within your base application.
Watch output in the terminal, type sth in the terminal as input to your base application.
I am having problems with a little Qt 5.0.1 program under Mac OS X 10.8.
(I have not tested any other platforms yet.)
I am launching an external Mac OS X program with this line of code:
QDesktopServices::openUrl(QUrl::fromLocalFile(fullpath));
Where fullpath contains a path to an application like:
/Users/schube/QTWorkspace/HelloWorld-build-Desktop_Qt_5_0_1_clang_64bit-Debug/HelloWorld.app/Contents/MacOS/../../../Aptus.app
(Aptus.app is a random app I've chosen, could be any app. I placed it in this path for testing purposes).
The application starts correctly but always in background; or at least, behind a Finder window. Really strange!
How can I force the new launched app to be sent to the foreground?
Use QProcess instead, but make sure that rather than using the path to the executable as the object to run, pass it to the open command as an argument. Something like this: -
QString cmd = QString("open %1").arg(fullpath); // may need QUrl::fromLocalFile(fullpath)
QProcess::startDetached(cmd);
Without using 'open', it will also open up behind other applications.
Note that you could also use the execute function, if you want to wait for the program to finish.
Also, with the open command, I think you only need to pass the path to the app bundle, rather than full path to its executable in Contents/MacOS. Either should work.
This might be a feature of the Mac OSX's window manager so that it does not steal focus.
You might need to alter your application to minimize.
I want to make an executable file (not the Mac .app bundle) which when run with a specific option (e.g. -gui) will pop up the gui.
For example, say I'm writing wget. I could do: wget www.google.com and that would print the result to the console, but if I instead do: wget -gui www.google.com that would pop up a gui window with the render of the html.
Is this possible in OS X (it is in windows)?
Note: I mean that the gui code is contained in the executable, calling open on another app is not acceptable.
Simple: Yes
Your second question will be how I guess.
Sometimes people ask me for applications that when launched by the Finder they should behave normal but when started by another process or terminal it should behave different. So, just like firefox, you can start the application the normal way or you can start it with special option.
Another way is creating agents. They are applications but don't appear in the dock and are designed to show interface elements when needed.
If you don't want to use a bundle per se you can just create a (cocoa) command line utility that loads an NSApplication when needed (depending on the command line options).
Is there any way to automatically launch an application on USB attach or CD insert on Mac OS X? it's easy on Windows, but I found that AutoRun.Inf does not work on the Mac at all.
You can't. Autostarting applications is impossible under Mac OS X.
The next-best thing, opening the CD folder and showing the installer icon, can be done by using (AutoOpen version 1.0) to make a .dmg which can then be burnt to a CD.
Basically, auto-run is considered a security problem and so is not supported in OSX. Sophie Alpert's answer is also a bit overkill. Most installers for OSX simply open up a folder to show the application and, possibly, a readme. Installing is done by dragging the app to your Applications folder.
For other kinds of apps on CDs (say, a slide show or something like that), the developer generally uses hidden folders to hide support data to ensure that the only thing the user will see when they open the CD is the single icon they're supposed to double click to start the app.
It is possible to install a background service that monitors whenever a USB device is plugged in and then launches an App. Google's "Android File Transfer Agent" is such a service that is running in the background and launches "Android File Transfer" whenever you plug in an Android device.
If you are looking for something for just yourself, you could write a small mac app that runs in the background and watches for a particular USB device (by id) to be attached and then run the program. Ideally a small XML plist could be used to map device IDs to the correct program to run. The XCode SDK has sample code that monitors for device additional and removal to get you started.
I agree with JavaCoderEx. I would crontab a task that looks for /Volumes/*/autorun.sh, then runs it once. Maybe touch a file in /tmp/ so you know its already been run, then remove it if the volume disappears.