"David Turner" <dkturner@telkomsa.net> 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...