Number: 1753
Date: 2-Aug-84 12':53':24
Submitter: JonL.pa
Source: JonL.pa
Subject: Want status region/window on screen similar to MIT''s "WhoLine"
Assigned To:
Attn: Masint,vanMelle,JonL
Status: Open
In/By:
Problem Type: Design - UI
Impact: Annoying
Difficulty: Hard
Frequency: Everytime
Priority: Perhaps
System: Operating System
Subsystem: Other
Machine: 1132
Disk:
Lisp Version: 30-Jul-84 21':47':55
Source Files:
Microcode Version: 5124
Memory Size: 4096
File Server:
Server Software Version:
Disposition: '
["Sannella.PA" "14-Aug-84 14':55':45" Description':]
Description: Some thoughts collected over the past few months on need for more visual feedback as to what Interlisp-D is doing':'
'
1) Want processes to keep account of their "run" time.'
'
2) Want a window, or "locked out" region of the screen, which continuously displays status information such as indicated below. Since some of this display could interfere with pagefault code, it seems that it may have to be special-cased, rather than just as an option on the window system.'
2a) Who owns the TTY (i.e., processname of the ttyprocess)'
2b) short state description of each of several processes; e.g, "blocked'
for I/O", "blocked for TTY process", "running", "misc. awaitEvent"'
Since not all processes could fit in the space available, the user could'
select which three or four he wanted in the display.'
2c) an exponentially-decaying picture of where the cpu time is going'
(Cedar''s little process window comes to mind also)'
2d) short summary of network connections (i.e., timed out, active, etc)'
2e) short summary of storage conditions; e.g., # of mds pages still available,'
% of arrayblock cells allocated but unused, CONS rate (?)'
2f) what is the connected directory'
'
---------------------------------------------------------'
Here''s a few pieces of mail on the matter':'
'
'
Date': 20 Jul 84 16':19 PDT'
From': Masinter.pa'
Subject': Re': PROMPTFORWORD behavior poll'
In-reply-to': Nuyens.pa''s message of 20 Jul 84 15':23 PDT'
To': Nuyens.pa'
cc': LispCore↑.pa, Card.pa, Henderson.pa, DMRussell.pa'
'
most other systems (including MITLisp''s, Tajo, and Cedar) have some kind of system status display. The problem is that some pieces of system status (paging behavior, GC) change dynamically at times when the window system is not in a ''safe'' place to modify. Changing the cursor generally IS safe. There are some possible technical solutions': we could optionally reserve a piece of the screen for status display and not let windows overlap it, and put status display there.'
'
We could put some special hack in the window system where the status display window would only update if it wasn''t obscured. '
'
What would the status display show? GC activity, what process has the tty, process(es) waiting for input? Should these be options you could turn on and off, e.g. with an "options" menu?'
'
'
From': stefik.pa'
Subject': Re': AR#1529 During DWIM operations, change cursor to DW/IM'
In-reply-to': masinter.PA''s message of 20 Jul 84 13':03':25 PDT (Friday)'
To': masinter.PA'
cc': stefik.PA, LispCore↑.PA'
'
More suggestions':'
'
How about an optional display window that could be invoked to give dynamic information about what''s running and how much time is going to different processes. DWIM info could be shown in the same window.'
'
Cedar has something like this now. In the past couple of weeks, the Colab programmers have come upon extreme sluggishness at times. They could, of course, use SPY. The question that arises is "just what is the system DOING right now?" In this application of LISP, we are using 2 machines (soon to be 3) with EVALSERVER, and there are many processes running. '
'
That we cannot easily SEE what is going on leads to a style of making weak hypotheses about what is happening, without any easy or immediate way to verify them.'
'
I think that this must be a problem for anyone using multiple processes.'
'
This need to visualize is related to DWIM from a naive programming point of view. In both cases programs are invoked or running for which we are not explicitly responsible. Like communication processes, DWIM fires up and uses cycles, often without informing the user. '
'
Perhaps a package and display like the "space allocation" could be invented, that inserted hooks (with advice?) into DWIM and the process-switching mechanisms.'
'
Mark '
'
'
Date': 23 Jul 84 19':31 PDT'
From': JonL.pa'
Subject': Proposal for new system windows'
To': LispCore↑'
'
In line with the various proposals for some more status indications, I''d like to see the usages of PROMPTWINDOW split up into three categories, and apportioned out to new windows':'
1) "weak" error messages -- those that don''t enter a BREAK'
loop (would prefer a scrollable text window)'
2) help messages -- the kind of thing that the MENU system does with'
the PROMPTWINDOW now. maybe this could be expanded.'
3) status messages -- might include some variant of the ubiqutous '
file server not responding messages and Lafite and/or TEdit doing '
this or that. Could also contain messages like '
"Process GRINDTAPE wants the TTY" '
so that a user could distinguish the case where a program is '
willing to hang forever until its process becomes the TTY process '
from the case where it wants to *demand* some attention. This'
window might have regions to accomodate randoming printings as '
well as continuous graphic status output (e.g., time spent in each'
process a la Cedar, storage dynamics, etc.)'
'
I''d propose to call these windows':'
1) ERRORSTREAM'
2) PROMPTWINDOW'
3) STATUSWINDOW'
Initially, these could be provided as globalvars, but all pointing to the same PROMPTWINDOW.'
'
Any comments?'
'
-- JonL --'
'
-----'
'
Date': 23 JUL 84 23':04 PDT'
From': MASINTER.PA'
Subject': Re': Proposal for new system windows'
To': JonL, LispCore↑'
'
In response to the message sent 23 JUL 1984 1931-PDT by JonL.pa'
'
Seems like there are a lot of fuzzy cases where one would get confused and used for the other. Or maybe I just don''t have it clear in my mind.'
'
We seemed to have gone thru a stage of "overloading the promptwindow" and are now going thru the reverse stage. Things might be simpler if most messages went to T, and we could just mess around with what the TTY window was for each process?'
'
-----'
'
Date': 24 Jul 84 19':25 PDT'
From': JonL.pa'
Subject': Re': Proposal for new system windows'
In-reply-to': MASINTER.PA''s message of 23 JUL 84 23':04 PDT'
To': MASINTER.PA'
cc': JonL.PA, LispCore↑.PA'
'
I''d certainly like to press for error messages not going *only* to T; current behaviour has them creating a separate break window (in somecases), or being printed in a non-text-scrollable window (e.g., PROMPTWINDOW) where they are soon lost. '
'
For example, the compiler prints out a lot of messages of the type "I am now compiling FOO, a function of three arguments A B and C", and this is intermixed with serious warnings like "GRUMBLE used free"; there seems to be little alternative now to DRIBBLEing all compiler output, and perusing it carefully.'
'
At the other end of the spectrum, SPACEWINDOW is approching something like a STATUSWINDOW; if we combind that with your/my suggestion to reserve a portion of the screenbitmap for non-occludable status information . . . '
'
-- JonL --'
'
'
'
'
Workaround:
Test Case:
Edit-By: Sannella.PA
Edit-Date: 14-Aug-84 14':55':49