From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,a875d9649dde34e3 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!not-for-mail From: Nick Roberts Newsgroups: comp.lang.ada Subject: Re: GWindows and a future home for it Date: Fri, 01 Oct 2004 20:52:40 +0100 Message-ID: <2s5qs9F1f2cu5U1@uni-berlin.de> References: <2s2k77F1em754U1@uni-berlin.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: news.uni-berlin.de nkhmW0p5N63jGezv4ZJ6zgUqZAMkpNelg56VwfiLY7Q+AMOQk= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en In-Reply-To: Xref: g2news1.google.com comp.lang.ada:4532 Date: 2004-10-01T20:52:40+01:00 List-Id: 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.

Titian Summary

October 1, 2004

Nick Roberts

...

Quick Glossary

orthogonal rectangle
a rectangle whose sides are parallel with the vertical and horizontal axes (abbreviated to orthorect)
RGBA
red, green, blue, and alpha (one minus the percentage of how much the corresponding background should show through)
component
a self-sufficient (to some extent) thing that is drawn on the screen (or a hardcopy page), and may have other associated characteristics
window manager
the piece of software which is responsible for operating the mechanics of a GUI

Package Structure

The most important packages are shown here. There are numerous sub- packages containing auxiliary stuff.

Titian

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

Titian.Color

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

Titian.Raster_IO

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

The fundamental abstract type Root_Context_Type, 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.

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° orientations, with optional decoration (underline, etc.); bit images (BITBLT), with image format conversion (explicit and automatic).

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.

The intention is that only (non anti-aliased) raster fonts are supported by this package — more sophisticated drawing operations are provided by the (optional) Titian.Scaled_IO package subhierarchy — 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).

Titian.Components

Three abstract component types: for a root component; for a control component; for an interactive component.

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

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 Invalidate procedure. When a control component is activated, its manager calls its Draw procedure in response to this invalidation. Examples of control components are: progress bar; VU meter.

An interactive component is a control component which is able to gain and lose the focus. 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.

Titian.Windowing

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.

Every window has an orthogonally rectangular area in it (corresponding to the 'client area' of a Windows window), called its canvas, 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.

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).

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.

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.

Titian.Fonts

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

Titian.Raster_IO.Text_Formatting

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.

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

Titian.Components.Utility

Provides a variety of useful facilities to help with using components. In particular, provides horizontal and vertical autospacers, 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.

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).

Titian.Raster_IO.Recording

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.

Titian.Raster_IO.Imaging

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.

Titian.Clipboard

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.

Titian.Scaled_IO subhierarchy

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).

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).

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.

-- Nick Roberts