[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[no subject]
- To: (BUG LISPM) at MIT-AI
- Subject:
- From: RMS@MIT-AI
- Date: Mon ,20 Feb 79 14:23:38 EDT
MOON@MIT-AI 02/17/79 04:53:27 Re: Windows
(There is a copy of this message in the file AI: MOON; WIN >)
I'd like to see the usual fashion for windows to be to have an outline (box) if and
only if the window is not using the whole screen (excluding the who-line, i.e.
SCREEN-{X,Y}{1,2}). In the present situation, lisp listeners never have
outlines, which is a problem when doing split screen hacking, and supdup
and editor windows always have outlines, although usually they are the only
thing on the screen, which just wastes scren space.
Actually, lisp listeners made the correct way do have outlines; only
the initial one fails to. Conditional outlines as described here can
be got by changing the :EDGES<- and :MARGINS methods for
WINDOW-WITH-BOX-CLASS, I think.
The initialization of windows has some problems, particularly with edges.
The :BORN method for WINDOW-CLASS always clobbers the edges to the whole screen.
I'd like to see an explicit protocol that specifying instance-variables in
the :NEW message always over-rides defaults supplied by the :BORN method
(that is, :BORN methods should be written to respect user-supplied initial
values in the instance variables.)
Done, in the specific case.
The default edges for a window should not be the whole screen; instead they
should come from the Lisp listener window "under control of which" the window
was created.
This might be convenient if windows were going to be created by the
user by typing (<- FOO-CLASS ':NEW) at a lisp listener, but I think
they should be created by something like JERRYB's menus. If that is
the normal way of doing things, there will be no need for this
feature.
PEEK and the who-line should be improved (in some unspecified way) to let
you find out more about processes and windows. There should be an escape W
keyboard command as on ITS.
I have a PEEK that displays in a window that almost works. If you
want to hack this, hack it instead.
I think it would be easier to use the mouse for random graphic input (e.g.
color editors) if there was a special form (WITH-MOUSE-FREE-OF-WINDOWS . body).
Inside the scope of this, the mouse tracker process would track the mouse, moving the
X cursor and updating the variables MOUSE-X and MOUSE-Y, but it would not
do anything special for button clicking and would not give control to any
windows the mouse happened to pass over. This would be implemented as
LET-GLOBALLY of a flag looked at by the mouse-process, plus a SETQ of
MOUSE-RECONSIDER (is that what it's called?) and a MOUSE-WAKEUP to kick the
mouse out of the control of any window it's in initially.
This is yet another job for a function to evaluate a special variable
in a stack group's environment. Then it can be done by binding.
I think I'd probably rather see labelled windows put their label outside
the outline rather than inside as now. Perhaps there should be a global
variable that controls this? I'd like to see a feature to have ragged
edges on windows, in connection with the scroll bar (I think this once
existed in EINE.)
I think only a couple of methods need to be changed for this:
:EDGES<- and :MARGINS in WINDOW-WITH-BOX-CLASS.
Rather than have a variable, I would ask the user just to redefine
them, just because there are only two of them.
(If we had a variable for the margins list, we could cut it down to
one).