I propose changing "Drawing" to "Rendering", because this a more common term in computer graphics. But I'm no native speaker, so I'd like to hear some comments on this.

Sounds good - in those cases where we really can separate rendering from UI.

Another problem is that in "real world" APIs the above subcategeories are often mixed up a bit. Have a look at the following APIs resp. Haskell libraries:

Clean ObjectIO Direct3D FRAN FranTk Fudgets Functional Metapost GIFWriter GLUT GTK+ Haven HGL Inventor MOTIF OpenGL Pan TclHaskell Win32 X toolkit intrinsics Xaw Xlib Xmu

Where should we put them in the new hierarchy? Do we need more/other subcategories?

A bunch of these are tied to particular systems and provide both rendering and UI functionality. It seems that splitting these would be rather artificial - they look separate but neither is useful without the other and neither can be combined with other systems. Even the HGL -which would split reasonably well- would look a bit funny since you can only use HGL primitives to render onto HGL windows. The only way round this that I can see is to come up with a standard API for interaction between the UI part and the rendering part so that you can combine any UI with any renderer. It's not clear what this would look like. For example, would device contexts (aka graphics contexts) be explicit as in Win32 and X11 or would they be implicit as in HGL? What is clear though is that they would not be the Win32 API, the X11 API, the Motif API, etc. since they are all tied to one particular backend. -- Alastair Reid reid@cs.utah.edu http://www.cs.utah.edu/~reid/