On Wed, Sep 8, 2010 at 11:59 AM, Yakov Galka <ybungalobill@gmail.com> wrote:
On Wed, Sep 8, 2010 at 17:34, Gwenio <urulokiurae@gmail.com> wrote:
Since there is a lot of discussion about the disign for high level parts for the library, I prepose the discussion be split into two. The low level disign only needs to know the requirements of the other parts are, and the higher parts only need to know what is possible. The reason they should be separated is the design of the high level components is a hot topic that is not going to be easily resolved.
Low-level parts aren't going to be solved easily either. An even bigger problem is that we don't have a clear separation of what is high-level and low-level. Anyway they are related so you should take in mind either level when you design the other.
On Wed, Sep 8, 2010 at 14:32, Mathias Gaunard <mathias.gaunard@ens-lyon.org>wrote:
On 02/09/10 22:17, Gwenio wrote:
Now for a start for discussion on event handling.
*Event Loop:*
<snip />
*Event Handling:*
<snip />
All of this is already dealt with by Boost.Asio, which provides a powerful unified way of dealing with asynchronous events.
1) Boost.Asio doesn't support native OS message queue (correct me if I'm wrong). 2) Event handling in GUI is not necessarily asynchronous. It's more on how to design the message passing from one component to the other in an extensible way with some additional requirements.
Although I agree that it would be better if it was compatible with Asio.
Low level: the part the allow interaction with the system and cannot be replaced without knowing what the system is. 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.