Re: [freesci-develop] Port problem investigation

[Christoph Reichenbach]

Hi,

[DrawControl, HiliteControl, EditControl]
> 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.

That is correct.

> 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).

Are you referring to the odd behaviour of the "cursor" there, or is there
something else that I'm missing?

[...]
>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.

All right. Do I understand this properly in that the widget should be drawn to
whichever port it was associated with the first time one of {DrawControl,
HiliteControl, EditControl} was invoked on it? If so, is there a way of
destroying this association, e.g. by destroying the port?

> 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.

Well, re-drawing something which is currently drawn below something else with
the same priority (!) is inherently not innocuous.

> 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. 

If I understood the problem correctly, the solution would be both: Widget
creation semantics would be updated to associate the VM object address with a
port. When the VM object is destroyed, the binding is also destroyed. If
present, such a binding then overrides the port-to-draw-to for the subsequent
widget generation.

  Updating the widget would also be an option, but I'm not sure what the
semantics are supposed to be if you completely change a control structure in
between calls to EditControl-- will the old control leave visual artifacts, or
will it be destroyed?

-- Christoph