"Alan Gutierrez" <alan-boost@engrm.com> wrote in message news:20050101122432.GA24017@maribor.izzy.net...
* Andy Little <andy@servocomm.freeserve.co.uk> [2005-01-01 05:41]:
"Alan Gutierrez" <alan-boost@engrm.com> wrote
* Andy Little <andy@servocomm.freeserve.co.uk> [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