[freesci-develop] Port problem investigation

[Lars Skovlund]

Hi all!

I've been looking at the port problems in Jones and some other games,
and I've sort of figured it out. Three kernel functions are involved
in the (re)drawing of SCI widgets: DrawControl, HiliteControl and
EditControl. Like most drawing functions, they obey the currently set
port. Therefore it is vital that the correct port be set at the time
of the call. You can probably guess that this isn't done in the
problematic cases. Why?

The key to answering this question lies in FreeSCI's widget
subsystem. When DrawControl is called, it creates a new widget whether
it already exists or not. It is my understanding that this is normal,
and the widget system is supposed to handle it by destroying the old
widget. So far so good. 

Obviously, SSCI did not use a widget system. This difference is the
source of a few problems already (the computer monitor in PQ2 springs
to mind). The kicker here is that all three functions may at some
point redraw the control if there is a need AND that FreeSCI
implements this in the same way in all of them, as described above.

It turns out that EditControl is called continuously by the script's
widget handling code, without the above precondition being met
explicitly. Usually, this is not a problem, because the right port
has been set elsewhere, and nothing comes in between to change that 
(see (2) below). Thus our own widget code is able to handle the
situation. In Jones, however, the wrong port is set and our code does
not detect the situation. Therefore, the new copy of the widget is
allowed to survive, and since it belongs to a different port, is
placed at the wrong location.

The problem is exacerbated by two things:

1. The fact that EditControl does absolutely nothing with icon
controls in SSCI, while FSCI explicitly redraws them. One fix might
therefore be to prevent EditControl from redrawing controls it's not
supposed to. However, redraws ought to be innocuous, and the solution
does not account for "normal" situations, and it is therefore
unacceptable in the long run.

2. Jones employs a class called the KeyMouse, allowing you to
control the game from a keyboard. This is not the usual way keyboard
control is handled (not even in SCI1), but a Jones particularity. As
art of its processing it is meant to switch the window manager port
temporarily, saving the old one in a property. Due to a bug in the
class, this field gets clobbered (also in SSCI), but because of (1),
this has no consequences in SSCI.

I see the solution as being some kind of change to our widget handling
code, but exactly what to change (different widget creation
semantics? hash table of previously drawn controls and corresponding
ports on the interpreter side of things?), I'm unsure of. 

Lars