[boost] Re: GUI library - another one

From: Max Motovilov (max_at_[hidden])
Date: 2004-03-03 11:12:40

"David Turner" <dkturner_at_[hidden]> wrote in message

> 1.  It should be a consistent yet thin wrapper around the platform's
> native functionality.
> 2.  It should degrade gracefully in the absence of certain features on the
> platform.
> 3.  It should be extensible through the factory pattern.
> 4.  It should couple loosely with user code - this means no inheriting
> from an abstract Window class.
> 5.  It should do what the user (programmer) expects, whenever possible
> (i.e. no leaky metaphors).
> 6.  Widgets that contain things should behave like containers, whenever
> this is practical.
> 7.  It should not use device-specific units like pixels, wherever this is
> practical.
>
> and finally
>
> 8.  It should be extremely easy to use.

I would add:

9. (really 0 in my view) It should use an extensive resource description
schema or language (for widget properties, layouts and relations) that is
either interpreted at run time or (though I like it less) compiled into code
transparently to the user. This resource description should probably be
XML-based.

An alternative for a lower-level GUI library is to _support_ such
description rather than to implement it (be designed to interoperate well
with different implementations). The danger here IMHO is that without a
resource technology built in, the trend over time will be to add enough
facilities to the library so it can function without one. In this case, why
not use Qt and save oneself the trouble?

The rationale behind making the resource schema central in the design is
that it allows to decouple the look-and-feel aspects from the code and
support graphic design part of the UI development with a suitable graphic
design tool. Forgoing code generation on the other hand, or at least making
the generated code a strictly transient entity, avoids the fallacy of CASE
systems which generate the initial boilerplate and leave the programmer high
and dry with lots of ugly unmanageable code.

One of course should be able to develop an application without using a
graphic tool (especially while the library is in development and one is just
not avqailable). But writing an XML description by hand is not any harder
than hardcoding numerous create_button() and set_window_position() calls in
C++, and the text should look nicer and be more maintainable.

10. It should not attempt to provide its own abstraction of 2D graphics.
Some level of portable graphics capability would certainly be necessary but
it should be kept to a minimum (your requirement #1 supports this I
believe). A portable 2D graphics API is worthy of its own library.

Also, speaking of (7) - in many cases it is rather hard to express
dimensions in device-independent units such as points or millimeters.
Display resolutions are still low enough to require us to consciously
consider whether to use 1 pixel wide or 2 pixel wide lines, manually prepare
icons of different resolutions instead of resizing the bitmap, etc. The
"named units" approach may help.

...Max...