On Tuesday 03 April 2007 13:31:19 Michael Hall wrote:
But yes what I was thinking was roughly as you indicate. Normal
threading on the initial launch. That handles the OS X events and
then starts a jvm with the SWT required thread options running the
actual application code, also passing it the OS X event information
as parameters.
I tried this, it seems to work (I haven't tested it fully) however,
there is
one significant problem: I end up with two running application
icons, one for
the loader, and one for the actual application. What I'd ideally
like is just
the one for the launcher, and the real app doesn't have one (so
that it looks
like there's one program, even though there are two running). Of
course, it
would have to behave like the icon belonged to the real app.
I do this same sort of launch for a application of my own. http://
users.spacestar.net/mikehall/javasrc.html#combined
Similar anyhow, I use the Jakarta commons 'ant' based launcher code
for the first launch. I ran into the same problem, you could probably
find it in archives somewhere. Possibly some use of LSUIElement might
help you. I think what I ended up doing though was changing the first
launch to be Unix script...
<key>CFBundleExecutable</key>
<string>Prelude</string>
The problem there being I think that if the OS X events you are
interested in are open document ones, they will not be received... http://users.spacestar.net/mikehall/javasrc.html#odoc
If anyone else has found any of this incorrect please let me know.
I can't have the loader terminate immediately after launching the
SWT app, as
then I'll lose the ability to have associated documents opened when
the
program is already running (which is a very significant use case
for this
program).
What you could do is have the launcher run off of it's own thread
that just idles but includes the event handler. I actually just wrote
code to do this. The sole contents so far of my app Toolkit. (To keep
it away from my messier, already does too many things appedit stuff).
But the codes pretty much simple enough to snippet into the post so
something like...
public IdleApp() {
t = new Thread(this);
t.start();
addApplicationListener(new ApplicationAdapter() {
public void handleOpenFile(ApplicationEvent e) {
String filename = e.getFilename();
try {
if (filename.endsWith(".jupd"))
new PlistUpdater(filename).start();
}
catch (Exception ex) { ex.printStackTrace(); }
}
public void handleQuit(ApplicationEvent e) {
System.exit(0);
}
});
}
public void run() {
for (;;) {
synchronized(this) {
try { wait(60000); }
catch (InterruptedException iex) {}
}
}
}
Although then you would have to have some communication between the
launching and application tasks. Something simple might be to feed
open document file names to the application through it's System.in.
What I'd be really happy to have happen is just get the file that
was double
clicked as a command line argument to a new instance, and then
handle it
myself. Hmm, it is possible to tell OSX that you are happy to have
multiple
instances, and the java stub that you want things on the command
line? I
haven't seen any mention of it anywhere, but maybe it's hiding from
me :)
We all have our wish lists. Someone mentioned having their own native
JNI JavaApplicationStub code. Seems like this would be good
functionality for that. They did not mention that it was open
sourced. When you introduce double-click files there are things that
are OS dependent things that are more difficult to handle with what
is supposed to be my more 'pure java' approach.
I just tested Azureus (torrent downloader, uses SWT also) and it is
somehow
able to work just fine. However, I had a look through its source
code, and I
have no idea how.
It seems then there might be a solution to the threading problem
after all? Without looking I'm not sure what it would be either.
Maybe someone else on the list might still have suggestions there.
_______________________________________________
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
