Re: GWindows and a future home for it

[Nick Roberts <nick.roberts@acm.org>]

stephane richard wrote:

> I'd like that rundown :-).....brief or detailed ;-).  you can email it to me 
> if you want.  Unless it's ok to post it here?  whatever's good with you.

I've knocked up something very quick. I've actually tagged it in HTML, but 
never mind.

I admit that, because Titian's is relatively undeveloped, it's not much of 
a runner. Possibly the one redeeming feature is that Titian really is very 
platform-independent, and everything about it is done 100% 'the Ada way'.

The point is, if something like GWindows or CLAW is developed (on 
SourceForge, for example), I will have develop Titian on my own anyway 
(also probably on SourceForge), because (I presume) neither GWindows nor 
CLAW could sensibly be ported to a very unWindows-like platform such as AdaOS.



<div class="titian">



<h1>Titian Summary</h1>
<p>October 1, 2004</p>
<p><i>Nick Roberts</i></p>

<p>...</p>



<h2>Quick Glossary</h2>

<dl>

<dt>orthogonal rectangle</dt> <dd>a rectangle whose sides are parallel
with the vertical and horizontal axes (abbreviated to
<dfn>orthorect</dfn>)</dd>

<dt>RGBA</dt> <dd>red, green, blue, and alpha (one minus the
percentage of how much the corresponding background should show
through)</dd>

<dt>component</dt> <dd>a self-sufficient (to some extent) thing that is
drawn on the screen (or a hardcopy page), and may have other associated
characteristics</dd>

<dt>window manager</dt> <dd>the piece of software which is responsible for
operating the mechanics of a GUI</dd>

<!--

<dt></dt> <dd></dd>

<dt></dt> <dd></dd>

<dt></dt> <dd></dd>

<dt></dt> <dd></dd>

<dt></dt> <dd></dd>

<dt></dt> <dd></dd>

<dt></dt> <dd></dd>

-->

</dl>



<h2>Package Structure</h2>

<p>The most important packages are shown here. There are numerous sub-
packages containing auxiliary stuff.</p>



<h3><code>Titian</code></h3>

<p>Base package, with just a few fundamental declarations (e.g. the
floating-point types <code>Inches</code> and <code>Centimeters</code>).</p>



<h3><code>Titian.Color</code></h3>

<p>The type <code>Basic_Color</code>, which holds RGBA values, and a basic
set of operations. An abstract palette type, with operations for storing
and retrieving colours, and for quantization.</p>



<h3><code>Titian.Raster_IO</code></h3>

<p>Basic functions for raster graphic calculations (points, lines,
orthogonal rectangles) and relationships (comparisons) between them.</p>

<p>The fundamental abstract type <code>Root_Context_Type</code>, which
represents anything that can be drawn on (e.g. a device, such as a video
screen or printer, or a window), and a large set of abstract primitive
drawing operations.</p>

<p>Operations include drawing the following: point marks, in a variety of
styles (dot, cross, plus, etc.); straight lines (horizontal, vertical, and
general), in a variety of styles (dashed, dotted, etc.); orthogonal
rectangles, optionally filled or hatched, with special corners; irregular
polygons (closed), and circles and ellipses (whole, partial, or segment),
optionally filled or hatched; text, in a selected typeface, in any of four
90&deg; orientations, with optional decoration (underline, etc.); bit
images (BITBLT), with image format conversion (explicit and automatic).</p>

<p>Each drawing operation supports three colour models: direct colour;
colour selector; current colour. Direct colour specifies an RGBA value; if
the video display supports only a colour palette, the colour is inserted
into the palette automatically (triggering quantisation if necessary).
Colour selector specifies an entry in a palette; a software palette is
provided if the hardware does not support one; current colour uses a 'pen',
a default colour which can be set direct or by selector. This scheme makes
it easy for the application program to use the model (direct or palette)
which suits it best, and allows an application to explicitly support both
models if it is deemed necessary.</p>

<p>The intention is that only (non anti-aliased) raster fonts are supported
by this package &mdash; more sophisticated drawing operations are provided
by the (optional) <code>Titian.Scaled_IO</code> package subhierarchy
&mdash; but the operations are designed in such a way that the font
rendering mechanism is not constrained by the interface (so a native
renderer, which might have more sophisticated capabilities, can be used by
an implementation if it would make sense).</p>



<h3><code>Titian.Components</code></h3>

<p>Three abstract component types: for a root component; for a control
component; for an interactive component.</p>

<p>A root component has a few operations, the most important of which is
<code>Draw</code>. When a component is registered with a window manager, the
window manager calls its <code>Draw</code> procedure to cause it to draw (or
redraw) all or part of itself on the manager's screen (or page).</p>

<p>A control component is a component which displays some aspect of the
application program's conceptual model, usually on a continuously updating
basis. Whenever that aspect changes, the program should call the
component's <code>Invalidate</code> procedure. When a control component is
activated, its manager calls its <code>Draw</code> procedure in response to
this invalidation. Examples of control components are: progress bar; VU
meter.</p>

<p>An interactive component is a control component which is able to gain
and lose the <dfn>focus</dfn>. Normally, a window manager allows only one
component at a time to have the focus, and directs keyboard input to that
component. Examples of interactive components are: push button; checkbox
button; radio button; menu bar/panel; scrollbar.</p>



<h3><code>Titian.Windowing</code></h3>

<p>Root window type, and operations. Two basic abstract window types: root
window; workspace window. The root window type is the root for all window
types. A simple z-order priority model is supported. A workspace window has
all the decorations of a typical application window (border/frame, title
bar, menu bar, etc.), can gain focus, and has some extra operations to
support that.</p>

<p>Every window has an orthogonally rectangular area in it (corresponding
to the 'client area' of a Windows window), called its <dfn>canvas</dfn>,
which can be set to a component. The component thus implements the canvas
of the window. Typically, window types do not need to be specialised; a
standard window will suffice, whose canvas is set to an appropriately
specialised component. Since there are many components which have other
components inside them (e.g. a panel splitter), this tends to be the ideal
structure.</p>

<p>Root window manager type, and operations. Window managers can be opened
and closed by name (like device files); not availble on some
implementations (e.g. Windows and Mac) where there is only one default
manager. There is always a default manager (which is automatically opened
if necessary).</p>

<p>The operations for a window manager include a set of standard component
constructors, providing a repertoire of essential components for the
manager. These will usually be implemented by the corresponding default
components of the manager's implementation.</p>

<p>A virtual window manager type, which provides the functionality of an
MDI window (one which allows multiple inner windows), and operations.
Constructors for: standard bare window; standard workspace window; standard
virtual window manager (MDI) window.</p>



<h3><code>Titian.Fonts</code></h3>

<p>Facilities for manipulating fonts, including opening and loading
external fonts (font files) by name, and obtaining metrics.</p>



<h3><code>Titian.Raster_IO.Text_Formatting</code></h3>

<p>Facilities for formatting text strings, including horizontal and
vertical alignment. Provides an efficient way for the application program
to 'see' the formatting, and perhaps adjust it (or to do its own
formatting), before the formatted text is drawn. Also allows text to be
formatted once and redrawn many times.</p>

<p>I think the facilities provided in this package are much better designed
(and more accurately defined) than those Windows provides.</p>



<h3><code>Titian.Components.Utility</code></h3>

<p>Provides a variety of useful facilities to help with using components.
In particular, provides horizontal and vertical <dfn>autospacers</dfn>,
which make it easy to neatly align many components (e.g. in a dialog); they
will keep their alignment even if the containing box is resized.</p>

<p>My personal preference is to code the components of a dialog by hand (in
Ada), and use autospacers to do the formatting. However, autospacers could
be used in a visual design tool (very successfully, I think).</p>



<h3><code>Titian.Raster_IO.Recording</code></h3>

<p>Provides a virtual device (a type derived from the root device type), an
in-memory container which can record a sequence of drawing commands, and
then replay them (to another device). The sequence can be saved and loaded
to/from a stream.</p>



<h3><code>Titian.Raster_IO.Imaging</code></h3>

<p>Provides a virtual device (a type derived from the root device type), a
bitmap image type, whose format and dimensions are controlled by
discriminants, which can be drawn on as an in-memory canvas, and then
itself drawn onto another device.</p>



<!--

<h3><code>Titian.</code></h3>

<p>

</p>



<h3><code>Titian.</code></h3>

<p>

</p>



<h3><code>Titian.</code></h3>

<p>

</p>



-->

<h3><code>Titian.Clipboard</code></h3>

<p>Provides all the usual functionality associated with transferring data
by clipboard. Supports different named formats, and stream I/O to read and
write data. Also provides direct support for a few basic formats.</p>



<h3><code>Titian.Scaled_IO</code> subhierarchy</h3>

<p>This package subhierarchy provides facilities for drawing continuously
scaled figures and text on a raster device, including selectable
anti-aliasing for text and lines, support for continuously scalable fonts,
continuous scaling of raster images, bezier curves, and many other advanced
functions (e.g. support for JPEG and PNG).</p>

<p>This subhierarchy is intended to be optional. It should be supported on
desktop GUIs and graphics workstations, where it will be required by
typical applications (e.g. a PDF viewer). It can be omitted, however, for
target machines where its support would be unnecessary or impractical (e.g.
an EFTPOS terminal).</p>

<p>I haven't got as far as writing the package specifications for this
subhierarchy yet, but I've a pretty good idea how it should be.</p>



</div>

-- 
Nick Roberts