The low level part should avoid implementing a list control. Event handling would translate system messages, and then pass them to a specified handler to be processed. I have spent some time thinking over how the library should be broken up. Primative: - Is not a GUI in and of itself. - Provides a system independent way to build a GUI. - Should be designed to avoid limiting the types of GUI that can be created and the systems it can be ported to (with that order of priority). - Should be usable with any library (both system and third party) that runs on the same system it is currently being build for (e.g. it should be possible to render with GDI, OpenGL, and DirectX when built for Windows). The code to wiring the library to others will not be provided; only the means to do so are included. Native: - Supports the creation of GUIs that fit with the system. - Could possibly provide more than one way to create "native" GUIs (e.g. a set of native controls and a set of functions to draw in the native style and get color/metric information). Component: - Defines common controls, and ways extend and customize them for the application. Primatives would be independant of the other two, and if it is designed properly then it will not affect the design of them. The reason primative and native are listed separately when they both deal with the system is in the intrest of keeping the scope of the project doable. Ideally at least one mechanism provided by the native unit would be able to intagrate with the component library. I have read some discussion about having an away to discribe the needs of your application programatically, and then have a GUI front end created at runtime. Such would be separate for the above catagories if it was created and they would merely provide one possible back end. On Wed, Sep 8, 2010 at 2:33 PM, Yakov Galka <ybungalobill@gmail.com> wrote:
Fine.
Then clarify some more details please.
On Wed, Sep 8, 2010 at 18:17, Gwenio <urulokiurae@gmail.com> wrote:
Low level: the part the allow interaction with the system and cannot be replaced without knowing what the system is.
According to your definition the low-level part should implement the controls with system independent interface. Consider a grid control (aka list-view with details style). What interface should it have? Should it store the data (with list_view::set_item_data()) or ask the owner to provide the data when needed by a callback?
The event handling components should translate the system messages, determine which control they are for, and pass it on to where ever the application or library as indicated it should be sent.
Recall message capturing/bubbling phases discussed before. Should the low-level event handling component implement them or perhaps it'll be broken into low-level component that merely captures system messages and a high-level component that actually transfers them to their destination (implementing capturing/bubbling and non-system events on the way)? _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost