GUI design guidelines
Before to start describing the display texture update process I want to bring the attention to the fact that's a complete decouple beetween the generation of the screen picture and the presentation through OpenGL.
In first part of documentation we described several things concerning playing images to video.
This second part we concentrate only on generating an image to be presented as generated pixel by pixel. This second part of the project is candidate to be modified and extended.
The Document object is actually our display
As we told, the display is populated with an image. The image we are going to generate is normally composed of a background picture, that nothing says that cannot be a single back color as blue or black for example, and a series of widgets placed on the page that acts like inputs or outputs of commands for switches for example and informations for text values display.
All these elements are handled by a collector object that's rally a Document Object.
The Document object is constituted as private instance of a texture where it can play contents and then a composite pattern tree object of items belongings to the page like widgets.
Document class structures
The document object is an intance of a class of type ege2dDocument. The document class and related other main classes that acts on a page are described on a schematic diagram that's presented here.
- ege2dDocument - main class containing all controls like background image, other images, switches, lamps, pushbuttons, sliders and so on grouped as tree in "root" instance of a composite tree. ege2dDocument has also an instance of a picture that's the real output to display.
- ege2dTextureJpeg (and others concrete classes derived from ege2dTextureAbstract) that encapsulates load and load to GPU for all images and textures
- ege2dPushbuttonControl / ege2dImageControl / ege2dVerticalBarControl and all the others derived from ege2dIToolControl that are the real controls that shows a texture behaviour, loaded by ege2dTextureAbstract, a position x and y on screen and mouse event handling clicks.
example code Scada Tank: It is suggested to open source code sample to follow descripion with relevant code.
ege2dDocument - Instance of a picture
Concerning the picture is essentially a Jpeg image that's refreshed by internal document object logic when the status of a control changes. This is executed in a smart way in the meaning that only the relevant part of the image is updated instead of the whole picture to keep the code fast. When main draw executed, a pointer to this class is passed to retrive pixels data.
ege2dDocument - Tree object as "root"
The tree object keeps track in a binary tree structure format, the list of all the widgets of the page. These can be controlImages, controlPushbuttons, controlSliders, controlTextInputs, controlLabels and so on. All the controls widgets inherits from Composite pattern the capability to be attached to the tree as nodes by IComponent interface. Other characteristic of controls is that they inherits from ege2dIToolControl the capability to have coordinates on the page (x,y as bottom left) and a size. More than this the ege2dIToolControl offers also the virtual events from mouse clicks to propagate user inputs. The object is attached to a node by the add method inherited from IComponent.
A strategy Control image as control texture
A control on the screen can be every visible widget. To explane with an example, suppose we are considering a pushbutton visible aspect. The aspect can be rappresented with two images, one with button released and other button pressed. Both of them are images and can be both from files on disk or procedurally created and stored in ege2dIStrategyImage that can hold every image type. In order to keep such images handling simple, we have designed an EGE2DdIStrategyImage that's a support adapter for them. EGE2DdIStrategyImage easily returns an image with its getTexture* method. EGE2DdIStrategyImage behaviour is as an abstract class that is inherited from its derivate concrete classes that implements the polimorphic behaviour. Inherited classes, are today ege2dPushbuttonAspectBuilder, ege2dTextboxAspectBuilder, ege2dControlTexture. ege2dPushbuttonAspectBuilder and ege2dTextboxAspectBuilder makes the textures procedurally for a standard pushbutton and textBox I/O, leaving ege2dControlTexture the capability to load a texture directly from disk for every control that has a picture associated to it. It acts like a standard loader for every picture. For the images, the pink color is considered as transparent and will not be applyed to undelying pixels when control projected.
Anatomy of a ToolControl
The tool control class ege2dIToolControl acts as an abstract class to be inherited from all controls and offers standard operations accessor like handles mouse events and sets the actual visible state switching from underlying images loaded for any specific control. It also expose Refresh() common method that copy the actual status image to the display image to be drawn in the specific x,y position. Attached to the control there are also IAction objects injected to supply configurable behaviour for custom events, like is possible to connect a derivative class of IAction that send some string through Websockets to a controlle hardware or for another sample, an IAcrion that simply controls page switch.