Boost logo

Boost :

From: Andy Little (andy_at_[hidden])
Date: 2005-01-01 04:56:52

"Alan Gutierrez" <alan-boost_at_[hidden]> wrote
>* Andy Little <andy_at_[hidden]> [2004-12-31 13:36]:

>> Hmm I see what you are saying ... The os privately owns the draw
>> function
>> for some (system) elements. So it doesnt need to be part of the interface
>> except for user drawn elements
> Or library drawn elements (a nit).

Yes.... on reflection the draw() function in the previous post was a red
herring, and is closer to implementation as you say though IMO could also be
classified as a particular type of graphics_element based on who owns its
graphics real-estate. Nevertheles Who does the drawing is probably a key
part of the make up of a particular graphics_element, and presumably it
should be possible in an ideal world to change an element at run_time, from
say a dumb rectangle ( explicitly drawn), to a window (drawn by the OS) to
an embedded curses application (though see final paragraph),.

The main idea behind the graphics_elements is to provide a single mechanism
to express the spatial relationship between diverse entities in some 2D
space(s).There is also something like a 3rd dimension (the Z-order) to
consider in this ( as has been mentioned in another post) . I conjecture
that there should be some common framework to express this. One needs surely
to be able to measure distances and know extents of graphics_elements,
regardless of their darker purpose, in order to implement a layout manager
for example.

> Also, I'm not creating boundries across applications, or
> platforms, such specialization might occur within a single
> application on a single platform.
> I might write a bitty spread sheet for Palm OS that uses Boost
> rendered elements on a grid, but still use resource bound
> elements for all other forms.

As far as the resource-bound elements that you mention goes I have to admit
that I'm not too sure what these are. 'Resource' could mean many things,
however it does sound like this is the same issue of sorting out the
graphics real-estate using some 'spatial-framework' as sketched above and
then providing some means of trading ownership between the application, the
OS and other applications, but doesnt this make the boost:GUI itself start
to look very much like an OS itself.?

I was hoping that the scope of the project would be kept small enough to be
realistic to achieve without a Herculean effort. Bottom line is all I really
considered on gui was client area graphics,. ( client area meaning the bit I
as the user own.... the canvas ) though the ability to make elements in the
client area 'active' would be a bonus. Of course once I started to make
active_elements, I would probably be well on the way to creating my own
simple gui (which would also work on very basic OSes , with windows etc
though restricted to the client area of the app IOW I lease the client
area.from whatever OS(Sound familiar .... Java) . The advantage of this
approach is that I am not relying on an OS to supply eg my button. I can
construct it entirely from scratch, though can presumably replace my
construction with something suitable supplied by an OS where possible. The
bottom line requirements on the os are basically some drawing primitives and
user input feedback etc. Hmmm... I suppose it really boils down to what the
boost::gui actually should be, and what is realistic.

Andy Little

Boost list run by bdawes at, gregod at, cpdaniel at, john at