ANNOUNCE - graphics package

Joachim Durchholz joachim.durchholz@REDACTED
Mon Jan 19 20:25:17 CET 2004

Luke Gorrie wrote:
> Joachim Durchholz <joachim.durchholz@REDACTED> writes:
>>I don't think that's true. What's a control in other languages just
>>gets mapped to the existing objects, which means that every object
>>gets a *huge* API.
> Terrible. Everything on my whole computer that deals with text has
> this _awfully_ big API that includes everything I could possibly want
> to do with text...
> ;-)


However, you don't need this API for tasks like, selecting text from a 
list or displaying a button. But you need other things.
And that's the point at which I usually make a break for a new widget.

Actually I think Emacs is just overdoing a step that's generally in the 
right direction; my personal widget list goes like the following:
* Area (with border effects) (does layout of child widgets)
   (is the only control that has layout-wise children)
   (with some useful routines for adding scrollbars)
* Text input field (with a read-only mode)
* Pushbutton (includes checkboxes)
* Slider/scrollbar
* Noninteractive graphics elements (lines, rectangles, bitmaps)
* A toolkit for building new types of widgets,
   which mainly consists of a framework for "draw" routines,
   a framework for routine screen positions to widget components,
   and a way to identify the borders of a control
   (it's pretty sure that somebody wants to custom-make a big
   red round "Emergency Stop" button - with this he can).

The list is already longer than that of Emacs, and I'm still not sure 
that I have covered everything, but I don't see that anything can be 
dropped; these widgets all behave in fundamentally different ways:

Area does child layouting; no other widget does this.
Text input fields do text layout and keyboard input.
Pushbuttons have a fixed size, a handful of states that are directly 
tied to the state of mouse buttons or keyboard keys, and slightly 
different appearance in each state.
Sliders and scrollbars have dragging capabilities.
Noninteractive graphic elements don't interact at all. Strictly 
speaking, read-only text widgets fall into that category as well (but 
there's much to be said for making every label amenable to selection 
with the mouse and copying - I'm sick and tired of having to retype the 
contents of error message boxes...)
... and the toolkit isn't really a widget :-)

Currently looking for a new job.

More information about the erlang-questions mailing list