[boost] [gui] (Was GUI validation (was GUI Library Proposal for a Proposal))

From: Andy Little (andy_at_[hidden])
Date: 2004-12-02 03:23:36

"Eugene Lazutkin" <eugene_at_[hidden]> wrote

> Just to revive discussion about GUI allow me to offer my 2c worth. (Sorry
> for big post).
>
> Let's split GUI into two parts: G (2D graphics) and UI (user interface).
> :-)
> G can be used without UI: printing, generation of metafiles (e.g.,
> Postscript, SVG) or pixmaps/bitmaps. UI can be used without G, if only
> stock
> components are used: simple dialog boxes.

The idea of separating GUI into various conceptual areas seems good to me,
However I would have thought that the graphics primitives part must be
designed first. Graphically a window should be part of a graphical system
that deals with graphical transforms, which also opens the way for non
window elements to be manipulated generically... From the point of view of
instantiating a graphical entity it should be possible to know where and how
big it is required and in relation to what, IOW a coordinate system.

> Now we want to make all these components as light-weight as possible for
> performance reasons. Ideally they should be mapped 1-to-1 to facilities of
> underlying platform, while preserving platform independence. I don't think
> it is productive to walk original Java way and implement all widgets in
> terms of graphics primitives,

Drawing the various parts of a window, eg its border is fundamentally a
graphics operation too. Should it not be possible to implement a gui on a
simple operating system such as DOS or other simple embedded os that has no
concept of high level graphics operations? There needs to be some underlying
abstraction which does not rely on an operating system for its existence.

> First order of business is 2D geometry. Following stuff is required:
>
> 1) Point. Simple 2D entity with X and Y components. In real life at least
> two versions are required: integral (screen coordinates are integral) and
> floating point (for precise calculations).

I agree that this humble 2D entity or family is the first graphics primitive
that needs some resolution. Because they are used in so many ways a general
purpose xy_pair type is the option I have currently been using. ( Being the
2D equivalent of an int or a float) Operations addition, subtraction,
multiplication and division by a numeric.

Perhaps this whole point/size issue shows a lack of clarity regarding the
overall coordinate-system. A  'point' describes a relationship between one
entity IN another, suggesting a graph edge relation. A 'size' is a property
OF an entity  only. The observation that the difference between a 'Point'
and a  'Size' could be used to discriminate functions is valid, but when
used in a  context ( ie by finding the best model of the system)there is
less need for  pivotting (overload resolution) on particular types. As
another example...  if  screen units were one type and window units were
some other type eg  millimeters or whatever, then conversion between these
types could be  achieved automatically rather than requiring a LPtoDp
function etc.  However  this again may not be necessary if the framework
fits correctly eg using a  transform matrix as a edge property of a graph of
the relationship between graphical entities.

> Additional consideration: point should play well with native
> platform-dependent coordinate.

I dont view things quite this way. This is surely a classic case where the
concept (the What) should be considered before any particular implementation
. My criticism of current libraries in this discussion is that they have
basically started with a particular implementation and tried to abstract
from that. IOW each implementation should be a 'workaround' for the ideal
approach which provides the standard from which to work.

> Additional consideration: region should play well with native
> platform-dependent regions. Because region is relatively complex object,
> which is used mostly in specific context, it may make sense to implement
> it
> as a wrapper around native region.

I also think it would be necessary to work out the mechanics of regions
first, else one gets into implementation problems again. If the goal is
platform independence then as well as reuse, it would need to be possible to
build the mechanics from scratch.

> 5) Transformation matrix. In 2D case it can be implemented as 3x3 matrix
> or
> (to conserve cycles and spaces) as 2x2 matrix + offset vector (6 values
> total). Usually it doesn't make any sense to use integer matrix.
> Algorithms
> to be implemented: addition, multiplication. It is beneficial to have
> construction from offset vector, rotation angle, mapping from rectangle to
> rectangle (with and without preserving aspect ratio) and so on. More
> complex
> algorithms are practical as well like "zoom around given point".

This relates to the overall coordinate system. The overall graph of  spatial
relationships between windows also can benefit by using transform matrix
'edges'. This also provides a clearer framework. IOW when 'moving' or
'sizing' a graphics entity (eg window) there is a more obvious answer to the
question " in relation to what?" Objects representing transforms seem to be
a good way to go.

> Well, what are your thoughts? Discussions of UI are recurrent event in
> Boost. I saw several proposals for 2D geometry in this mail list. Authors
> of
> several GUI toolkits are frequent visitors here. Are we ripe already?

Thanks... There is a lot more interesting stuff in your post and I like
the overall tone.Would it be an idea to use the boost wiki to further the
discussion?

regards
Andy Little