Has a cross-platform library been developed to enable double-clicking
a document and having it open in a running java application – i.e. the windows/unix/linux
equivalent to Apple’s ApplicationListener.handleOpenFile(ApplicationEvent
ae)? The thread below from this list in Feb. 2004 suggests this may have been
done.
I see that Java WebStart’s jnlp offers similar
functionality, but my app is not a WebStart app.
Surprisingly, Sun’s JDesktop Integration Components
appear to fall short of providing this functionality.
- Larry
- Subject: Re: double-click a document
- From: Tim Boudreau <email@hidden>
- Date: Mon, 09 Feb 2004 09:38:56 +0100
size=2 width="100%"
align=center>
On Feb 9, 2004, at
2:41 AM, Greg Guerin wrote:
It can listen on a TCP/IP port, or it can advertise via Rendezvous/JmDNS,
or it could even use a named pipe (see 'man mkfifo'). The choice of
mechanism may well depend on the deployment platform.
Since the client needs no UI, it can and will launch fairly quickly. It's
not EVERY Java launch that's slow to start, only the ones that involve AWT
and/or Swing. You can demonstrate this by writing a simple UI-less Java
program and launch it with a double-clicked app-bundle. On 10.2+, the
"executable" can be a shell-script that invokes the 'java' command,
or it
can be created with this intriguing tool:
<http://www.apple.com/downloads/macosx/unix_open_source/
dropscript.html>
<http://www.mit.edu/people/wsanchez/papers/DropScript/>
If you think about it, the "listen for clients" strategy is exactly
what
the ApplicationEvent and ApplicationListener model embodies. It just does
it using a different mechanism.
I hear a cross-platform library begging to be written here (well,
whispering seductively).
What you described is exactly how NetBeans does it, with the added twist
that on startup NetBeans writes the port being used to a file, and the mini-
launcher app will read that file so one user on a multi-user machine doesn't
double click and potentially open a file in somebody else's running copy
of NetBeans.
If anyone wants, I can point you at the sources for this - most of it is
in a module called "openfile", plus a bit in the startup code - the
port in
a file mechanism doubles as a way to bring up the running copy of
the NetBeans if it's alive to ensure two copies of NetBeans don't get
started with the same settings directory (in which case they would
clobber each other's changes). It would be interesting and useful for
it to be abstracted as something non-NetBeans-specific.
-Tim