Right from the start, the Graphical User Interfaces (GUIs) of the most popular operating systems, have been and still are organized around windows. A window is an area on the screen that has the ability to receive user input and present itself via a set of vector/raster graphics commands. The term screen here references a virtual screen that is different for each integration platform and which can actually span multiple monitors. For most users this virtual screen is associated with the term desktop.
A window in NOV is a painting surface, that can receive native user input and that has a peer, which is native for the specific integration platform. NOV distinguishes between two types of windows - top-level windows and child windows, represented by the NTopLevelWindow and NChildWindow classes respectively, both of which derive from the abstract NWindow class. The NWindow abstract class on its turn derives from the NBoxElement abstract class and hence windows inherit the box elements functionality, described by the Box Elements topic.
A top-level window is a window that is usually associated with an application window, form or dialog. Top level windows help you popup NOV content in a native for the Window Manager way.
A top-level window is peered with a native for the Window Manager top level window. All Window Managers support top-level windows that share a number of common features such as the ability to open windows, resize windows and display windows over other top-level windows. Another important common feature of top-level windows is that they are hierarchically organized, meaning that certain top-level windows can be owned by other top-level windows.
A child window is a window that is usually associated with a widget placeholder. Child windows help you embed NOV content in already existing presentation layers, via a specific for each presentation layer host.
A child window is peered with a native for the integration platform-presentation layer UI element. To be fully functional a child window must be explicitly hosted in a native for the integration platform-presentation layer host. Because each presentation layer is associated with a Windowing System, for the specific platform on which it runs, each native UI element is having a native for the Windows Manager top-level window in which it resides. Because of that fact, each child-window is actually residing in an implicit native top-level window.
It is important to distinguish between the Window Manager and the Presentation Layer (i.e. controls toolbox) that integrates inside it, because these are two very different things.
For example - both WinForms and WPF are presentation layers for the Microsoft Windows - Win32 Window Manager. In WinForms a top-level window is represented by the Form class and in WPF by the Window class - both of them however are creating a top level Win32 window, that is managed by the same manager. A child window in WinForms is represented by the Control class, that actually creates a child Win32 window, while in WPF a child window is associated with the UIElement class, which does not have a native Win32 counterpart. Both the WinForm-Control and the WPF-UIElement are however residing in an implicit Win32 top-level window - the native window for the Microsoft Windows - Win32 Window Manager.
In Silverlight things become more complicated, since Silverlight does not have a Window Manager, nor tries to integrate with the Windows Manager of the current OS in which it runs. That is why the NOV Silverlight host is actually implementing its own Window Manager that emulates the Microsoft Windows - Win32 Window Manager inside Silverlight.
Both top-level and child windows share a set of common features that are essential for the visual communication with the user, that are:
- User Input - windows can process native user input related to mouse, keyboard and drag and drop. Windows can also request native focus and mouse capture.
- Painting - windows can paint themselves, in an abstract back-end graphics, that is specific for each integration platform.
- Cursors - windows can request native for the Window Manager cursors.
- Content - the content of each window is an instance of the NWidget class.
In order for a NOV window to be fully functional it must be made a descendant of the desktop. In NOV the desktop is represented by the NDesktop class, a singleton instance of which is accessible from the NApplication.Desktop property. NOV creates the NDesktop singleton instance when NOV is installed for a particular presentation layer (see Installing NOV).
The windows that belong to the desktop are accessible by NDesktop-Windows property. This collection is populated with the root windows of your NOV application. The root windows of your application can be both child windows and top-level windows.
Each window (child or top-level) can have an arbitrary number of top-level windows that are considered owned by. The top-level windows that are owned by a specific window are accessible by the NWindow-Windows property.
The following image illustrates the object relationship between the top-level windows, child windows and the desktop.
figure 1. Windows and The Desktop
In the image above the NChildWindow 1, NChildWindow 2 and NTopLevelWindow 3 are contained in the NDesktop-Windows collection and are the root windows of this fictional application.
The NTopLevelWindow 1.1 is contained inside the Windows collection of NChildWindow 1. NTopLevelWindow 1.1.1 and NTopLevelWindow 1.1.2 are contained in the Windows collection of NTopLevelWindow 1.1. This means that you can popup NOV content from any NOV window.
So we have all objects of the figure mapped except the Implicit Top-Level Window. If you recall a child window is intended to be hosted by a native for the Window Manager top-level window. The Implicit Top-Level Window is just that - the native top-level window, which indirectly hosts the NChildWindow.
It is important to know that the Window Manager does not actually need to know about child windows, it is only concerned about top-level windows, in order to perform correct ownership mapping, Z-order and other features. So that is why even though NTopLevelWindow 1.1 is a child of the NChildWindow 1, for the native Window Manager it is a owned by the Implicit Top-Level Window.
Because Window Managers are primary interested in top-level windows and rarely depend on any native child windows, many GUI toolkits do not use native child windows at all. Such GUI toolkits are often called "windowless", to emphasize on the fact that they do not depend on the native child windows for a specific Window Manager.
Window Managers typically come with predefined native child windows, such as buttons, list boxes etc. GUI toolkits that use these directly or indirectly are called "window wrappers". For example - WinForms is a "window wrapper" GUI toolkit, because it uses the native Win32 common controls (predefined child windows for the Win32 Window Manager). WPF is a "windowless" toolkit, because it does not use the Win32 common controls.
NOV UI is also a "windowless" toolkit, but goes even further by abstracting itself even from the native Window Manager top-level windows and other OS specific features. That is why NOV can also be characterized as a "hostable" and "virtualizable" GUI toolkit, which is a truly rare (if not unique) feature for a GUI toolkit nowadays.
In terms of DOM, the NDesktop, NWindow and NWidget classes are all elements. In order to provide NOV Windows and their content with a functional environment for expressions, styling, measure and arrange services, NOV hosts the singleton NDesktop element inside a NDocument instance. This means that all Windows and Widgets that you can see displayed by a NOV application are hosted in a single document, which is accessible from the NApplication.DesktopDocument property.
The fact that all Windows and Widgets of your application are descendants of a single document has many architectural advantages one of which is application-wide themes. In NOV themes are just factories for a Cascade Style Sheet (CSS). This means that you can change the entire application look and feel with CSS by just altering the StyleSheets collection of the NApplication.DesktopDocument.
A shortcut for applying an application wide theme is the NApplication.ApplyTheme method. The following code changes the entire UI to use the Windows Classic - Teal theme:
| Changing the Application Styling |
Copy Code
|
NWindowsClassicTheme theme = new NWindowsClassicTheme(ENWindowsClassicThemeScheme.Teal);
NApplication.ApplyTheme(theme);
|
Finally there is a browser-like environment for making applications.
