Re: [boost] Thoughts for a GUI (Primitives) Library

Subject: Re: [boost] Thoughts for a GUI (Primitives) Library
From: Gwenio (urulokiurae_at_[hidden])
Date: 2010-09-10 15:42:34

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_at_[hidden]> wrote:

> Fine.
>
> Then clarify some more details please.
>
> On Wed, Sep 8, 2010 at 18:17, Gwenio <urulokiurae_at_[hidden]> 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
>