Design Notes and Philosophies

One of the primary deviations from past widget sets, is the switch to floating-point percent-window-size layout, away from integer pixel or frame-based layout. This is enabled uniquely by the underlying OpenGL. It promises much more natural and flexible window layout. It is very simple and straight-forward.

As a window developer, I want to sketch-out the placement of various widgets, and then implement the window as envisioned. I know where I want to place each object on the page, and it's size, for instance as a percentage of the window's size. I really do not care how many pixels that is. Frameworks (widget grids) do not allow fine control, and seem very awkward to fit a desired layout in many cases.

Because coordinates are specified in percent of window size, then if the application-user resizes the window, the layout remains the same. If specified in pixels, then the layout would need to be re-designed or re-computed, else it will not resize well. Certainly this is a new way of thinking. Perhaps you will like it or not. I find it works reasonably well for many applications.

Otk Design Issues:

Issue 1 - Coordinate Systems

One issue, was whether the percentage-based coordinates should refer to the outer-most window, or the most local panel (immediate parent) ?

Presently, it was decided and implemented to be relative to the local panel. This enables a panel's layout to be designed once, and then used anywhere within any window or panel, regardless of hierarchy-level or window-size. Granted, the panel's size may change considerably, depending where it is instantiated, but everything will render correctly.

For example, suppose panel-A occupies the outer-window from 20% to 40% horizontally, and 60% to 80% vertically.

Another way to think about this is that all windows or panels have a coordinate system that spans from 0.0 -to- 100.0 in both the vertical and horizontal.

We can say the panel-A occupies the area from it's upper-left corner (20,60) to it's lower-right corner (40,80), or that it occupies 20% of the outer-window both horizontally and vertically (40-20=20, 80-60=20).

Issue 2 - Widget Architecture

Another issue was how to architect the widgets. Otk approached this from a very simple viewpoint. Two fundamental classes where defined: Panels and Text. (A placeholder was reserved for anything outside these classes, but so far nothing else but "lines" has been needed.) Every object is descended from one of the two fundamental classes or a combination of both.

For example, windows and rectangular panels (for placing other widgets onto), are all considered to be container-panels and are members of the class Panel. The basic Panel class has an attribute that affects how it is displayed: either as a flat rectangular area (simple panel), a raised rectangular area (raised panel), or a recessed rectangular area (recessed panel). Even Buttons belong to the Panel class, but they have an extra attribute which is sensitivity. That is, Buttons are merely panels that are sensitive to mouse clicks. Therefore, Buttons are a sub-type of the Panel Class.

Complex widgets are combinations of the two widget base classes. The combinations appear to form super-classes. For example, the Button is a combination of a Panel sub-type and a Text label widget. This all gave rise to Otk's present three level class structure: Super-classes, fundamental Classes, and sub-classes.

Currently it is time to step back and review the architecture, and possibly re-organize it. Nothing is set in stone at this time. It would seem that a cleaner object taxonomy could be derived by looking at the logic which operates on the classes. One observation is that there appears to be two viewpoints: 1.) how to display an object, 2.) how to operate with an object. It may make sense to re-architect along these lines.

Side-note: This issue affects how Otk will be implemented "under-the-hood". It should not affect the application interface (the dashboard).

Issue 3 - Depth Management

Presently, objects begin forming at depth 0.0 and are placed at progressively higher levels, for example 1.0, 2.0, 3.0, etc, as they grow toward the camera at 510.0. The viewable frustum is 0.0 to 500.0.

Under perspective mode, the resolution would vary with distance from the camera. However, under the oblique mode used in Otk, the resolution is constant. So there is no need for us to vary our delta-Z incrementer. It also does not matter how far the camera is from the near-field of the frustum, unlike with perspective mode.

The resolution is contant at roughly 0.002 (for my video card) with the Otk frustum. Other video cards/libraries may be worse.

The floating sub-windows begin forming at 300.0 and move upward from there by steps of 4.0+thickness for each one formed, where thickness is the difference between the lowest and highest object on a sub-window. During each draw, the highest sub-window is determined, so that new sub-windows occupy the next highest active position, which is also reduced when sub-windows are closed.

Naming Conventions:

1. All Otk functions begin with: "Otk" Note the "O" is capitalized, the "tk" are smalls.

   (There are many precedents for this style. For example, all X-library calls begin with upper-case "X". This distinguishes immutable infrastructure routines from user routines which are typically all-lower-case names. The balance of the letters being mixed-case, further distinguishes Otk routines from macros/constants which typically are all-caps. )

2. For functions that are part of the published Otk API, the first letter of each subsequent word in a routine name is upper-case.
   Examples: OtkMakePanel(...), Otk_Make_Selection_List(...)

3. Functions that are not part of the published API, but that are internal (private, behind-the-scenes) functions of Otk, use lower-case for all letters after the Otk prefix. Examples: Otk_object_attach(...)

   The general user need-not be concerned with these functions. Only Otk-developers use these.

4. There are some exceptions to the above conventions, due to names that were selected prior to these conventions.

Explanation of important object fields:

1. Object's Coordinates -
There are two sets of coordinates for each object:

A. Relative - x1, x2, y1, y2.
B. Absolute - xleft, xright, ytop, ybottom.

The second set, Absolute-coords, are calculated from the Relative-coords, and are the object's absolute coordinates in the OpenGL window. This coordinate system is internal to Otk. It is not exposed through the user API. The Absolute-coords are not relative to other Otk windows or objects, other than the main outer-window.

Back to main page