Mac OS-X Dialogs

By definition, a daemon runs in the background, disconnected from the terminal.
Most importantly, if the daemon is in the "background", and some user is logged in,
then some other application is in "foreground" - has the focus of the GUI.  If an
unrelated program throws a dialog box up over the foreground app, it is not only
considered "bad manners", but could seriously confuse the user.  It is very much
against the Macintosh Human Interface Guidelines, and typical of the worst-behaved
Windows apps.

Daemons typically log errors to system log files, usually /var/log/system.log
Consider the logger command, or the syslog library routines:

man  logger
man  syslog

Ok, let me clarify... This "Daemon" is monitoring an external device for an event and launching an app when the event is received. (Ex: pressing an extra button on a keyboard) However, should the program not exist, I want it to prompt the user to either re-install the program or contact tech support. Since the user-interaction is necessary I dont think it would be "bad manners" in this situation.

-D

Since a daemon has no foreground UI access, I suggest the following:

Since the result of the event is to launch an application, I suggest you
have a default, tiny application that you launch in the event that third-
party application is not available.

Ok, but that brings me back do dialogs, this tiny app would need to have a dialog, and this is beyond my skill set on mac.
Is there any way to just add a certain header file and a command that would pop up the dialog?

-D

khkremer,

How reliable would that be across the whole spectrum of 10.1.x to 10.3.5?

Would I just make the script and launch it using osascript? how reliable is this as well?

Thanks,
-D

We are getting so close, just so you know I'm going to increase the points and do a split since you both came up with the ideas so close to one another.

Brett,

I tried your script and it worked, but with one flaw. It does not focus the dialog, it keeps it in the bottom and bounces the Finder window, is there a way around this?

-D

Oh and the script does not close untill you press ok. (this might cause my service to hang?)

NVM, just needed an activate statement. If I compile this script on 10.3.5 will it work on 10.1.x?

-D

> I tried your script and it worked, but with one flaw. It does not focus the dialog, it keeps it in the
> bottom and bounces the Finder window, is there a way around this?

Add the command "activate" to the script to tell Finder to orderFront:
exec osascript <<\EOF
tell application "Finder"
        activate
        display dialog "My application was not found" buttons {"OK"} default button 1
end tell



> Oh and the script does not close untill you press ok. (this might cause my service to hang?)

Now you are just being lazy.  Consider using popen(), fork()+exec(), & (run script in background),
or "giving up after" parameter to the "display dialog" command.

lol you caught me on the laziness, been a loooong day, anyway.

khkremer: "The Mac is not Windows :-) This is the reason why the application is launched in the background, and not "in your face" as Windows would do it."

I would assume the user would not care since what they want to do is open the app using my button connected to the daemon. They'd be expecting the app to open, if the app doesnt open the error message should. :)

Thank you both very much.

-D

Thanks for reminding me of "activate". I never use this, mainly because it's so annoying to have to deal with this on Windows on a regular basis (I have to use Lotus Notes on Windows for email - IT's decision - and every time I receive email, a dialog window pops up, grabs focus, and needs to be dismissed... AAARRRRGGGGGHHHHH :-)

I, too, hate when a background app throws a dialog and grabs focus while I'm working.
I consider it extremely bad behaviour.  I already admonished DABOMB on this design
decision, but he seems determined to go forward with it.  He will be roundly criticized
by his users and may eventually change to a less user-antagonistic design.

Windows users are accustomed to an annoying user experience, whereas Mac users are
quite intolerant of bad program behaviour.  Windows programmers fail to realize that
porting apps to the Mac doesn't just mean learning a different set of system APIs, it
means refactoring the design to be user-centric and follow the Apple Human Interface
Guidelines.

Earlier versions of Mail.app would throw a dialog and grab focus for POP3 connection
failures.  Apple hadn't noticed because they used IMAP in-house.  I brought it to their
attention, suggested better ways to handle flakey connections, and the next release
of Mail.app had nearly all my suggestions implemented.  I was impressed.

Ok, this might be beating a dead horse... But you are telling me that you as a user, who is using my product, and presses the button which you expect to bring up an app on the screen, would not want to see the failure notice come forward, even though if the launch was successful the app itself would pop up front considering that you pressed the button this would be your current task?

-D

I wish I could select both as the answer but here is what I ended up doing with my script.

simlply 2 lines:

activate
display dialog "yada yada...

Saved as app you dont have to tell finder to do the dialog if it is it's own app. You may be right on the popup, when I run through some product eval testing with a group of mac people we will find out if it bugs them :)

Thank you both for your help, I would have never found this at all as I didnt even realize applscript still existed in OS X, I did alot of it in 9 and pretty much forgot all the syntax anyway.

Thanks. The points from this question put me over the one million mark :-)

ackkkkk..... and i'm downhere at 14000 after 5 years... lol guess i'm not very active

Very strange behavior... If I move the script away from the directory I saved it in. It doesnt work anymore...

-D

Are you using the "exec osascript" method to run the script, or did you compile the script?

compiled

now the osascript method isnt working what have i done?!\ ack, oh well.

Make sure the file has execute permissions for the current user.