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 inWindows2/Components
-
.wsmode files
- representing docking modes - places where TopComponents can be put - think of them as tabbed containers - these go inWindows2/Modes
. For each Mode, you will also create a folder inWindows2/Modes
where the.wstcref
files 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 inWindows2/Modes
See also: