"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),. 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