|
|
Copyright © 2009–2010 Arndt Roger Schneider |
In Graphical User Interface s a window is a region with content, mostly of rectangular shape. Drawing operations outside the defined window region are invisible –clipped .
In Tk a window appears in the window hierarchy and has a unique identifier. This identifier is called the window pathname in Tcl/Tk.
The pathname is a list of window names separated by the dot (.) character. The last term is the name of the window and the terms before its ancestors.
Tk contains a special window without a name: dot (.), the root window. The root window is automatically created by Tk whenever a new window hierarchy is established. In Example 2.1, “Tcl/Tk pathnames” ».b« is a child of the root window.
A Tk window can be implemented in either »C« Jeszra does not yet generate C-source code.
The used programming language is irrelevant for the Graphical User Interface performance. Graphical User Interface performance is defined as how quick an application respond to a request –event–, either initiated by the user or through the application. How fast an application should respond is defined by its user. A human being requires time for seeing, deciding and acting. In detail: a normal human being perceives a succession of pictures as continues when they follow within 70ms –motion pictures have 41ms. Deciding and acting require roughly the same time as seeing. Thus a Graphical User Interface is perceived without interruption, when every user initiated action is completed within 3x70ms = 210ms.
Humans adapt easily to a certain speed, but not to speed changes. The solution for an unresponsive action can be to increase the processing time of all other actions.
Hence the performance of an application shall be independent from its data. The related measurement for responsiveness is called complexity . Complexity defines how much the processing time increases with contents. The desired complexity, for all windows, is constant ; which means that the response is independent from contents.
The responsivness of a software is determined by the author of that software and not by the used programming language. For example: the hugelist window, written in Tcl/Tk, has a constant complexity. The Tk listbox window, written in C, has linear complexity on n–were n is the number of all listbox entries.
7 Rules for a well crafted Window
Every visual element must be resolution independent.
Do not use bitmaps as icons, instead use vector graphics throughout the entire Graphical User Interface.
The window has to be predeterministic.
Good examples for predeterministic are the Tk window hierarchy or the stand alone geometry manager grid . Each window name is predeterministic and easily identifiable.
Implicit creation rules are the opposite to predeterministic. Here the application has to keep a cross-table for the transactions between model and view.
The identifiers, in a fully predeterministic Graphical User Interface, are derived from the model and thus a simple transformation or filter can be used to transfer data between the model and view.
The application logic, needed for handling implicit creation rules, is prune to errors. An application featuring a complete predeterministic Graphical User Interface will have significant less such errors. Remember: the Graphical User Interface has no business to create order, this is entirely up to the model.
The window must support on-demand data acquisition, if it displays a substantial amount of data.
This is the main reason for unresponsive Graphical User Interfaces. All contents originate from the model, channeled through the application layer, into the view. All the contents must be re-read even when only a fraction changed –either inside the view or the model. Now put a network between view and model to let the application crawl.
The real-estate established by the view is in general only large enough to hold fractions from the whole data. A window using on-demand data acquisition will only request as much data from the model as fit on-screen. Everything else is ignored as long as it is not needed. Of course rule #2 and #3 are interrelated.
The documentation must state the window´s complexity. The complexity is the contents related performance of a window.
This is an important information for everyone using the window, because the complexity defines how and when the window can be used.
Ideally a window has a constant complexity, which is possible with rule #2 and #3. However not every use-cases can be served with constant complexity.
The new window must have sufficient functionality of its own.
For example a labeled frame window, decorating a container with a description, provides no functionality of its own. All functionality is being borrowed from the two contained windows.
Flexibility should be the design goal for every window.
For example the rtl_gridwin attaches scrollbars to a client window. The gridwin uses a common interface to work with every scroll-able window. An application might simply rearrange the scrollbars inside the gridwin –through the Option Database– to change it for all scrolled window.
Keep the interface small and dedicated to a single task.
When aggregation is being used as the main means to acquire flexibility then the power of the entire interface is a function of their combination and not of individual windows. Which makes it fairly simple to replace single elements whenever the need may arise. The more complex the interface of a window gets the less likely it can be replaced with something different, new –perhaps better– and therefore bereft the application of its future.
Each of this classes features a built-in geometry manager. Figure 2.1, “Built-In Managers in Hierarchy View” displays the window hierarchy for all three built-in geometry managers.
General purpose geometry managers (pack, grid, place) are recessive to built-in geometry managers in Jeszra.
The canvas built-in geometry manager is called »canvas« and operates similar to »place«.
The text built-in geometry manager is called »text«, its geometry has no similarity to any stand-alone manager. The text geometry manager treats windows like glyphs(tokens). Windows float in paragraphs. The closest resemblance, to the text geometry manager, is a wrapped menu bar.
Paned windows provide a grid like built-in geometry manager. The internal geometry manager features grips, sash for interactive resize operations.
Jeszra keeps built-in geometry management and the window structure synchronized. A window, managed by a built-in manager, must be a child of the managing window.
Scalable Vector Graphics cannot be generated from the paned window. The internal decoration is excluded from Scalable Vector Graphics output. The paned decoration would be located between the red and black frame in Figure 2.5, “The Built-In Layout”.
The Canvas Items palette contains graphical objects available in the Tk canvas window.
Canvas Items are almost identical to windows, they have properties, react to events, feature »states« (may interact in predefined ways). The main difference to a window: Canvas Items can only being created and used inside of a »canvas« window.
Jeszra combines vector graphics and application design. The Tk canvas is only a very small part of Jeszra´s abilities. Vector graphics are dealt with in great detail later on in Chapter 6, Vector Graphics.
A text tag is a format description for floating text in a text window.
All text window features are supported by Jeszra, including direct editing and text formatting.
Text formats are organized as »tags«. Tags appear inside the hierarchy view underneath the window node, The hierarchy view resembles Figure 2.7, “Tags, formatted Text” . A tag is selectable and through the Inspector edit able. The Inspector »Geometry« page allows to extend the range of the given tag or to modify existing ranges.
The coordinates from the built-in »sel« tag are re-used, when creating a new tag.
The text window can only partialy converted to Scalable Vector Graphics 1.1. The text window lacks introspection. Although, it might be possible to use »dlineinfo« to gather some additional information about the visual aspects. »dlineinfo« is still insufficient to generate proper Scalable Vector Graphics 1.1.
The flowRoot item in Scalable Vector Graphics 1.2 may close this conversion gap between Tk and Scalable Vector Graphics.
There is a wide family of actors.
First amongst the actor family are the button-type controls. In Tk (and AQUA®, Motif®), there are buttons, button groups, checkbutton groups, radiobutton groups, checkbuttons with indicator, radiobuttons with indicator, menu commands, menu radiobuttons and menu checkbuttons.
Figure 2.10, “Striped Button Family” displays the button-style controls, as seen under Gstripes. On the left is the normal form and to the right the white space variation shown.
The white space variant of checkbutton and radiobutton have so-called indicators. An indicator is an icon representing the normal form from the left. This allows for multi-line captions without risking visual disintegration.
Microsoft® Windows 95® only featured the white space variant. These controls were termed »checkentry« and »radioentry«. This design is acceptable, as long as there is no normal form available.
The menubutton, at the bottom, is somewhat out of the ordinary. This control displays an indicator to the right, but does not fade into white space. Here, the indicator hints toward the popup menu, which appears when activating the menubutton. The right-sided button inside of a combobox uses the same visual concept.
Menus can be seen as dynamic dialogs, containing only a very limited set of controls. In Tk, controls inside of menus, are called »menu entries«.
Cascade is the equivalent to a menubutton. An cascade entry features a »menu« property, referring to another menu. The referenced menu is automatically opened (posted) whenever selecting a cascade entry.
Command is the equivalent to a button.
There is no normal form for menu entries! Menu entries have a close resemblance to the white space variation of their dialog counterparts. A menu can be seen as a single white space area wherein controls are being swallowed.
The separator is an inert entry. Separators are used for grouping entries.
The »Command«, »Radiobutton«, »Checkbutton« and »Separator« entries in Figure 2.12, “Menu Palette” are disabled. These entries are activated when selecting a »menu« window.
Menu screen-shots appear frequently inside of this document. A good example is shown in Options Menu. The »Options« menu features a radiobutton-group, a command entry and three checkbuttons.
The AQUA® HCI Guidelines recommends to use the caption of a checkbutton entry to communicate its state. This is used everywhere inside of Jeszra’s own menus. There is no direct support for this checkbutton type in Tk. Jeszra uses »commands« to achieve this design and implements the state handling explicitly.
The »-postcommand« Jeszra uses the postcommand property to create its diverse menus on-demand.
The postcommand property contains a tcl-script, which gets called right before displaying the menu on-screen.
|
|
Copyright © 2009–2010 Arndt Roger Schneider |