[boost] Re: Re: Re: Re: Re: [gui] GUI Taxonomy

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.

regards
Andy Little