Note: These pages are being reviewed.
How does the declarative XML API for the window system work?
The API is not hard, just a bit baroque.
On startup, the window system needs to know some things to construct the main window, and possibly restore the state it was in before shutdown:
The window system needs know what components it will be displaying
It needs to know where to display individual components
And it has a way to define places where components can be displayed, and needs to know what places have been defined
It would be a disaster for performance if all possible components in the system had to be instantiated/deserialized during startup just to figure out if they actually need to be on screen. The XML definitions for window system components allow a module to completely declaratively provide all the information described above.
There are three main file types to be concerned with - these are put in the System Filesystem by declaring them in your module’s layer file:
.settings files- representing TopComponents that will be on screen - these go in
.wsmode files- representing docking modes - places where TopComponents can be put - think of them as tabbed containers - these go in
Windows2/Modes. For each Mode, you will also create a folder in
.wstcreffiles that indicate what components are present can go TopComponents can live (essentially tabbed containers)
.wstcrf files- a pseudo symbolic-link that contains some configuration data and points to the appropriate .settings file via its ID - put these in the folder you created in
Apache Migration Information
The content in this page was kindly donated by Oracle Corp. to the Apache Software Foundation.
This page was exported from http://wiki.netbeans.org/DevFaqWindowsXmlApi , that was last modified by NetBeans user Admin on 2009-11-06T16:06:42Z.
NOTE: This document was automatically converted to the AsciiDoc format on 2018-02-07, and needs to be reviewed.