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

From: Alan Gutierrez (alan-boost_at_[hidden])
Date: 2005-01-01 07:24:32

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

    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.

    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.

    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.

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

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

    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.

    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.

    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 don't think that there'll be a Golden Spike.

--
Alan Gutierrez - alan_at_[hidden]