[boost] Re: boost Windowing Toolkit

From: James Grandy (jgrandy_at_[hidden])
Date: 1999-12-13 09:58:52

Hi,

Sorry to come late to this discussion; my DSL connection was (and still
is) out.

I don't think adding a windowing toolkit to boost is a good idea; it's
hard to come up with an integrated cross-platform framework that everyone
is going to be happy to use -- too many design tradeoffs at every level
of the job. However, there are certainly design patterns that have
emerged over the years, initially in the various Macintosh frameworks
(MacApp, PowerPlant), that may be worth adding to boost. There are also a
number of smaller opportunities to provide platform-independent wrappers
for concepts that seem to be relatively universal across platforms. I'd
love to see boost incorporate a set of these, just as it seeks to
incorporate fundamental building blocks for other programming tasks.

Examples I have in mind. I'm sure there are more, but these are the ones
I use in my own framework:

- a message-passing facility that can tunnel OS-specific events. The
design pattern I use is the one in the Be OS Application Framework, with
the following general class structure:

class message {
public:
        typedef uint16  id_t;
};

template<typename T> class data_message {
public:
        typedef T       data_t;

class message_handler {
public:
        void    handle_message(message *msg);
};

class message_dispatcher : message_handler {
public:
        void    dispatch(message *msg, message_handler *target);
        bool    message_available(void) const;
        void    pulse(void);
        void    add_target(message_handler *hdlr);
        bool    remove_target(message_handler *hdlr);
private:
        set<message_handler*>   targets_;
        deque<message*>         msgs_;
};

In the Be OS, message_dispatcher is called message_looper because it runs
in its own thread. Here, the client has to periodically call pulse() to
get messages dispatched to their handlers; this could be wrapped in a
thread to emulate the Be-style facility. The data_message derived class
isn't in Be, but is useful for wrapping OS-specific messages, as well as
for sending simple messages with a single data payload.

MacApp has a very similar set of messaging classes. In my experience,
this sort of library is efficient and flexible enough to support the
common UI messaging requirements.

- classes for point, and rectangle. I template by scalar type, to support
"device" coordinates, which are usually integers, as well as "view"
coordinates, which can be integers (shorts or longs), fixed point
numbers, or floats. Conversion to platform-specific structures is
efficient here (even if coordinates have to be swapped), since the data
structures are so small.

- types that support keyboard state -- a bitmask for modifier key state,
a way of determining whether a key is being pressed, and conversion to
Unicode characters, all cross-platform.

- a class that encapsulates what I call "input state" -- mouse position,
keyboard state, etc. An instance of this class would be generated
whenever an interface event is raised, and passed around as a way of
encapsulating access to the input state at the time of the event. A
similar class is possible that encapsulates output state -- coordinate
system transforms, platform-specific references to drawing context, etc.
Even if the input/output attributes are platform-specific, encapsulating
those details in one object is very useful when building event-driven
frameworks -- you can pass the object around without knowing what's inside it.

- a standard (XML?) way of describing control hierarchies, with a
cross-platform API for writing a control hierarchy to disk, and reading
one in from disk. Adobe's new desktop publishing application, InDesign,
includes in its SDK a cross-platform resource compiler called ODFRC,
except it doesn't use XML.

- a cross-platform (XML again? Unicode definitely) way of storing
strings, with an API for accessing string libraries keyed on locale (e.g.
French, Canadian, Russian, etc.).

I think there is potential to build a larger set of interface tools, but
I agree with Dave Abrahams that any such "framework" should use C++
idioms, and make use of namespaces to hide platform-specific details. I
strongly believe that the most successful UI framework is no more than a
composable set of cleanly separated sub-libraries; too much integration
is bad, in my opinion. I'd love to see generic programming used to design
a set of generic interfaces that support UI programming; I'm not yet sure
what it would look like, but I'm convinced it's worth the effort.

jim

ps I might be willing to submit my implementation of the messaging
library and the point/rectangle classes, if there is interest.

-- 
James Grandy             Colorfield Digital Media, Inc.
jgrandy_at_[hidden]                   1.412.422.7516