Jesktop Developer Documentation
How to make Applications


First of all

Making an application compatible with Jesktop does not mean it has to only be runnable on Jesktop. It can still have the ability to run from the command line and a full "mainable" application. What we outline here is a way of coding the application so that it can run in both ways from one code base. There are a number of things you should not do, but they are easy to adjust to. Just look at how many pre-existing applications we have ported to Jesktop - it can't be that hard.


Take a look at the constraints page, to see tricks and tips for coding an application to be Jesktop compatible.

Frimble (or not)

If you need to interact with the Frame for the app, then you should inplement Frimble functionalily (still compatible with the standalone runtime environment). The the Frimble documentation. If you don't need a title, menu, close event consciousness, then JPanel is enough to extend.

applications.xml - a config file for a jar.

The app must be distibuted in a jar that contains all that is needed for the application to run inside Jesktop. This includes classes and resources. For GPL applications for legal reasons you should include the source too (as opposed to making it available on a website). The final thing that Jesktop needs is an applications.xml file that contains packaging instructions for Jesktop to pick up on as it installs applications. That file should exist inside a directory called JESKTOP-INF. This is insiped by Sun's specified standard for WAR files, with the exception that we have avoided attibutes and elements called name as they are confusing. Here is the example:

<?xml version="1.0"?>
    <display-name>Julia Set Animation</display-name>
    <display-name>Mondrian Art Thingy</display-name>
    <display-name>Warped Image Manipulator</display-name>

Shown here is the packaging for the demos that we ship with Jesktop. A display-name that will be used for presentation (TODO-internationalisation). A target-name that is used as a unique name for the app and a class to instantiate. As you can see here, it is possible to have many apps in one jar. This is as simple as it gets for the applications.xml file.

applications.xml - A more complex example

Below is the applications.xml file used for Horstscape.

<?xml version="1.0"?>
  <default-application target-name="Tools/Browsers/Commercial/HorstScape"
    <!-- <jar where="remote">jar:
                            !/HTMLWindow.jar</jar> -->
    <jar where="contained">lib/HTMLWindow.jar</jar>

This intorduces three things:

  1. default-application This is what will be launched if the jar file is double clicked in the Windows style Explorer tool. Also as attribles unde that element are the icons to use for the app.
  2. additional-jars These are the jars that Jesktop should get that are part of the application. The one that is specified there is "contained" in that it is inside the main jar. Commented out is the eperimental remote jar. This would mean that Jesktop could go and get the jar from the remote location and automatically mount it for use along side the installed application. It's commented out because of the one of the bugs that we'd like Sun to give some attention to. See Bug two on this page.
  3. application-config-file this is a config file specifically for the application. At this stage it's optional.

Application specific config file

Below is the Horstscape.xml for the application of the same name:

<?xml version="1.0"?>
  <icons icon32="horstscape/earth32.gif"
    icon16="horstscape/earth16.gif" />

It shows the gifs that can be used as icons for the app. There is no set loacation for this file within the jar.

Hosting provided by : SourceForge Logo Jesktop API SourceForge project page