ANNOUNCE - graphics package

[Joachim Durchholz]

Vlad Dumitrescu wrote:

> From: "Luke Gorrie" <luke@REDACTED>
> 
> One possible show-stopper that I see is handling circular message paths, which
> may lead to deadlocks.

This is unavoidable, and independent of the library design.

Here's the canonical example:

You have two input fields A and B, and they are supposed to always sum 
up to 100.
Nothing easier than that: handle any event that may change A's field 
value, have that event processed, then send an event to B so set its 
contents to (100 - A's value).
The problem is that an event that causes B to change its contents will, 
in turn, send a message to A to update that value.

There are various ways to break such a loop.

One way would be to provide a high-level "field contents has changed" 
message, and have the framework check whether the contents really 
changed before sending the message. (Since this example is a relatively 
common situation in real GUI dialogs, this would even make sense, though 
that's not a general solution.)

Another possibility is to detect the loop. If the GUI library finds that 
the same set of messages is being sent between a given set of controls, 
it can let them crash.
MS Windows actually does that. I once had such a message recursion, and 
found that the recursion would break at level 20 or so. (That was a 
mighty surprise because this behaviour was undocumented... and it 
doesn't work for all messages :-((( )

In all cases, it's absolutely essential that, for every piece of code, 
there's a full documentation on what messages it may send, and under 
what circumstances this is done. Otherwise, programmers have a hard time 
determining whether their message code is inadvertently creating a loop.

In practice, this kind of documentation is the first thing that's 
incorrect. So some general guidelines are in order:
1) Divide the messages into abstraction levels. A message of a higher 
abstraction level may trigger only messages at lower abstraction levels.
2) If a message must trigger another message at the same or a higher 
abstraction level, this fact and the precise set of trigger conditions 
must be documented. Alternatively, one could make sure that the source 
code for all such triggers is easily found, either by requiring 
registration in a central place (downside: all the hassles of central 
registration that one would avoid), or by requiring a special (easily 
greppable) form of message send (downside: works only if source code is 
available - true for ex11, but not true once companies start making 
custom controls).

Regards,
Jo
--
Currently looking for a new job.