One way to tell how the app was launched is to look at its parent
process. It will be loginwindow if started as a login item and either
Dock, Finder, SystemUIServer, etc. if the user started it somehow.
This won't work though if your app is a JAR file (ie - haven't used
JarBundler). Because then the parent process would be Jar Bundler.
Adam Ohren
email@hidden
"God does not play dice."
-- Albert Einstein
On Jul 23, 2007, at 2:20 PM, Nicolae Cismaru wrote:
But the problem now is different. How will I know if the
application is started automatically at
log in and not explicitly by the user?
- If the application is started automatically and the Hide key is
set to true, the splash and main
window will not be displayed.
- If it is started by the user, they must be displayed
Nicu
--- Greg Guerin <email@hidden> wrote:
In the loginwindow.plist, add the key/value
<key>Hide</key>
<true/>
Or is there something else?
There isn't, AFAIK.
The state of Hide is user-controllable. The initial state can be
preset by
the application, but it should remain user-controllable, and not
be forced
by the application. See System Preferences > Accounts > Login
Items tab
(the tab is Startup Items on 10.3). It's the Hidden checkbox.
If the app has to do something by itself based on the state of
Hide, it
should get the state by itself. Think of it as an external global
variable. There are several ways of getting its value.
One way is to exec() the command 'defaults read loginwindow
AutoLaunchedApplicationDictionary' and parse the resulting text to
get the
value of interest.
The login items dictionary is also accessible by AppleScript. See
the
Login Items Suite of System Events.app, and exec() the 'osascript'
command
from Java. This also requires parsing the resulting text.
One could also use the XML DOM to parse loginwindow.plist, then
walk the
tree to examine the Node of interest.
Of these, the XML DOM is probably simplest for a Java program,
just because
you don't have to write any parsing code. You still have to do the
decoding, but that's probably simpler than writing a parser, IMO.
One last thing: any plist file can be stored in XML or in binary-
plist
format. There is no guarantee which one it will be at any point.
The
'plutil' command can convert a plist to XML, which should occur
before XML
parsing is attempted. Read 'man plutil', and see its -convert
xml1 and -o
options in particular.
-- GG
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/java-dev/nicolae.cismaru%
40yahoo.com
This email sent to email@hidden
______________________________________________________________________
______________
Pinpoint customers who are looking for what you sell. http://searchmarketing.yahoo.com/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/java-dev/email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
This email sent to email@hidden
