[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Oct 9 09:28:00 1999 
Subject:problems with rclib and rcmenu packages 
From:Aaron Sloman - see text for reply address 
Volume-ID:991009.01 

I previously announced RCLIB, the pop-11 based GUI toolkit available
at the freepoplog site

    ftp://ftp.cs.bham.ac.uk/pub/dist/poplog/freepoplog.html

in the rclib/ and rcmenu/ subdirectories, and also
available in these packages: rclib.tar.gz, rcmenu.tar.gz

WARNING:
The RCLIB package is based on the rc_graphic package which is part of
the Pop-11 X library. However, if you have started to use rclib/rcmenu
and then try to use rc_graphic "neat", e.g. expecting rc_start() to
create a new window, you can get nasty surprises.

This has happened to some of our students who now use the RCMENU control
panels for controlling Ved, etc. and then may trip up when they look at
TEACH RC_GRAPHIC and try the examples.

To avoid problems, once RCLIB is in use, create windows only using the
procedure

    rc_new_window_object(x, y, width, height, setframe) -> win_obj;

as described in HELP RCLIB

Then before giving a drawing command, or using rc_start() to clear a
window, make sure that the appropriate window is current, e.g.

    win_obj -> rc_current_window_object;

I guess a macro should be introduced to simplify the above, e.g.
something like this??

    SETWINDOW win_obj

PLANS:

Because the above can confuse students, I shall attempt to overhaul the
RCLIB package, and especially the bits of the RCMENU library that create
control panels to make sure that they leave the state "clean", to reduce
the risk that drawing commands introduced in the RC_GRAPHIC teach files
mess up the last control panel created, etc.

The changes may take a few days.

All this is a consequence of my (bad?) decision to build the
RCLIB and RCMENU packages on top of rc_graphic so that procedures
already defined for use with rc_graphic could be used in the new
packages.

The pre-existing rc_graphic procedures do not require a window object to
be specified explicitly, as it is assumed that there is always a
"current" one, whose state is represented by global variables.

The alternative approach would require every drawing procedure to be
changed to take an explicit window argument. Maybe that's what I should
have done.

Anyhow, for now my plan is to address the problem by modifying some of
the RCLIB and RCMENU procedures, and to change RCLIB so that
LIB RC_WINDOW_OBJECT redefines some of the rc_graphic procedures,
notably

    rc_new_window(width, height, xloc, yloc, setframe);
    rc_start();

to reduce the risk of unintended interactions.

Comments and suggestions welcome, of course.

In the long run it may be necessary to produce a "grown up" version of
RCLIB using *only* drawing procedures which always required a window
object as argument.

(NOTE: the Pop-11 library LIB RC_CONTEXT, distributed with Poplog
since about 1990 or earlier, was intended as a partial solution to the
problem of managing different windows with rc_graphic procedures.
It should never be used alongside RCLIB, whose solution is totally
different, based on the object oriented methodology supported by
Objectclass.)

Aaron
===
-- 
Aaron Sloman, ( http://www.cs.bham.ac.uk/~axs/ )
School of Computer Science, The University of Birmingham, B15 2TT, UK
EMAIL A.Sloman AT cs.bham.ac.uk   (NB: Anti Spam address)
PAPERS: ftp://ftp.cs.bham.ac.uk/pub/groups/cog_affect/0-INDEX.html