Graphical User Interfaces - A Complete Study
Part 2 - GUI Details and Resources
Written by Stéphane Richard (Mystikshadows)
INTRODUCTION:
Welcome to this second installment of my GUI Development Series. In the first installment, I told you about my own GUI project called ErgonOS, I detailed a bit what I wanted the GUI to do, defined some standard keyboard keys that will be available throughout the whole project, mentionned a bit what I wanted the GUI to look like along with some basic tools, utilies and resources. I think it's important to take the time to do this for a project this size just so you don't get lost in questions like "what did I want to do again?". But that's just the beginning. There's alot more to plan for when creating a GUI project. I call the first installment "The tip of the iceberg" and rightfully so as it talked about what the user would/could potentially see in the GUI.
In this second installment, We will break things down even more. We will take each part of the GUI as defined in the first installment and really take them apart to see exactly what each part needs as far as resources go to compose istself properly. You might be surprised to know, for example, that my scrollbar takes 8 distinct elements (plus 6 others for the pressed buttons) which brings the total to 14 elements for just a scrollbar. But you'll see how it's broken down later in this document. This is what we'll do in this second installment. It will form a very detailed list of things to do and implement which is a great tool to have when developing such a project. If any element is dependant on another it will be duely noted and we'll also start to define what events are and how they are to be considered in this project. So let's get right to it.
GUI DESIGN ESSENTIALS:
When you design a GUI's visual aspect, there's really three things you need to think about. It's important to take the time to really related these three items because in the end, they will govern the outcome of your project. When you think about it, there's more to a GUI than the way it looks even though the visual aspect of your GUI will be the first thing your users will see, it won't be the only thing they'll judge your GUI by. I've personally seen GUIs that looked like hell (in that case it was very bad color combinations) but were, in my book, as functional as they could get. I've also seen exquisitely beautiful GUIs that offered no functionalities (or atleast far from enough functionalities) to be usable. I've also seen GUIs that presented a good balance of these two aspects but seemed incomplete in design because some essential features just weren't there. Although a GUI is definitaly a question of personal taste, there's alot more to it than that. Let's take a look at these three things and explain them right here in what I believe is their order of importance in consideration.
- Functional Design:
A component is what many would call a control. For example, a TextBox, a ComboBox, a clickable button, and the likes. When I say functional design, it's important to understand that how it looks has nothing to do with how it works. When you display a textbox on the screen, you have to ask yourself what could the user want to do with that textbox. In other words, the way you plan on making your components work is the first item on the list. Once you know how it will work, how it looks will be a simple question of giving it a look that fits (intelligently) the intended functionality. - Component Relationship Design:
Most controls work fine on their own. A textbox is a textbox plain and simple. However, some conponents will be destined to work in combination with other components. A Scrollbar doesn't do much by itself, it will typically need something that will get affected by the events it handles. For example, a scrollbar might affect the visible area of a grid or a picture. It might affect the values of a variable (for a color selector), but by itself, a scrollbar is a component that doesn't have any real valid functionality. You'd be surprised at how many people forgot some simple thing like that which represented a major redesign of a big project. Taking the time to see how controls could work together will often solve this issue and avoid some major design issues as you'll see later in this series. - Visual Design:
At this point, you know what you want your control to offer to the user, you also know if and how a given component will depend on another componement or be depended on by another component (inter-component communication). Once you know this, you can sit down and give your component a visual look. When I designed the ErgonOS screenshot you've seen in the first installment, I took the time to think about the functionality and relationship of what you're seeing in the design. Everything is where it is for a reason.
You'll notice quickly I'm sure that I put visual design as the last item on the list. There is a reason for that. Knowing how a component works and what other component it can work with (if any) can and usually will influence the way it looks. There's visual aspects of a control that wouldn't look the way they did if the given component didn't interact with other components or they wouldn't be positioned where they are in the visual design if they didn't interact with other components that you'd typically see nearby. GUI design is all about common sense and a good level of user interaction. Speaking of which, user interaction should be considered throughout these three aspects of component design because GUI does mean Graphical User Interface and as such everything about a GUI should have to do with what the GUI allows the user to do and the way the user can perform those features. In a standard GUI you have to consider that the user might use the mouse or the keyboard to perform an action (in some cases, a joystick if designing a game or if you want your GUI to work with a joystick like it would with a mouse.
USER INTERACTION EVENTS:
As you know, with any programs but especially with GUI projects, one of the most important aspect of the program is the way it interacts with it's many components AND the way it interacts with the user. Both of these are really important for an application to be complete. In the context of a GUI project, this type of interaction are even more important. As a general rule of thumb, you should never leave your user in the dark as to what is happening at a given time. If the GUI is just waiting for the user to do something, you should have a direct means of letting him or her know that the GUI is waiting for them. If an application in your GUI is busy doing something "important" and the user should just wait, again he or she should have a way of knowing that. Before anything else, it's important to define what the user can do at any given time. So right now, let's take the time to define the actions that the users can perform in the GUI. Typically, they are split into two major groups of actions keyboard and mouse actions. Depending on the the hardware installed, a joystick could be used, a lightpen, a tracing table but they all amount to keyboard and non keyboard events.
- Keyboard Actions:
These are the oldest of actions. Keyboard have always existed since the dawn of computers and everybody uses them. Even today alot of users prefer the keyboard over any other type of input device. Although the choice is up to the GUI developer, me, I prefer to accomodate for both mouse and keyboard actions of not for anything else, to offer a backup system in case the other input device fails. This way, the user doesn't have to go buy a mouse right away. But I do this especially because alot of users are just keyboard users and would rather use the keyboard even if they have a mouse isntalled and working. Each key on the keyboard has a scancode and that code differs when ALT or CTRL or SHIFT is pressed in combination with the key. A keyboard manager simply needs to get these codes from the keyboard and branch out to the proper code fragment in the program depending on which part of the GUI the user is in when he presses the keys on the keyboard. At a global level, the keyboard standards I defined in the first part will be implemented. Because of such function as Shift and arrow keys which will allow to select text in a tet editor keyboard events will be broken down into 3 steps, the key down event the key press event and the key up event (when a key is released). - Mouse Actions:
This is where the code will vary alot depending on where the mouse pointer is (on what type of component). At a general level the user will have the ability to perform the following actions on any component that is currently visible on the screen:
- The user can move the mouse pointer around the whole screen. We'll need a way to determine where the mouse is on the screen but only in the case where the user pushes a button in most cases. However I want to implement a mouse over event to highlight the control that is currently under the mouse pointer as a visual help to the user, an indicator of which component on the screen will be activated if the user presses on a mouse button. The mouse over will be implemented on each component so when the mouse is over a component, the component will be responsible for knowing that the mouse is over it and highlight or unhighlight itself accordingly.
- The user can push a mouse button for two reasons, either to click or double click on a component or the user may push a mouse button to initiate a select of text or an area of a picture. In all cases each button on a mouse have a different value so we can determine which of the buttons were pushed. Because we'll want to allow selection of an area or dragging of elements to other locations, a mouse event is broken down in 3 steps, the mouse down event (when the user pushes down on a buton) the mouse press event (when the user just released the button he or she just pressed and the mouse up event (this is when the user finished releasing the button and will also help identifying if a possible double click of the button has occurred. Like windows, I want a click of the right mouse button to bring up a context sensitive menu for the current document in the document area (top right) section to give direct access to commonly used functionality.
- The user can perform a drag event which is a series of steps that start with a mouse button down event, a move of the mouse pointer while the mouse down event is still active (this will allow the dragging of a component or the selection of text or an area of a picture or whatever else that can be influenced by a drag event such has the scrolling of a scrollbar for example). There are many reasons to use a drag event, we'll see which component will need to handle later in this document.
With all this material in mind, let's define the ErgonOS components. We'll start with with simple components and work our way up to the components that are combinations of other components. This will also guide us in the rest of the series as to how we'll code ErgonOS and the techniques we'll use.
ERGONOS GUI COMPONENTS:
Here I'll be enumerating the elements, describing them along with any relationship that could and sometimes should exist between one or more other components. I will use a table format to help keep things clear and organized. Here we go. Note that if components are similar in nature I will group them in one table and merely explain the differences. I will explain the different actions and events after I enumerate them in this list of components.
| Standard Label Component | |
|
Control Name: Control Type: Depended on by: Depends on: Derived Controls: Action Types: Mouse Events: Keyboard Events: |
LabelControl User Interface and Communication No other controls No other controls No derived controls Move, Resize, Enable, Disable Drag, Move, Drop Could get clicked but not necessarily. |
| Description: | The label is the simplest component that can exist in a GUI however it's practically the most useful to the users as they give the user information and/or explanations about certain other controls (labels to a textbox entry for example). They can be used anywhere in a GUI design where the need to explain or give information to the user is necessary (just as error messages, confirmation messages and the likes. Titlebars to dialogs can also use labels to display title information. Labels are usually not directly controled by the user. However, you could, for example, create a link in a label that can be clicked by the user to open a website in an explorer. |
| Standard Button Component | |
|
Control Name: Control Type: Depended on by: Depends on: Derived Controls: Action Types: Mouse Events: Keyboard Events: |
ButtonControl Accessibility, Selection No other controls No other controls Group Buttons, Toolbar Buttons, Scrollbar Buttons Move, Resize, Select, Enable, Disable Click, Drag, Move, Drop Enter Key and Focus events, Arrow keys (if moving) |
| Description: | The Button Component is the most widespread control that can exist in a GUI project. Sooner or later One or more parts of a GUI will need some form of button (text or graphical) to confirm somekind of action in the case of dialogs for examples. They are represented by a rectangular area that can be clicked on by the mouse. Group Buttons work together as a group and typically allow one or more options to be selected at one time. They can also function as radio buttons would and only allow one member of the group to be selected at once. Toolbar Buttons are typically square but could be rectangular. Like other buttons they can so text and/or images. Scrollbar buttons are smaller than toolbar buttons as they need to fit in a more limited space (at the bottom of a vertical scrollbar or on the right of a horizontal scrollbar component, they only show small images and no text. |
| CheckBox/RadioButton Components | |
|
Control Name: Control Type: Depended on by: Depends on: Derived Controls: Action Types: Mouse Events: Keyboard Events: |
CheckboxControl, RadioControl Selection Labels for text part, other radio components as a list No other controls No Derived Controls Move, Resize, Select, Enable, Disable Click event Space Key and Focus events, Arrow keys (if moving) |
| Description: | There's two major roles to the Checkbox component the first of which is to allow to select an option as being enabled or not. Another (fairly used option) is to represent a status of a series of operations where the option being completed gets checked so the user can see how many steps are left. The radio component can also be turned on or off however it needs to be in a group of other radio controls to achieve it's intended purpose as it allows to select one and only one of a series of options. |
| TextBox, MaskedBox, SelectorBox Components | |
|
Control Name: Control Type: Depended on by: Depends on: Derived Controls: Action Types: Mouse Events: Keyboard Events: |
TextBoxControl, MaskedBoxControl, SelectorBoxControl User Input No other Controls No other controls No Derived Controls Move, Resize, Select, Enable, Disable, Entry Click event, Drag Event (for selection) All Keys and Focus events, Arrow keys (if moving or resizing) |
| Description: | In ErgonOS these three components allow one line only of filtered on non filtered entry from the keyboard. Whenever a value (string or numeric) is expected from the user, it is often in a textbox component that this value can be acquired from the user. MaskedBox components offer the same with the added feature that the input can be controled by providing a mask (or filter) to what keys the user can push. for example a mask of "##,###.##" would only allow the user to enter numeric values. This is useful for data validation techniques. A SelectorBox could also be called a range validator component and can be used when a list of expected values is acceptable. Note that a listbox or a combobox component could also be used for this purpose. Depending on the role of the input a selector box could be faster and just as safe. |
| PictureBox Component | |
|
Control Name: Control Type: Depended on by: Depends on: Derived Controls: Action Types: Mouse Events: Keyboard Events: |
PictureBoxControl Display, Image Editing No other controls Scrollbars if image bigger than picturebox No derived controls Mouse Movement, drag, drop, select All Button Click, Drag, Drop. Arrow keys, PageUp/Down, Enter, Shift Arrows (Selection). |
| Description: | What's to say about a picture box exactly? In this case, the picture box will allow complete editing of images of course. It will also allow the loading and displaying of image files of many formats. Aside the standard expected image functionality, i will also support zooming in and out, color depth manipulation and a couple of advanced functions to make the image box a little bit more useful than most standard picturebox component. As mentionned, should the image being displayed be larger than the current size of the picturebox component, a set of scrollbars will be available to navigate around the image. |
| ListBox/ListView/TreeView Components | |
|
Control Name: Control Type: Depended on by: Depends on: Derived Controls: Action Types: Mouse Events: Keyboard Events: |
ListBoxControl, ListViewControl, TreeViewControl List management, Hierarchy and Basic Grid No other controls Scrollbars if list is bigger than the listbox ImageList and ImageListView Mouse Movement, drag, drop, select All Button Click, Drag, Drop. Arrow keys, PageUp/Down, Enter, Shift Arrows (Selection). |
| Description: | This set of 3 controls I've combined here because when you think about it, they are all some form of list managers in their own right. The listbox is the most primitive of the three controls in that it only allows a list of one data element. A scrollbar appears when needed if there's more data than what is visible in the control, all controls work the same way. The ListView component handles more than one column of data but otherwise works as a listbox component. The treeview is a list however each item can have one or more child items which allows to handle a complete hierarchy of related and grouped items quite efficiently. |
| ComboBox, CalendarDrop, NumericDrop Components | |
|
Control Name: Control Type: Depended on by: Depends on: Derived Controls: Action Types: Mouse Events: Keyboard Events: |
ComboBoxControl, CalendarDropControl, NumericDropControl Selection, Data Entry No other controls Scrollbars, buttons, listbox, calendar and numericpad No derived controls Mouse Movement, drag, drop, select All Button Click, Drag, Drop. Arrow keys, PageUp/Down, Enter, Shift Arrows (Selection). |
| Description: | This set of 3 controls all have a standard textbox or maskedbox with a down arrow button on the right. while standard textbox editing is available, pressing the down arrow button will, in all three components, brings a more visual means if entering (or selecting) valid data for the textbox area. Since they all bring down a different means of data entry, I grouped them together here. Of course the combobox will bring down a list of selectable items (much like a listbox), the calendar component will bring down a calendar from which to select a valid date and the numericdrop component will bring down what looks like a calculator (numeric keypad) to select each digit that are to be entered in the text area. |
| Toolbar and Toolbox Component | |
|
Control Name: Control Type: Depended on by: Depends on: Derived Controls: Action Types: Mouse Events: Keyboard Events: |
ToolbarControl and ToolboxControl Selection, options, menu shortcuts No other controls Buttons, Combobox and others for representation No derived controls Mouse Movement All Button Click Tab key to select, Enter key to activate. |
| Description: | These two components are really one of the same, they are a rectangular area that are used to hold mostly button components (but can hold other types of components as well). The main difference between these two components is one of standard. The toolbar will hold menu shortcuts only while the toolbox can hold tools and accesories that can be used with the current document type. If you remember I mentionned in the first part that each document can customize the GUI for it's own use. These are two of the four areas of the gui that can be customized for the type of document. These components are around the main document area (the toolbar is below the menu system and toolbox components can be anywhere around the main area (top, bottom, left or right). |
| ComboBox, CalendarDrop, NumericDrop Components | |
|
Control Name: Control Type: Depended on by: Depends on: Derived Controls: Action Types: Mouse Events: Keyboard Events: |
ComboBoxControl, CalendarDropControl, NumericDropControl Selection, Data Entry No other controls Scrollbars, buttons, listbox, calendar and numericpad No derived controls Mouse Movement, drag, drop, select All Button Click, Drag, Drop. Arrow keys, PageUp/Down, Enter, Shift Arrows (Selection). |
| Description: | This set of 3 controls all have a standard textbox or maskedbox with a down arrow button on the right. while standard textbox editing is available, pressing the down arrow button will, in all three components, brings a more visual means if entering (or selecting) valid data for the textbox area. Since they all bring down a different means of data entry, I grouped them together here. Of course the combobox will bring down a list of selectable items (much like a listbox), the calendar component will bring down a calendar from which to select a valid date and the numericdrop component will bring down what looks like a calculator (numeric keypad) to select each digit that are to be entered in the text area. |
| MenuBar, PullDownMenu, PopupMenu Components | |
|
Control Name: Control Type: Depended on by: Depends on: Derived Controls: Action Types: Mouse Events: Keyboard Events: |
MenuBarControl, PullDownMenuControl, PopupMenuControl Selection, options No other controls Option bitmap icon of the menu option No derived controls Mouse Movement Left button click Arrow keys to navigate Enter key to activate. |
| Description: | A menu system is typically a combination of these three types of menu components. The menubar is the first visible to the user. In ErgonOS it is right below the titlebar on top of the main document area. when the user selects one of the options in the menu bar, a pulldown menu will appear with relative functions and options. Because it will appear below the selected menu bar option, it is said that it will pull itself down which gave birth to it's name. If other levels of menus are needed, popup menues will be used. This same popupmenu will also be used for the right button click functionality I mentionned earlier in this document. In the pulldown menu and the popup menues, an optional bitmap may be used to give a visual representation of the menu option (when these are added to a toolbar, only that bitmap will appear) This will help locate what the button does because the user will see it in the menu system with a description. These controls can also be customized on a per document type level to offer the most relevant functionality needed when working on a certain type of document (that works just as well if he document is a game for example). |
| Statusbar and IndicatorBar Components | |
|
Control Name: Control Type: Depended on by: Depends on: Derived Controls: Action Types: Mouse Events: Keyboard Events: |
StatusBarControl and IndicatorBarStatus Information and user feedback No other controls Labels and optional bitmaps No derived controls No actions, for display only No Mouse event except possible mouse over and click No keyboard events. |
| Description: | Both these controls appear on the bottom of the main document area and server to represent information about the current document. The statusbar component will mention things like the document name, it's type, if it's modified or not and the likes (definable by document type). the indicatorbar will tell you where you are in the document (rown and column) as well as if you are inserting or not, if your caps lock key is pressed or not and other "editing" related information, it could be X and Y coordinates on a picture for example. Again it can be customized on a per document type level so each document can give relevant feedback about itself and is being done currently by the user. |
| TabbedDialog and TabStrip Components | |
|
Control Name: Control Type: Depended on by: Depends on: Derived Controls: Action Types: Mouse Events: Keyboard Events: |
TabControl and TabStripControl Selection No other controls Label, optional Bitmap Icon, Page Container No derived controls Mouse Movement Left and Right button click Tab key to select which tab is active. |
| Description: | In ErgonOS, the best example of Tab usage is the main document area. When you open a new document (whichever type it may be) it will create a new page in the document area And will appear right below the main document editing area. Selecting one of these tabs will essentially setup the whole GUI for the document type (including menues, toolbars, toolboxes and accessories toolbox at the bottom right of the screen). In this case the tabs work much like the windows taskbar where each page will be an application or a GUI setup for the document type. When you click on the document configuration tool, another use of tabbed dialogs will be available as the functionality and options for that given document type will be shown in a tabbed dialog grouped by functionality in different tabs. IF an application needs a data entry screen and there are too many different bits if information required for just one screen, using tabs will allow to create entry screens that are on more than one page. Tabs provide a quick and intelligent means of organizing multiple screens of related information. Each page uses a page container so that it can contain other controls or document to achieve the desired functionality of the new page. |
| Document Management Component | |
|
Control Name: Control Type: Depended on by: Depends on: Derived Controls: Action Types: Mouse Events: Keyboard Events: |
DocumentControl Entry, Selection, Visualization, Editing No other controls Document Filters per document type No derived controls Mouse Movement Left and right button click, drag, drop All keyboard events for editing, selecting, etc. |
| Description: | A document, in the case of ErgonOS can be considered as a document and/or an application since each document type govern the overall look and behavior of the whole GUI. Hence if you were to make a game for ErgonOS it would appear as a document page in the main document area. More than one page representing one document will also be allowed. For example, if you were working on an HTML document you could define a page for the HTML code itself and another page for the HTML preview. Tabs on top of the document area (below the menu and toolbars) would then appear for each representation of the same document. Another example is XML files. In many cases You'd be editing XML code, XDT files for data definition and XSL files for data representation and formatting. the three files could be paged the same way in one document since they usually work as a group towards a finished validated and formatted XML document. A game could have more than one page as well. For example, the first page could be the main game, the second page perhaps a map of the different levels when needed and the likes. Each document can be setup to represent itself in different ways. A plain text document would just output regular characters, a source file could have a syntax highlighting feature applied when editing code, a word processing document could show different fonts, colors and images in it's contents. Of course you could use the supplied functionality but you could also provide your own. So essentially, defining a document's views, behaviors, tools is the first part in building an application setup for the document type. in addition to that, you could also add a document editing and viewing options to allow you to add syntax highlighting or text formatting features to your document. You could either use known standard keywords and tags or define your own. More on this when we cover ErgonOS Application Development facilities. |
| User Definable Component | |
|
Control Name: Control Type: Depended on by: Depends on: Derived Controls: Action Types: Mouse Events: Keyboard Events: |
UserControl Application Creation, Functionality filtering No other controls All other components and other user components No derived controls Mouse Movement, kebyard action, mouse buttons Selectable Mouse Events (all possible) All keyboard events (can be customized) |
| Description: | So far, the components I've defined all follow the ErgonOS standard as in they are all made to work with what ErgonOS offers in terms of functionality, look and feel. This UserControl components allows the user and developer to create 100% customized look and feel for their documents (applications). Later in this series, when we create our home financial application, we'll see how this control can be used in so many ways to give a document type it's own unique look and functionality based on what the document should be allowed to do. We'll also see example of the multiple paged document usage too as the application will need all these features to perform it's designated task properly. For now, all you need to know is that the User Component allows things to appear and work completely based on what the user need and want from a given document type. Functionality filtering could easily be used as a security measure where when you allow others to use the system you might not want them to edit any files any editing feature could be block with a simple click of a button or by creating a functionality filter for the current document type. |
And there you have it, this represents the many controls that are used in ErgonOS. With the UserControl component you could create your own if you want a specific component that just doesn't exist in ErgonOS. Of course, to make it all work together in a coherent and intelligent way, we'll need some basic things implemented. Groups of related functionality that all serve to perform a given set of tasks are often called engines. And ErgonOS will definitaly have engines to allow it to offer the users a suitable and usable interface to the low level functionalities available on the OS it will be built on. Let's take a brief look at them so we know better what we'll be up against when we start to code the GUI.
ERGONOS ENGINES:
The engines listed here represent independant areas of functionality that is needed for ErgonOS to work like it is expected to. Each engine is independant in itself but could receive, if needed, events and information from one or more of the other engines. Here are these engines along with their description.
- L.A.H.P. (Low level Access to Hardware and Peripheral)
In this first phase of ErgonOS development, this level will just be an interface to BIOS information however I will keep that part independant so that ErgonOS can be quickly made to work on any other architectures. if you need to know information about the hardware in the case, this is what will give that information. This should work fine in any PC based system in this first phase. - V.A.D.M. (Video Access Device Manager)
Although I've decided to use the Allegro library for most video functionality you'll be seeing, there is still plenty of functionality that I'll need to code for. For example, screen saving and restoring for when forms and dialogs appear on top of the GUI the screen will need to be restored after the form or dialog is closed. I'll also need this engine to have knownledge of where all components of the GUI are so I know which event manager to call when a user event occurs. This is the engine for the job. Using allegro (and derivatives) should allow the Visual side of ErgonOS to work on any platform and OS that supports the allegro library. - O.S.S.I.S. (Operating System Services Interface System)
All operating systems work different when it comes to using the hardware connected to the PC. DOS will use interrupt 10h for video, 33 for mouse, 21 for OS services. Linux will use a different system and the same goes for other OS on other platforms. In this first phase, DOS will be implemented. But in later phases, I plan on being able to run Ergon OS on amigas, Macs, power PCs and other architectures that differ greatly from one another. So this part of the engine will be kept independant of the other engines so they can be adapted to different platforms and OSes as easily as possible. - A.S.D.A.M. (Architectural System for Digital Audio and Music)
If the OS can see a sound device in the system, A.S.D.A.M. will be initiated and read for action. It will also allow facilities for opening and creating standard MIDI files and wav/mp3 files in preparation for multimedia presentations or games. It will offer a set of standard functions coherent on all OS and platforms that will interface itself to the OS's provided drivers or architectures for sound synthesis and digital audio that are installed. - A.R.M.S. (Advanced Resource Management System)
ErgonOS uses resources thoughout a session, it will load appropriate bitmaps for controls and forms, it will unload what is not need at the current time. This engine is what will take care of that internally. It will get notified by the GUI that certain components and images aren't needed and ARMS will get rid of them in memory. Garbage collection will also be managed here. Note that the global ErgonOS Clipboard functionality will be managed from this engine as well so that anything that is cut or copied can be made available to other documents. - T.E.M.S. (Tasks and Events Managmeent System)
In ErgonOS each document type currently opened represents a task, Each task has it's own page so to speak. However some pages will have multiple pages to represent themselves. Each component that can be seen will have it's own event manager. The current task will determine which document gets the user events (along with which of the general ErgonOS areas are clicked on or keyed to with the keyboard). This engine will determine which area of the screen the event goes to as well as which task it belongs to all the way down to which component the mouse was over when the event occured to know which event manager to call. - C.A.P.S. (Command Acquisition and Processing System)
Remember the command window from the first installment of this series? This engine is what will get any and all commands typed in the command window, determine if the command is valid, and execute the commands (which could mean bringing up a file dialog to open a file, setup a document type's many customization features, create a project group in which files will be organized for the sake of user ease of use and personal organization of his files or whatever else is offered by the GUI in terms of feaures and functionality. These commands are global to the whole GUI unless a given document type has been given a specific set of commands that are active when the type of document is being worked on. For example, if you are editing a webpage, you could say that for HTML files PREVIEW will automatically activate the preview tab of the document. and really customize even more aspects using custom commands. This engine will also allow to create what I call ErgonOS Job Files which are specific list of ErgonOS commands that can be executed much like a DOS Batch file. - E.A.G.L.E. (ErgonOS Application Generation Language and Environment)
On top of CAPS which can be directly incorporated into an EAGLE application for GUI setup purposes for example. EAGLE will also have all the statements needed to create variables, perform conditional testing and evaluation, itterative constructs and procedures to organize the code into a modular fashion. It will also allow object oriented programming extensions (I call it extensions because OOP will be optional, not mandatory in EAGLE development projects).
This is of course a work in progress. It represent the engines I can think of right now. I think they are complete and that if they have been mentionned they shouldn't change too much. However, as development goes by, I might add to this list of engines if I think of a major group of functionalities that I simply didn't account for when enumerating them right here. As you can se, I'll have my work cut out for myself but it should be a very interesting experience. All these engines are there because of the way I want ErgonOS to work. It is very likely that for your own GUI projects you might want things to work very differently from ErgonOS and rightfully so. This series represent everything that will go in ErgonOS as per the way I will want ErgonOS to work internally and from the user's perspective. Of course your GUI project might have some similarities to mine. But this series of articles should be used as a set of guidelines for ALL GUI projects. But rather as a list of things you may want to consider when creating your GUI. Sitting down and thinking abit about what your GUI will be used for and what it should have based on it's intended purpose will help you define what parts you'll want to use and which part have no meaning to the purpose of your GUI.
PART TWO NOW CONCLUDED:
This brings the second part of this series on GUI development to an end. It also brings alot of the "documentation part" to an end as well. In the next part we'll still be documenting a few things of course but all documentation will start aiming at the coding side of the GUI rather than the design side of the GUI. So I suggest you take the time for these first two parts to sink in as good as they can before we attack the third part of this series. I've mentionned alot of things in these first to documents. Maybe by now some of you might already be thinking of how you can use some of this material for your own new or existing GUI projects. Can you imagine just how prepared documenting the GUI design helps make you? it took me a couple of hours and look at how organized things are getting in this project so far. These first two parts will really help define the rest of the series right down to the coding part and this is what planning is all about.
In the next installment, as I already mentionned, we will be starting on the coding side of ErgonOS. Like I said I will be documenting that side too but as you'll see it will all be about coding. Until then, if you have questions, comments, suggestions or if you just want to say hi, you can email me at the email shown below. Until the next installment, happy reading and planning.
MystikShadows
Stéphane Richard
srichard@adaworld.com