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

From: Andy Little (andy_at_[hidden])
Date: 2005-01-01 13:33:55

"Alan Gutierrez" <alan-boost_at_[hidden]> wrote in message
news:20050101122432.GA24017_at_maribor.izzy.net...
>* Andy Little <andy_at_[hidden]> [2005-01-01 05:41]:
>>
>> "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),.
>
>    Consider a draw method for a spread sheet. Is there a graphics
>    element for each cell? If I load 100x10,000 workbook, do I
>    create 1,000,000 cell objects so that each of them can draw
>    themselves? No. The grid draws the cells.

Only the visible part of the spreadsheet would require to be represented
graphically of course. Even if each cell was a graphics_element this would
typically only amount to (say) 1000 elements. In practise I guess lines
representing the grid might be required and rectangular fills where
individual cells or blocks are in different colours and of course text. All
rendered (if it is out of date) when a draw request is made, So typically
the lifetime of a graphics_element is at minimum the period between  display
updates. But I would consider the above decisions to be the job of the
application designer, who hopefully would find his tools in the boost::gui
library.

>    Even if you had a grid flyweight, and create a cache of cell
>    styles, it is still easier to draw the cells by simply drawing
>    rows and columns.

Yes.. the GUI is only providing some particular graphical View on data at
one instant of time, using the artifice of available graphical facilities...
a triumph of artifice over substance.(but without this mechanism to provide
feedback to the user computers would be useless... so its such an important
area).

>    This is more than a nit. It is easy to talk about grids being an
>    application problem. But if the library is modeled soley as an
>    object tree, it gets cumbersome when it come across a rendering
>    task that cannot be so modeled.

An alternative to a tree representation would be to make them nodes in a
graph (ala Boost Graph Library).
The spatial relationship between graphics_elements would then be represented
in an graph-edge property.
To make the thing generic I guess the spatial relationship might be
represented as a transform ( eg a homogeneous transform matrix).
The transform between non-adjacent nodes could presumably also be worked out
from the above properrties. I think this is quite similar idea to a
scene-graph in 3D graphics.

>    When looking at windows, or a form like a dialog box, nested
>    aa-boxes in a tree in memory works, and that's what we are
>    modeling here, a graphics_element draws itself, but for grid,
>    document, and canvas applications, this model breaks down.

Who draws a graphical entity ( the application or the system etc) is
definitely a  fundamental part of its character. Usually the user is given
the task by the OS of drawing in the client area when prompted to do so(
thus defining client_area). In that sense the user 'owns' the client area.
The system owns ( and therefore draws) everything else. That may be a useful
distinction for 'generic' graphics elements.

>    Which is why, I think there is some other mixin. A document
>    needs to define how a button can participate in document layout.
>    If the button cannot partipiate in the z-axis defined by the
>    documet, because it participates in the z-axis of the windows
>    system for example, their is a compile time error.

I am not sure what you are saying with the z-axis  terminology.

>    An interface that makes for a document_component,
>    grid_component, or form_component, so that the boundries between
>    rendering strategies are not artificial ones like nested boxes.

The term document doesnt seem to fit here. I usually understand it to
mean a data container, without particular direct graphical display
significance.

>> 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.
>
>    Layout manager? What is your definition of layout manager, for
>    clarification.

One example would be typesetting in a word-processor.
The text and and formatting information is essentially held in a serial
container, but is
constrained to fit the paper dimensions by the layout manager. Each time the
data is modified the layout manager recomputes the absolute position that
each text character appears. And of course images and windows may also
participate in the layout. The layout manager takes care of flowing the text
around them.

>> >    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.?
>
>    This project will be unlike anything else at Boost. I'm starting
>    to feel that what I want to do does not belong here,but the
>    holidays are not over yet.

 True... I am certainly not representative of all the views on boost, in
fact I am probably very unrepresentative. ;-)

>    I can draw a dialog box using a resource designer in Win32,
>    layout my buttons and textboxes, attach a number, and then hand
>    a dialog id off to windows and saw, ShowDialog, and it will.

Thats true. However AFAIK the two requirements so far on boost::gui seem to
be

1) That is implementable in standard C++ code.
2) that it is operating_system independent, although that is a loose term
and could I guess mean pretty much anything in practise.

>    Then I'd like to bind event handling to each control on the
>    dialog, also identified by an ID. This event handling ought to
>    be uniform with all other library event handling.
>
>> 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.
>
>    I see that a lot of people here feel the way you do.
>    Primitives and events.

Something like what Reece Dunn has layed out in the [gui] Big Picture
thread. Sounds like this is more low level than you would like, however The
bottom up approach of designing the lower level components first although
slower is more robust IMO. Test the low level components first and then
build the high level stuff on top of that. I dont really like this, but the
problem is that there is no common set of low level components across
platforms,. Without this I suspect that we would be swimming in macro jam.

>    There is probably a need for something so simple. I'd like to
>    continue to participate in this discussion, but I don't know
>    that it is going to ultimately be something I want to work on.
>    This doesn't mean that I don't want to share work, research, or
>    ideas with Boost.
>    I am working from the application back to the OS, and I don't
>    think my direction will meet with an OS direction, because I
>    always see the OS forward direction fall short.

 I guess that a project like this will require all the help it can and then
some, and  working code demonstrating the concepts  is going to be the most
persuasive factor in the direction that this library would take.

>    I don't think that there'll be a Golden Spike.

nor a magic bullet... :-)

regards
Andy Little