Date: 29 Aug. 1982 11:05 am PDT (Sunday)
From: Taft.PA
Subject: Read-only documents
To: TiogaImplementors^

I'd like to suggest a slightly different semantics for read-only documents in
Tioga:

(1) Being read-only should not prevent Tioga's copy of the document from being
edited; it should just prevent it from being Saved on top of the original. That is,
the user must explicitly Store the document on a different file when finished
editing; and the Save menu item should not appear until he has done so.

(2) It would be nice to have read-only local documents with the same properties.
Sample application: forms. In Bravo, I occasionally forget to assign a new name
to an edited form and end up Putting it back on top of the original form. If
forms were read-only, this would not be possible.
 Ed

Date: 21 Sept. 1982 6:06 pm PDT (Tuesday)
From: Stewart.PA
Subject: Menus problems
To: TiogaImplementors^
cc: Stewart

Menus.ReplaceMenuEntry does not seem to work when the replaced entry is the last in a list. (e.g. Split in Typescript Viewers).

Menus.ReplaceMenuEntry should return the old entry

Either MenuEntryRec should not be PRIVATE or there should be a "Call this menu entry" procedure.

 -Larry

Date: 18-Oct-82 18:15:18 PDT
From: Taft.pa
Subject: Confusing feedback from Save
To: TiogaImplementors^

It is very confusing that the feedback from Save (requesting confirmation of the Save) persists even after Save has been confirmed, and in fact even after it has completed.

This is far from being the only instance of feedback persisting inappropriately long, but it is the most confusing I have encountered to date. Perhaps there should be a systematic convention for removal of prompts from the feedback line. For example, maybe the Viewers operation which displays the prompt should require specification of when the prompt should be removed, with the default being the next keystroke or mouse click event or something. [Time limit --SM]
 Ed
Date: 8-Nov-82 15:58:03 PST
From: Maxwell.pa
Subject: Rollback+Idle for public dorados
To: Levin, McGregor


-------------------------------------
Date: 8-Nov-82 15:14:59 PST
From: ramshaw.pa
Subject: quitting conviently off of public Dorados
To: Maxwell
cc: ramshaw.pa

John, it would be minor convenience for users of public Dorados if there was some way to invoke the combination {RollBack; Idle} with one click. When leaving a Dorado that I have dirtied up, I would like to go through the RollBack sequence to guarantee that the machine is clean for the next person. But I don't want to wait until the Rollback completes, and I don't want the next person to just start working logged in as me (which is likely to cause her some confusion when she next tries to store a file on an IFS, say).

Lyle

------------------------------------------------------------
Date: 13-Nov-82 18:35:53 PST
From: teitelman.pa
Subject: typescript suggestion
To: tiogaimplementors^
cc: teitelman.pa
Reply-To: teitelman.pa

There ought to be an inline in typescript called IsATypescript. I have currently defined this to be RETURN[viewer.class.flavor = $Typescript] but you might change that without my knowing about it. [viewer.class.data.tsInfo#NIL --SM]

warren

Date: 20-Dec-82 13:43:56 PST
From: Horning.pa
Subject: Autoscroll deficiency
To: Teitelman, McGregor
cc: TiogaImplementors^, Horning.pa

I have inferred the following intended behavior for typescripts:

They scroll to keep new text visible if the end of the typescript was visible at the start of the output, otherwise not.

However, I observe the following problem: if a typescript's height is smaller than ScrollBottomOffset (something that often happens to me in viewers like FTP and Walnut), then they don't autoscroll at all.

It would seem reasonable for autoscrolling to go MIN[ScrollBottomOffset, ViewerHeight]
(or even MIN[ScrollBottomOffset, ViewerHeight/2]), rather than not scrolling at all when
ViewerHeight < ScrollBottomOffset.

Jim H.

Date: 20-Jan-83 16:54:26 PST
From: teitelman.pa
Subject: positioning icons
To: maxwell
cc: tiogaimplementors^, Swinehart, teitelman.pa
Reply-To: teitelman.pa

John,

Scott says that there is a way, though not clean, of exchanging icons on the display. Be that as it may, here are a couple of other points relating to moving/positioning icons:

(1) when I exchange an icon with a viewer using Dan's hack,
what really happens is that the corresponding icon is opened in the place of the viewer, and the corresponding viewer is closed. This is not the same as exchanging, as the new icon may very well pop up somewhere else. If the facility were available, I would code this so as to really exchange the two, i.e. have the icon that was closed appear in the same position as the one that was originally selected. In this way, if the user wants to manage his screen realestate so as to always keep one of two icons in a particular spot, and the other open, he can.

(2) It would also be nice to be able to point at an icon and move it to a new location. In particular, I would like to be able to move the icon over so that spaces opened up, and conceivably use these spaces as hints to help me find certain icons. As is, you have to play a modified version of the fifteen puzzle in order to get your icons positioned right.

warren

Date: 24 Jan. 1983 2:03 pm PST (Monday)
From: Lamming.PA
Subject: ViewerOPs
To: TiogaImplementors^
Reply-To: Lamming

There needs to be a function which does the opposite of UserToScreenCoords.
MouseInViewer does too much!

Date: 25-Jan-83 17:14:09 PST
From: teitelman.pa
Subject: ViewerEvents suggestion for next release
To: tiogaimplementors^
cc: teitelman.pa
Reply-To: teitelman.pa

Add a clientData: REF ANY field to type of EventProc and a clientData argument to RegisterEventProc. This will enable several different eventProcs, e.g. one for setInputFocus and one for killInputFocus, to share some state.

warren

Date: 29-Jan-83 14:26:01 PST
From: Taft.pa
Subject: Unintended formatting
To: TiogaImplementors^
cc: Taft.pa

I have been using Tioga a lot during the past month to edit Maxc software. It is truly wonderful except for one thing: occasionally some Tioga formatting gets put in unintentionally. I don't know whether this is the result of my issuing formatting commands accidentally or due to bugs in Tioga and related software (I'm suspicious that the EditTool's Substitute command inserts Tioga formatting spontaneously) In any event, the result is very annoying, since a Tioga formatted document is unusable on Maxc. I realize I can fix this by means of the WritePlain command, and I have been doing so, but it is really a nuisance.

This is a problem with using Tioga to edit any non-Cedar files, i.e., files intended for consumption outside Cedar. I have the following suggestion. Tioga should require special confirmation before inserting any formatting into a previously unformatted document. This should apply only to documents loaded from files, as opposed to NoName documents created from scratch. That way, plain-text documents will remain plain-text unless the user says otherwise after an explicit warning.

I also have a related suggestion, which I may have made before. When text is copied from one viewer into another, its formatting information is copied with it. This is fine if both documents use the same style, but can cause considerable confusion if they use different styles. I suggest that Tioga should require special confirmation before inserting text that uses a style not previously referenced from the destination document.
 Ed
Date: 31-Jan-83 10:40:18 PST
From: Horning.pa
Subject: Roll-down menus?
To: TiogaImplementors^
cc: Horning.pa
Reply-To: Horning.pa

I was talking to Larry Rowe at the SPLISS program committee meeting about Lisa. (As a consultant, he's been using one for several months.)

He says that one reason that the one-button mouse isn't as intolerable as might be expected is the way menus are set up:
 DOWN over the NAME of the menu causes the menu itself to "roll down" below the name on the screen. The cursor can then be rolled down to the desired item, which is activated by UP. (He also notes that he uses CTRL combinations in preference to menus whenever possible.)

While I wouldn't want to adopt this scheme in general, it occurs to me that it might be a very nice option for submenus like Places, Levels, and Boot. It would help to reduce the tension between long-term consumption of real estate and slow access to submenu items. Would it mesh well with the Viewers paradigm?

Jim H.



Date: 10-Feb-83 10:58:56 PST
From: Horning.pa
Subject: Abbreviations
To: TiogaImplementors^
cc: Horning.pa

It is somewhat of an annoyance that in order to have private abbreviations, I must either edit the standard abbreviations associated with a style, or create a private style.

Is there any reason not to allow "layered" abbreviation definition, much like layered TIP tables, so that I could keep my private abbreviations in a private file (or files), identified by a .profile option? I would settle for one global set, or for one set per style, whichever seems more natural to you.

Jim H.


Date: 23-Feb-83 16:28:06 PST
From: McGregor.pa
Subject: Tioga Bugs
To: McGregor

Kill the secondary selection when viewer destroyed!


Date: 25-Feb-83 16:17:16 PST
From: teitelman.pa
Subject: ctrl-shift A
To: tiogaimplementors^
cc: teitelman
Reply-To: teitelman

does not work when at end of node. If i can control-A at beginning of node to join the node to the previous one, why can't I do same thing with ctrl-shift A at end?

warren


Subject: distinguishing captions
Date: 3-Mar-83 10:24:38 PST
From: teitelman.pa
To: tiogaimplementors^
cc: teitelman
Reply-To: teitelman

John,

I think Andrew said he talked to you about this,but it would be very nice if there were a way to use distinguished patterns in captions, specifically to distinguish action areas on the client from action areas in cocedar, but there might be other applications as well. I think what I would like to see would be something like the following:

allow the client to specify a 4X4 repeatable pattern which you then lay down in the caption only in those areas not covered by characters. In other words, things like grey are not particularly useful if they cover the whole background area, because then you can't read the name of the caption. So you can either paint the caption all grey, (or striped or whatever), and then when putting down the characters specify white on black background, or paint exactly as you do now, and then when you get done...

I think we could probably get this in immediately (i.e. for 4.0) if you would agree to do it via a property list entry, the same as we do now for icon labels. This has the attraction that since it is not going to be used for most viewers, we don't have to pay for it in the data structure, and we don't have to wait for interface changes, but can experiment right away.

warren

Subject: Middle bugging menus
Date: 3-Mar-83 9:54:21 PST
From: lamming.pa
To: TiogaImplementors^
cc: Maxwell
Reply-To: lamming

How about a user profile option to disable the middle-button feature on menus - I don't like it!
  9-Mar-83 Taft.PA Comments
Date: 9 March 1983 8:19 am PST (Wednesday)
From: Taft.PA
Subject: Comments
To: McGregor

Following up on our discussion the other night, in which I stated that I would not use comment properties in programs until they were guaranteed to be visibly different from non-comments:

I would be happy with an outcome in which all italicized text was treated as comments. That is, it would be the italic look itself and not some accompanying property that caused the compiler to ignore it. This would also mean that free-standing comments and line-ending comments could be treated the same way.

A similar convention is used in Sil and works very well.

 Ed
 17-Mar-83 kolling.pa hole
Date: 17-Mar-83 12:21:14 PST
From: kolling.pa
Subject: hole
To: cedarsupport^, tiogaimplementors^
cc: kolling
Reply-To: kolling

There appears to be a problem with the interlock between saving and dirtying a viewer contents. If you click Save, and then type ahead an edit while the Save is going on, generally it subsequently works correctly, but sometimes after the save the edit takes effect but the system and header believe the viewer is clean.

Karen
6-Mar-83 Taft.PA Mesa formatting
Date: 6 March 1983 12:13 pm PST (Sunday)
From: Taft.PA
Subject: Mesa formatting
To: TiogaImplementors^
cc: Taft

The control-M command, if applied to a document with Tioga node structure, takes a stand-alone comment explicitly indicated by "--" and converts it into a node with a comment property and with the "--" stripped off. I very much dislike this behavior.

I use explicit "--" because I refuse to have the semantics of my Mesa programs be dependent on invisible properties. (I'm also extremely nervous about the possibility of getting the comment property accidentally applied to non-comment nodes without my knowledge, though I don't believe this has happened to me yet (how can I know for sure??)).

Please leave explicit comments the way they are, and just apply "c" looks to them, the same as you do for line-ending comments.

Also, I notice that in some cases the "k" look is applied not just to keywords but to adjacent punctuation, e.g., the " = " in "TYPE = RECORD". This isn't a big deal, but having two sizes of "=" scattered around looks a bit peculiar.

 Ed
6-Mar-83 Taft.pa Hyphen versus minus
Date: 6-Mar-83 15:38:21 PST
From: Taft.pa
Subject: Hyphen versus minus
To: TiogaImplementors^
cc: Taft.pa

Having never written programs in a variable-width font before, I've just noticed a minor problem with which I'm sure many other people are familiar already. The character which Mesa thinks of as minus sign is actually hyphen, and prints that way. The result looks a little peculiar in expressions, since it is much narrower than (for example) the plus sign.

I think it's probably not reasonable to change Mesa to use the real minus sign character (control-X). This is both horrible to type in and raises compatibility problems.

Is there some clever thing that can be done with formats and looks that will cause hyphens appearing in code (but not in comments) to be printed as minus sign instead?
 Ed
 23-Mar-83 lamming.pa Edit Macros
Date: 23-Mar-83 9:36:42 PST
From: lamming.pa
Subject: Edit Macros
To: TiogaImplementors^
Reply-To: Lamming

I want to make an edit macro using the edit tool that copies keywords to the front of a file, one per line.

In the edit tool I did the following:
left bugged (lb) Looks this gives me both Text and Looks options
lb Match Literally to get Match as Pattern
lb Begin
Right bugged (rb) Target
typed <look> k, followed by @**
lb Search
lb SaveSel-A
lb SaveForPaste
lb Delete
lb Prev
lb Paste
types control CR
lb RestoreSel-A
lb End
and got the following message in the message window:

 
Not all events still recorded. Some missing at start
The edit macro contained the string
SaveSelectionA SaveForPaste Delete PreviousPlaceholder Paste Break RestoreSelectionA
Could this be caused by the fact that my edit history length is set to 2 - as per Rovner's recent message

        Mik
 24-Mar-83 donahue.pa TEditSplit
Date: 24-Mar-83 9:41:06 PST
From: donahue.pa
Subject: TEditSplit
To: McGregor
cc: donahue

It would be nice if TEditSplit.Split returned the viewer it created doing the split, so I could copy some properties to it.

Jim D.
 27-Mar-83 teitelman.pa more on splitting
Date: 27-Mar-83 18:54:14 PST
From: teitelman.pa
Subject: more on splitting
To: tiogaimplementors^
cc: teitelman
Reply-To: teitelman

I found it useful to define a procedure MapViewers (don't like the name) which takes a procedure and applies it to a viewer and all of its splitees. You might want to include something like this in ViewerOps.


warren
 27-Mar-83 teitelman.pa stewart's address fault
Date: 27-Mar-83 17:06:12 PST
From: teitelman.pa
Subject: stewart's address fault
To: tiogaimplementors^
cc: Stewart, teitelman
Reply-To: teitelman

Clicking "Show" in the EditHistory tool without having filled in the "since" field causes an IOImpl.EndOfStream. Aborting then causes an address fault.

I pursued this, with particular interest in the address fault, because the EditHistory Tool should be checking for the EndOfStream error when it calls GetInt (or looking to see if the field is empty or whatever). The stack at the time of the endofstream error is:

&1 WalkStack InputImpl.GetCedarScannerToken
&2 WalkStack InputImpl.GetInt
&3 WalkStack EditToolBuilderImpl.GetInt
&4 WalkStack EditHistoryImpl.DoShow
&5 WalkStack ButtonsImpl.ButtonPusher
&6 WalkStack ButtonsImpl.EntryButtonsNotify
&7 WalkStack ButtonsImpl.ButtonsNotify
&8 WalkStack InputFocusImpl.MasterButtonProc
&9 WalkStack TIPMatcher.MatchProcess

After I click abort, I do get an AddressFault and the stack looks like:

&12 WalkStack IncreekImpl.CopyIncreek
&13 WalkStack TIPMatcher.MatchProcess

MatchProcess is trying to call CopyIncreek with self: NIL and template: NIL.

The relevant line of code in MatchProcess is [] ← ClassIncreek.CopyIncreek[user.parseInfo.inCreek,
user.parseInfo.localCreek]


warren
 28-Mar-83 teitelman.pa split viewers
Date: 28-Mar-83 12:51:17 PST
From: teitelman.pa
Subject: split viewers
To: tiogaimplementors^
cc: teitelman
Reply-To: teitelman

I don't know if you consider this a bug or not, but when I split a viewer, the new viewer does not inherit the old ones icon (although it does get all the right menu configuration). This is a problem for the userexec, because all splitees have the typescript icon. I can program around this by registering an event for splitting, but I thought I'd report it anyway.

warren
 28-Mar-83 teitelman.pa split
Date: 28-Mar-83 12:52:46 PST
From: teitelman.pa
Subject: split
To: tiogaimplementors^
cc: Teitelman
Reply-To: teitelman

ViewerEvents.ViewerEvent should include split as a type.

warren
 25-Mar-83 Atkinson.pa Re: Two Notifiers
Date: 25-Mar-83 15:59:45 PST
From: Atkinson.pa
Subject: Re: Two Notifiers
In-reply-to: Stone's message of 21 March 1983 10:06 am PST (Monday)
To: Stone.pa
cc: Teitelman, McGregor, Atkinson, Rovner, Levin, Birrell, Maxwell

Forking of two notifiers because of a breakpoint in a NotifyProc is an annoying but (I think) understood problem. It is due to informational signals coming from the basic event handler (breakpoints). The informational signal causes a notifier to be forked, then the StallWatcher process (which looks for stalled processes) causes a notifier to be forked.

There are two fixes that should be considered. First, the Viewers stuff should be able to recognize that it does not need to fork a new notifer if the process in question has already had a notifier forked. Second, informational signals should not be used for breakpoint and uncaught signal stuff, in particular because they interact badly with conditional breakpoints.

In the meantime, to turn off informational signals, use:

 ← AMEventsImpl.informing ← FALSE

That's what I do.

Russ
 25-Mar-83 teitelman.pa Re: 4.0 bug: Opening a non-existent file
Date: 25-Mar-83 16:07:17 PST
From: teitelman.pa
Subject: Re: 4.0 bug: Opening a non-existent file
In-reply-to: Your message of 18-Mar-83 16:44:16 PST
To: McGregor.pa
cc: Teitelman

"Looks like you might know something about this..."

Actually, I think this is your bug, or maybe my misunderstanding. Here is what I am doing:

IF (entry ← Menus.FindEntry[viewer.menu, Atom.GetPName[l.first]]) # NIL THEN Menus.ReplaceMenuEntry[menu: viewer.menu, oldEntry: entry];

The AddressFault is coming out of the following line of code in MenusImpl.ReplaceMenuEntry:

menu.lines[l].xPos ← menuHLeading;

The thing that makes this particular situation is special is that the viewer in question had a second menu line added to it, by performing Menus.SetLine[menu: viewer.menu, line: 1, entryList: UserExecPrivate.secondMenuLine]; and then had this line removed by performing:


Menus.SetLine[menu: viewer.menu, line: 1, entryList: NIL];

It then had a menu item added by performing:

Menus.AppendMenuEntry[menu: viewer.menu, line: linesUsed - 1, entry: Menus.CreateEntry[name: Atom.GetPName[l.first], proc: ResponseProc, clientData: l.first, fork: FALSE]]; where linesUsed = Menus.GetNumberOfLines[viewer.menu], and it is when I attempt to take the entry away that it gets into trouble.

The problem could be that I am trying to remove the last element in a line, or it could have to do with the fact that there is a NIL line. I am willing to put in a workaround if you can tell me what. Maybe instead of using GetNumberOfLines to find the last line, I ought to check and see if that line is empty or not.

warren
 27-Mar-83 Taft.PA Overloaded buttons
Date: Sun, 27 Mar 83 10:08 PST
From: Taft.PA
Subject: Overloaded buttons
To: CedarDiscussion^

A number of Cedar tools have chosen to conserve screen real-estate by multiplexing several functions onto each button in the menu. Left, middle, and right clicks of a button have different meanings, and for a few buttons the meaning is further modified by the shift and/or control keys.

As the number of tools has increased, there has been an explosion of independent meanings assigned to the different mouse buttons and control/shift mouse button combinations. There is no consistent user model for these assignments. I am finding it increasingly difficult to remember all of them, and I think the situation has gotten rather badly out-of-hand.

I have an alternative proposal. The "primary" function of a button (i.e., the one corresponding most directly to the button's label) should be invoked by the left mouse button, as it is now.

All the other, "secondary" functions should be collected together in a subsidiary menu, which is brought up when you click the button with the middle mouse button. I have in mind something along the lines of the Smalltalk/Tajo-style pop-up menu, though I imagine there are other possible arrangements that would also be satisfactory.

I don't have any systematic use for the right mouse button. Perhaps the most frequently-used secondary function can be invoked by it. Users can learn about this if they want to, but they don't have to since the secondary function is also available in the subsidiary menu. For completeness, the subsidiary menu should also include the primary function.

Examples:

Compile: left click: compiles file
  middle click: brings up menu {Compile, Bind, CompileAndBind}

Set:  left click: sets breakpoint at selected place
  middle click: brings up menu {Set, BreakEntry, BreakExit}

In order for this scheme to have any benefit, all tools must be converted to use it. This suggests that the Menus interface should be changed along the following lines.

Current:

ClickProc, MenuProc: TYPE = PROC [parent: REF ANY, clientData: REF ANY ← NIL, mouseButton: MouseButton ← red, shift, control: BOOL ← FALSE] ;

CreateEntry: PROC [name: Rope.ROPE, proc: ClickProc, clientData: REF ANY ← NIL, documentation: REF ANY ← NIL, fork: BOOL ← TRUE, guarded: BOOL ← FALSE] RETURNS [entry: MenuEntry] ;

Proposed:

ClickProc, MenuProc: TYPE = PROC [parent: REF ANY, clientData: REF ANY ← NIL, function: ATOM] ;

CreateEntry: PROC [functions: LIST OF ATOM, proc: ClickProc, clientData: REF ANY ← NIL, fork: BOOL ← TRUE, guarded: BOOL ← FALSE] RETURNS [entry: MenuEntry] ;

The primary name of the button is the print name of the first atom in the functions list, and clicking it with the left mouse button calls proc[..., function: a] where a is that atom. The second atom in the list is similarly associated with the right mouse button. The middle mouse button brings up a subsidiary menu consisting of the entire functions list, and releasing the middle mouse button over one of the buttons in that menu calls proc[..., function: a] where a is the corresponding atom.

I think this scheme also subsumes the purpose presently served by the "documentation" argument, so I have omitted it.

Comments?

 Ed
 28-Mar-83 paxton.pa Re: Overloaded buttons
Date: 28-Mar-83 9:00:15 PST
From: paxton.pa
Subject: Re: Overloaded buttons
In-reply-to: Taft's message of Sun, 27 Mar 83 10:08 PST
To: Taft.pa
Reply-To: Paxton
cc: CedarDiscussion^

Ed,

YES! We should have a standard convention for menu buttons. And as Warren points out, we should still be able to include accelerators for "non-primary" operations. How about the following proposal:

Holding CTRL down when click a menu button brings up a pop up menu (no matter which mouse button is used, so you just have to remember CTRL). The pop up menu stays up as long as CTRL is held down, and while it is up you cannot click anything else (perhaps this restriction can be relaxed, but do we really want several pop-up menus up at once?). You can do multiple operations in the pop-up menu, but as soon as you release CTRL, the menu goes away. Perhaps the menu should include a HELP entry that defines the different menu commands. This would take care of the desire for documentation without dedicating a mouse button.

There will be a standard mapping from entries in the pop up menu to buttons as an accelerator for use by "expert" users. For example,
 
 1st menu entry available by LEFT button
 2nd available by MIDDLE button
 3rd available by RIGHT button
 4th by LEFT-SHIFT
 5th by MIDDLE-SHIFT
 6th by RIGHT-SHIFT

This proposal satisfies the need for a standard convention. It is upward compatible with the current user-interface. It is easy to explain to new users. The mapping from pop-up entries to mouse buttons is simple so users will quickly learn to use the accelerators. It supports new users without penalizing experts.

Let's do it.

--Bill
 28-Mar-83 To: Taft.pa Re: Overloaded buttons
Date: 28-Mar-83 9:17:19 PST
From: McGregor.pa
Subject: Re: Overloaded buttons
In-reply-to: Taft's message of Sun, 27 Mar 83 10:08 PST
To: Taft.pa
cc: CedarDiscussion^
Reply-to: McGregor

Ed;

Thanks for your pop-up menu proposal-- I think it has quite a bit of merit.

When designing a menu system, I try to keep the following criteria in mind:

1) How simple is the user model? i.e. how easy is it for the user to remember/guess the action that will result from invoking a command with the various comninations of mouse buttons and shift keys.

2) How much functionality is provided for the cost of the resources? Perhaps you could measure this in units of commands per screen area or some such.

3) How fast and easy is the mechanism to use for experts (assuming you've already paid the overhead to remember all the functions)?

The current scheme does pretty well by metrics (2) and (3), but as you point out, pretty lousy on metric (1). A pop-up scheme for the "secondary" functions would really improve (1) at some cost of (3) since now the user has to scan the list visually to find the function and has no way to "click ahead". (As an example, the various Tioga operations on 'Clear' and 'Get' are commands that are very useful to "click ahead").

As an additional thing to think about, I have some inclination to make us more compatible with the Xerox product 2-button mouse, in which case the pop-up scheme becomes valuable to preserve the functionality we have today.

Command schemes are interesting to me and I'd be interested in other people's thoughts...

Scott.
 28-Mar-83 Lampson.PA Re: Overloaded buttons
Date: 28 March 1983 12:33 pm EST (Monday)
From: Lampson.PA
Subject: Re: Overloaded buttons
In-reply-to: Your message of 28-Mar-83 9:00:15 PST
To: Paxton
cc: CedarDiscussion^

I like this proposal, and have one small extension to propose. Different users may
well have different ideas about what is common, so it would be nice if the
choice of operations invoked by buttons could be set in the profile, as Warren
suggested. How about a list of atoms which determines the order of menu items
(and hence, by your proposal, the meaning of button clicks)? The only problem
I can see with this is that it will be hard to use a Cedar with an unfamiliar
profile, but this probably happens seldom, and it's always possible to use the
menu for everything in case of confusion.

If there is going to be a standard HELP entry, I think it should be in a standard
place in each pop-up menu, namely first, and your table of menu-button
correspondences should be shifted by one:
 
 2nd menu entry available by LEFT button
 3rd available by MIDDLE button
 4th available by RIGHT button
 5th by LEFT-SHIFT
 6th by MIDDLE-SHIFT
 7th by RIGHT-SHIFT

About two-button mouse compatibility: could we standardize on
Left+Right=Middle? A user with a two-button mouse could use a profile which
minimizes the use of this combination.
 28-Mar-83 Taft.PA Re: Overloaded buttons
Date: Mon, 28 Mar 83 09:52 PST
From: Taft.PA
Subject: Re: Overloaded buttons
In-reply-to: "Your message of 28-Mar-83 9:00:15 PST"
To: Paxton
cc: CedarDiscussion^

Bill, I would be very happy with your version of the proposal.

I have one comment to make about a point that was brought up by both Warren and Scott, with regard to "buttoning ahead". It is currently the case (and rightly so) that feedback from clicking menu buttons is immediate, even if the action invoked by the button is deferred. I see no reason in principle why this should not extend to the operation of a pop-up menu. That is, CTRL-click on a menu button should bring up the pop-up menu immediately, and the button selected from it should have its action queued for later execution, just the same as is now done for top-level buttons.

 Ed
  3-Apr-83 Shore.PA Wedge Your World via Tioga
Date: 3 April 1983 3:02 pm PST (Sunday)
From: Shore.PA
Subject: Wedge Your World via Tioga
To: TiogaImplementors^.pa
Reply-To: Shore

Try hitting CTRL-← at an empty node. It wedges the world (and I lost all my
edits). I did it to try to clear the Format of the node, and I think it should have
that semantics.

--Andy
 15-Apr-83 teitelman.pa A proposal for eliminating the need for a Level...
Date: 15-Apr-83 14:49:13 PST
From: teitelman.pa
Subject: A proposal for eliminating the need for a Levels menu
To: cedardiscussion^
cc: TiogaImplementors^
Reply-To: teitelman.pa

How about having a single Levels button work as follows:
left click = firstlevel,
right click = alllevells,
middle click = more levels,
shift middle click = fewer levels.
I almost never use fewer levels and I bet most people are the same. In any case, using shift to mean "the opposite" is consistent with a number of other buttons.

This would free up the need for a levels menu entirely.

warren
 29-Apr-83 kolling.pa split viewerf headers
Date: 29-Apr-83 17:43:27 PDT
From: kolling.pa
Subject: split viewerf headers
To: cedarsupport^, tiogaimplementors^
cc: kolling
Reply-To: kolling.pa

Splitting a viewer while it's in Saving state, fairly often creates the second viewer on the New Version state.

Karen
  9-May-83 teitelman.pa a request
Date: 9-May-83 12:54:44 PDT
From: teitelman.pa
Subject: a request
To: tiogaimplementors^
cc: teitelman
Reply-To: teitelman.pa

I may have sent this, but in the same vein that it is now possible to specify the icon label independent of the viewer name, I would like to be able to specify the caption text independent of the viewer name. A good example of this is the [New Version] which is done via a special bit. I would like to be able to put in the caption Foo.mesa - [needs to be compiled] or some such, but have ViewerOps.FindViewer succeed when given "Foo.mesa". I would be happy with something like the current scheme for handling icon labels, i.e. to have the paint proc check the property list for the property $Caption or some such.

warren
 11-May-83 teitelman.pa menus, etc.
Date: 11-May-83 9:51:33 PDT
From: teitelman.pa
Subject: menus, etc.
To: tiogaimplementors^
cc: teitelman
Reply-To: teitelman.pa

Here are some more suggestions for your file:

(1) It would be nice if there were some way of including in the menu area of a viewer fields to be filled out, e.g. if the menu had some more of the flexibility of a container.

(2) alternatively, if one had a container viewer, with one of the areas a tioga document, it would be nice if the menu are could still look like a tioga document. In other words, currently, the menu expects that its data is a tioga document. It would be nice if there were some way of telling it where the tioga document was, or some convention, such as last child of last child of last child... Walnut ran into some of these problems when it used to have a feedback area as part of a sender.

(3) It would be nice if there were a convenient way to piggyback on existing tioga menu lines, such as a way of saying add this entry to the places menu for this viewer, without having to know what line the places menu was on. It would also be nice if there were some way of saying bring up the places menu.

(4) then there are all of the issues in about resolving the discrepancies between ViewerOps.CreateViewer and TiogaMenuOps.Open, the latter not allowing you to specify iconic, or not to paint, etc., whereas the former does not get the default menus right.


I also have a collection of small interface changes for tiogaops that I have been holding onto.
 13-May-83 Horning.pa Display anomaly
Date: 13-May-83 10:34:01 PDT
From: Horning.pa
Subject: Display anomaly
To: TiogaImplementors^, CedarSupport^
cc: Horning
Reply-To: Horning.pa

This morning, while forwarding a message, I observed behavior that I haven't seen for a long time: Bogus text displayed in the wrong place in the viewer. Alas, it's not repeatable, or I'd send you a protocol. I had filled in the Subject: and cc: fields, and Nexted to the CoveringMessage, when I noticed that it was apparently followed by part of the cc: field of the forwarded message (starting from "c:", to be precise). When I opened another viewer in the column to compose this message, the bogus line disappeared, so it was apparently in the bitmap, rather than the underlying data structure.

Jim H.
 20-May-83 Horning.pa Reminder wish
Date: 20-May-83 12:13:37 PDT
From: Horning.pa
Subject: Reminder wish
To: Teitelman
cc: McGregor, Horning

Warren,

Sometimes I don't see flashing reminder icons, because they are on the second row, flashing away behind a viewer. This tends to reduce the utility of the system, because I most need reminding when I am in the middle of something, which may well have filled my icon row.

I can think of a couple of ways around this:

- Give bottom-row priority to flashing icons.

- Have the Reminder system always keep an icon up, which I can place by the usual rules, and which Reminder replaces by the (first) flashing icon at the right time. The nominal icon could be a notebook or something, and could open up to Reminders.txt, if desired.

Jim H.

 28-May-83 MBrown.pa proposed change to semantics of Get button / Op...
Date: 28-May-83 22:18:57 PDT
From: MBrown.pa
Subject: proposed change to semantics of Get button / Open exec command
To: TiogaImplementors^
cc: MBrown

&4 open howtousewalnut.msg
Created Viewer: HowToUseWalnut.tioga
{Viewer - class: Text, name: HowToUseWalnut.tioga}

 ("not found" in message area, and screen flashes).

We've been around on this several times. How about this: if directory lookup for x.y fails, then lookup x.mesa and search for y. But don't lookup for x.* where * matches the filename extension completion list (which is searched on "Open x", the name x having no "." and the file x being nonexistent.)

 --mark
 29-May-83 MBrown.pa TS oddity
Date: 29-May-83 11:10:20 PDT
From: MBrown.pa
Subject: TS oddity
To: TiogaImplementors^
cc: MBrown

I have noticed strange behavior of the insert caret in typescripts when the insert point is near the bottom of the typescript. Sometimes the caret blinks one line too high, but with correct horizontal position. Sometimes it blinks one line too high, and at this end of that line. Scrolling makes the caret appear in true position. I think I can repeat this in my current checkpoint, but it seems to depend sensitively on the collection of viewers open in the right column.

 --mark
 30-May-83 MBrown.pa Repainting bug
Date: 30-May-83 20:57:38 PDT
From: MBrown.pa
Subject: Repainting bug
To: TiogaImplementors^
cc: MBrown

I am running Cedar 4.2.69 of 27-May-83 18:10:39 PDT.

In case you are looking for a repeatable case in which the new repainting code fails, I have one (scrolling my new version of AMIO.mesa leaves a few partial scan lines of trash on the screen.)

 --mark
 31-May-83 teitelman.pa newFile event
Date: 31-May-83 12:34:59 PDT
From: teitelman.pa
Subject: newFile event
To: tiogaimplementors^
cc: teitelman
Reply-To: teitelman.pa

Just a reminder, that there is currently on single event corresponding to the creation of a viewer on a new file, which can occur either by the user clicking Open, or clicking New and then typing the filename followed by linefeed, or by clicking Get in an already existing viewer, etc.

warren
  1-Jun-83 MBrown.pa Learning styles
Date: 1-Jun-83 15:40:11 PDT
From: MBrown.pa
Subject: Learning styles
To: TiogaImplementors^
cc: MBrown

I have noticed that it is difficult to learn styles. I am not referring to the style concept, but to the content of a particular style (say Slides.style.)

Here are some operations that might help:
 given a document (or a branch, or whatever), return a list of all formats used in the document.
 given a document and a format, return a node in the document that has that format. (maybe given a document and a node and a format, return the next node after the given node in the document that has that format)

It is entirely possible that the EditTool lets me do this today, but I am not enough of an expert to drive it.

 --mark
 13-Jun-83 Maxwell.pa ButtonsImpl.EntryButtonsNotify
Date: 13-Jun-83 11:58:10 PDT
From: Maxwell.pa
Subject: ButtonsImpl.EntryButtonsNotify
To: McGregor
cc: CedarSupport^.pa
Reply-To: Maxwell.pa

The test:

IF data = NIL THEN RETURN;

in EntryButtonsNotify should be moved out into the procedure ButtonsNotify since "data" is what gets locked upon entry. (ButtonsImpl: CEDAR MONITOR LOCKS data USING data: ButtonData) If data is NIL, the opcode that attempts to lock the monitor will get an address fault.

John.
  6-Jun-83 vanleunen.pa good?
Date: 6-Jun-83 11:42:23 PDT
From: vanleunen.pa
Subject: good?
To: TiogaImplementors^
cc: vanleunen
Reply-To: vanleunen.pa

Middle-clicking an icon makes it open, and shift-middle-clicking an icon makes it both open and consume its whole column. Reasoning by analogy, I had some hope that, since left-clicking <-- or --> in the viewer menu makes the viewer move to a different column, shift-left-clicking <-- or --> in the viewer menu might make the viewer move to a different column and consume that whole column. Didn't. Would it be good if it did?
 28-Jun-83 Swinehart.pa Re: Some hints for private Tioga styles
Date: 28-Jun-83 8:45:07 PDT
From: Swinehart.pa
Subject: Re: Some hints for private Tioga styles
In-reply-to: "Your message of 14-Jun-83 17:24:46 PDT"
To: Beach
cc: TiogaImplementors^, Swinehart
Reply-To: Swinehart.pa

The edit tool was a stroke of genius from the standpoint of manifesting the largest number of available actions in the smallest amount of space, and the most quickly. But for any given action it is of course not the most convenient way one could imagine providing that action.

When it comes to looks, formats, and styles, I find myself wishing I had something like the Star property sheets. A property sheet could be a new viewer that would contain an excerpt from the edit tool, whose fields would be filled in already with the current values. The viewer could also have buttons that would yield higher and lower-level property sheets (looks leads to formats and styles, and so on), as in Star. The viewer would automatically refer to the text sequence or node from which it was derived, so the result would be a lot less clicking. It would be compatible in some sense with the edit tool, too, so I think it would fit in OK.

Aside on edit tool: How about putting into a second menu line some buttons which, when clicked, would scroll the tool data to a selected section (search, sort, format, style, edit ops, and so on?) At the cost of one or maybe two lines of additional height at the default size, this would substantially reduce the number of times I have to grow the edit tool window or laboriously scroll it.

Thanks for listening,
Dan
 25-Jun-83 Stolfi.PA wish: Viewer defaults in User.profile
Date: Sat, 25 Jun 83 01:28 PDT
From: Stolfi.PA
Subject: wish: Viewer defaults in User.profile
To: McGregor, Maxwell
cc: Stolfi

I believe the suggestions below could be implemented in just a few man-months, and would save me (and probably two or three other users) several miliseconds per year. (No thanks, please; you are welcome.)

1. Add to user.profile entries like

Viewers.LeftColumnWidth: 6 inches
Viewers.NumberOfIconRows: 2

2. Have a some means to specify through the user.profile some default parameters for Viewers of certain kinds, e.g.

Viewers.EditTool.Openheight: 2 inches
Viewers.FileTool.Iconic: False
Viewers.Tioga.Position: Top
Viewers.Chat.Column: Right

One could get the same functionality now by having each tool interrogate the user.profile for pertinent entries before creating its Viewers, but this leads to lots of duplicate coding.

I don't have a good idea of how to specify the Viewer kind in the profile entries. Class names ($Typescript, $Container, etc) are too general; program names (ChatToolImpl.bcd or whatever) seem too specific and obscure. Perhaps on creating a Viewer one could specify two atoms: the class name, as usual, and a "subspecies" id that is matched against the User.profile entries.

This suggestion would require the addition of "default" options to the types of the affected parameters (e.g., column: TYPE = {left, right, color, default}).

(Why do I want these things? Well, every time I boot Cedar (a rather frequent operation, would you believe) I have to adjust those parameters manually. What? Life is hard, you say? Then why do we have PreLoad's and CommandsFrom and...).

Oh well, this IS silly...


<:-}

j.
 28-Jun-83 teitelman.pa TiogaOps2Impl.Normalize
Date: 28-Jun-83 17:18:04 PDT
From: teitelman.pa
Subject: TiogaOps2Impl.Normalize
To: tiogaimplementors^
Reply-To: teitelman.pa

see anything wrong with this:
Normalize: PUBLIC PROC [viewer: Viewer] = { [] ← TEditInput.Normalize[] };

Hint: TEditInput.Normalize[NIL] causes an address fault.

warren
 30-Jun-83 Stolfi.pa Closing grown Viewers
Date: 30-Jun-83 15:43:56 PDT
From: Stolfi.pa
Subject: Closing grown Viewers
To: McGregor
cc: Stolfi

When a Viewer A is DESTROYed or unGROWn after having been GROWn to full height, the Viewers it had displaced are automatically reopened. However, this wonderful miracle does not happen if A is CLOSEd.

Is the difference intentional? I for one would be even happier if this convenient feature applied to CLOSE as well.

jorge
 14-Jul-83 Paxton.pa Viewers automatic column height adjust
Date: 14-Jul-83 9:53:51 PDT
From: Paxton.pa
Subject: Viewers automatic column height adjust
To: Pausch, McGregor

I have lots of icons around. I start with the usual one row of icons at the bottom, but as I work that gets full and icons start going in the second row. Trouble is, I have to adjust the height manually -- what I'd really like is a way to tell Viewers to show as many rows of icons as necessary. I.e., if I have icons in the second row, shorten the columns automatically so I can see them. Sounds like a simple hack to add.

--Bill
 18-Jul-83 donahue.pa Bug in ViewerEventsImpl
Date: 18-Jul-83 13:21:41 PDT
From: donahue.pa
Subject: Bug in ViewerEventsImpl
To: McGregor, Maxwell
cc: donahue

If ViewerEventsImpl.ProcessEvent is called with viewer = NIL (which will happen if you register something for killinputfocus and the input focus is not in any viewer yet), then the code
FOR l: EventProcs ← eventProcs[event], l.rest UNTIL l=NIL DO
IF l.first.before # before THEN LOOP;
IF l.first.filter # NIL AND l.first.filter # viewer
AND l.first.filter # viewer.class.flavor THEN LOOP;
abort ← l.first.proc[viewer, event, before ! ABORTED => CONTINUE].abort;
IF abort THEN RETURN;
ENDLOOP;
will fail in the evaluation of viewer.class.flavor.

Jim D.
 29-Jul-83 pier.pa ChoiceButtonsImpl Bug
Date: 29-Jul-83 15:50:23 PDT
From: pier.pa
Subject: ChoiceButtonsImpl Bug
To: McGregor
Reply-To: pier
cc: pier

Scott-

The bug is simpler than I thought. See below. I supplied an invalid default rope to ChoiceButtonsImpl.BuildFlipThru, which attempts to call local procedure DefaultFound to compare each name in the button list to the default. If it fails to find the default, it plunges ahead calling Labels.Create with a NIL name, instead of raising DefaultNotFound. I think the code expected DefaultFound to set a global variable "foundDefault" which can be checked before plunging ahead.

Tnx.

BuildFlipThru: PROCEDURE = BEGIN
  eachButton: ButtonList;
  titleButton: Buttons.Button;
  nextx: INTEGER ← x;
  IF title # NIL THEN { -- create a title button
   stateInfo.type ← flipThruWithTitle;
   titleButton ← Buttons.Create[
    info: [name: title, 
     parent: viewer,
     wx: nextx,
     wy: y,
     wh: entryHeight,
     border: TRUE
     ],
    proc: FlipThruButtonProc,
    clientData: stateInfo
    ];
   nextx ← titleButton.wx + titleButton.ww + 3;
   }
  ELSE stateInfo.type ← flipThruNoTitle;
  FOR eachButton ← buttonNames, eachButton.rest UNTIL (eachButton = NIL) OR
   DefaultFound[eachButton.first, default] DO -- do nothing
   ENDLOOP;
  -- now set up the initial button
  IF title # NIL THEN stateInfo.flipLabel ← Labels.Create[[
   name: eachButton.first,
   wx: nextx,
   wy: y,
   ww: MaxNameWidth[buttonNames], -- first find the longest name so we can set up the
   -- width properly (unfortunately when re-labeling a button, the width remains the same)
   wh: entryHeight,   
   parent: viewer, 
   border: FALSE
   ]]
 18-Jul-83 Ingalls.PA Re: Hand Pointer
Date: Mon, 18 Jul 83 12:44 PDT
From: Ingalls.PA
Subject: Re: Hand Pointer
In-reply-to: "Your message of 18-Jul-83 10:27:15 PDT"
To: McGregor

If you can make your way through

 [Filene]<Smalltalk80Support>ShowHand-DI.st,

it has the information you need.
  3-Aug-83 Maxwell.pa ViewerLocksImpl.CallUnderXXXLock and UNWIND
Date: 3 Aug 83 10:07:28 PDT
From: Maxwell.pa
Subject: ViewerLocksImpl.CallUnderXXXLock and UNWIND
To: Pausch
cc: Plass, McGregor

Each of the CallUnderXXXLock procedures should release its locks when an UNWIND is raised. The best place for the catch phrase is in the call on the client's procedure, e.g.:

CallUnderWriteLock: PUBLIC SAFE PROC [proc: PROC, viewer: Viewer] = TRUSTED BEGIN
ENABLE {
AMEvents.Debugging => MarkColumnWedged[ViewerColumn[viewer]];
AMEvents.Debugged => MarkColumnUnWedged[ViewerColumn[viewer]]};
AcquireWriteLock[viewer];
proc[ ! UNWIND => ReleaseWriteLock[viewer]];
ReleaseWriteLock[viewer];
END;
John.
 11-Aug-83 Cattell.pa reminder
Date: 11 Aug 83 9:12:43 PDT
From: Cattell.pa
Subject: reminder
To: McGregor
cc: Cattell

For you, or whoever takes over Buttons when you're off in the rainforest:

I need a way in the Buttons interface to change the clientData associated with a button. Something like ReLabel, but maybe called ReData instead?