blob: cb318a18adcbee78e99ea83a89dfcc8daa8f218e [file] [log] [blame]
//
// Licensed to the Apache Software Foundation (ASF) under one
// or more contributor license agreements. See the NOTICE file
// distributed with this work for additional information
// regarding copyright ownership. The ASF licenses this file
// to you under the Apache License, Version 2.0 (the
// "License"); you may not use this file except in compliance
// with the License. You may obtain a copy of the License at
//
// http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing,
// software distributed under the License is distributed on an
// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
// KIND, either express or implied. See the License for the
// specific language governing permissions and limitations
// under the License.
//
= How does the declarative XML API for the window system work?
:jbake-type: wikidev
:jbake-tags: wiki, devfaq, needsreview
:jbake-status: published
:keywords: Apache NetBeans wiki DevFaqWindowsXmlApi
:description: Apache NetBeans wiki DevFaqWindowsXmlApi
:toc: left
:toc-title:
:syntax: true
:wikidevsection: _window_system
:position: 7
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 xref:DevFaqSystemFilesystem.adoc[System Filesystem ]
by declaring them in your module's xref:DevFaqModulesLayerFile.adoc[layer file]:
* *`xref:DevFaqDotSettingsFiles.adoc[.settings files]`* - representing xref:DevFaqWindowsTopComponent.adoc[TopComponent]s that will be on screen - these go in `Windows2/Components`
* *`xref:DevFaqWindowsMode.adoc[.wsmode files]`* - representing xref:DevFaqWindowsMode.adoc[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 `Windows2/Modes` where the `.wstcref` files that indicate what components are present can go TopComponents can live (essentially tabbed containers)
* *`xref:DevFaqWindowsWstcrefAndFriends.adoc[.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 `Windows2/Modes`
See also:
* xref:DevFaqWindowsWstcrefAndFriends.adoc[How to use .wstcrf and other files]
* link:https://bits.netbeans.org/dev/javadoc/org-openide-windows/org/openide/windows/doc-files/api.html[The Window System API]
////
== Apache Migration Information
The content in this page was kindly donated by Oracle Corp. to the
Apache Software Foundation.
This page was exported from link:http://wiki.netbeans.org/DevFaqWindowsXmlApi[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.
////