Date: 20-Jun-83 16:22:07 PDT From: teitelman.pa Subject: Position Bug in Tioga To: tiogaimplementors^ cc: Guibas, teitelman Reply-To: teitelman.pa
If you select a number and click position in a viewer, under certain circumstances, there is no secondary selection. To see this, retrieve /ivy/teitelman/bug/bug.profile, select the number 585 somewhere, and click position. 584 and 586 work fine.
warren
22-Jun-83 Maxwell.pa bug report on Find
Date: 22-Jun-83 10:31:34 PDT From: Maxwell.pa Subject: bug report on Find To: TiogaImplementors^.pa cc: CedarSupport^.pa Reply-To: Maxwell.pa
The following procedure should make Karen's bug happen:
1) move an &n line to be the first invisible line below the window of the Executive.
2) select a visible &.
3) click Find repeatedly. The Finds will cycle through the visible & plus the one invisible one.
------------------------------------- Date: 20-Jun-83 15:48:33 PDT From: kolling.pa Subject: bug report on Find To: cedarSupport^.pa cc: kolling Reply-To: kolling.pa
There's something wrong with Find in my (non-editable) userexec viewer. I think this is new in this release, but I'm not sure. (I'm on the boot file from just before the release). The problem is as follows: I frequently select "&" and Find backwards or forwards. Find backwards works, but Find forwards when there is only one & displayed (several &s exists ahead in the typescript) does not. What happens is I select the visible &, click Find forward, and the select bar disappears but the viewer does not scroll; if I click Find forward again it reselects the visible &. Perhaps there are two different bugs here.
23-Jun-83 Maxwell.pa minor bug in ContainersImpl.ContainerPaint
Date: 23-Jun-83 8:21:03 PDT From: Maxwell.pa Subject: minor bug in ContainersImpl.ContainerPaint To: Pausch.pa cc: McGregor, Beach, Maxwell
Rick pointed out a bug in my code to determine the correct width and height for bounded viewers. The effect of the bug was to leave a scrollbar wide gap to the right of the bounded viewer. The fixes are easy.
The code:
IF (temp ← MAX[v.parent.cw-v.cx, 5]) # v.ww THEN {
should be replaced by:
IF (temp ← MAX[v.parent.cw-v.wx, 5]) # v.ww THEN {
Similarly with:
IF (temp ← MAX[v.parent.ch-v.cy, 5]) # v.wh THEN {
and:
IF (temp ← MAX[v.parent.ch-v.wy, 5]) # v.wh THEN {
I will update this file when there are new entries.
23-Jun-83 To: Maxwell Re: minor bug in ContainersImpl.ContainerPaint
Date: 23-Jun-83 13:23:35 PDT From: pausch.pa Subject: Re: minor bug in ContainersImpl.ContainerPaint In-reply-to: "Maxwell's message of 23-Jun-83 8:21:03 PDT" To: Maxwell cc: Pausch, McGregor, Beach
I've made the change and re-compiled my version. This will show up later releases.
22-Jun-83 Beach.pa Re: Some curious Viewers difficulties
Date: 22-Jun-83 11:30:12 PDT From: Beach.pa Subject: Re: Some curious Viewers difficulties To: Pausch Reply-To: Beach cc: Beach
Maureen suggested that you might be able to help here, since you had just rolled a new Viewers for the ISL prerelease.
-------------------------------------
Date: 22-Jun-83 11:15:36 PDT From: Beach.pa Subject: Some curious Viewers difficulties To: Maxwell Reply-To: Beach cc: Beach
I am implementing a scroll-by-page scroll bar for ShowPress. This relies on Darlene Plebon's new Sliders interface that works just fine. However to establish the slider, its necessary to nest both the slider and press viewer inside a container -- thats when the fun begins.
1. binding the X and Y bounds of the nested press viewer fails to position the press viewer properly. I believe this is due to an interaction with scrollable: TRUE.
2. All the containers, buttons, sliders, and press viewers have paint: TRUE, but the press viewer does not paint itself unless the whole column is repainted. I am not sure of the interactions here -- some assistance would be appreciated.
3. Positioning buttons and text viewers on the same line is awful! Off-by-one errors abound. Grrr. . . Seems that its the defaults that differ in Buttons and MakeNewTextViewer.
4. It would be nice to use the ViewerBLT cache on the press viewer. Can I get some assistance on doing that properly?
It would be nice if there were a way to open an icon or a viewer and specify where in the column the new one was to go. For example, when opening an error log, it would be nice if I could open it just below the corresponding viewer. Split seems to know how to do this.
The last time I tried, there were problems relating to doing this in a single operation, i.e. you had to specify paint false on the call to Open, then remember to recompute column etc., I think that it would be a good idea if this were an option in OpenViewer and CreateViewer.
warren
27-Jun-83 McGregor.pa Trying out the Tioga keyset commands
Date: 27-Jun-83 10:16:15 PDT From: McGregor.pa Subject: Trying out the Tioga keyset commands To: Teitelman, Mitchell, Daniels, ISLImplementors^ Reply-To: McGregor cc: TiogaImplementors^
If you'd like to try out the Tioga keyset functions, you'll need to do the following:
1) Acquire a keyset (the alto lab used to have a stockpile)
2) Retrieve the following files from [Ivy]<McGregor>Cedar> Keyset.label KeysetReadonlyTioga.TIP KeysetTioga.TIP You may want to modify your personal df file to point to these files.
3) Hardcopy the Keyset.label file and tape it to your keyset.
4) Modify your <user>.profile to contain the following entries: ReadonlyTiogaTIP: KeysetReadonlyTioga.TIP TiogaTIP: KeysetTioga.TIP
5) Boot Othello; Open Indigo, and fetch <PreISLCedar>Top>CedarDorado.boot onto the client volume. The new boot file is required because of a bug in TIP that prevents specifying more than two control or shift keys; it should be included in the next normal Cedar release. The PreISLCedar boot file also fixes the known Viewers repaint bugs. (Note to non-ISL folks: PreISLCedar is our staging area for ISL Cedar releases. At some point it will become incompatible with Cedar 4.2).
6) Boot the client volume with the "D" switch and let it do its thing with the automatic bringover. If you have any files from <PostCedar> you may need to re-retrive them.
7) You should now be in business. Make a checkpoint if you like and try out the new functions. I'll fix the Viewers TIPTables to be consistent at some point, but for now, I'm especially interested in comments about the following:
Are the set of functions reasonable? What would you add or delete? If you give up on the keyset or never use it, I'd be interested in hearing (even if you can't articulate what drove you off). If you find yourself becoming a "hard-core" addict, I'd be interested in hearing about that as well.
It is still the case that when you are composing a walnut message and typing goes below the bottom of the viewer, the viewer does not always scroll up so that the typeinpoint is visible.
warren
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.
Someday God will justly reward an Adjust algorithm that, in response to a request to move a border up, moves it even further down than it started out, or that takes three adjustments to get to the correct set up of one border. How about believing the border is where the cursor is moved to?
Should allow more than one such procedure to be registered at a time. Spreitzer wants to try fooling around with somethiing that does a bringover from a df file, and he ought to be able to do this without turning off the one in the userexec that does spelling correction.
warren
28-Jun-83 Taft.PA Circumventing the unbound style problem
Date: Tue, 28 Jun 83 16:58 PDT From: Taft.PA Subject: Circumventing the unbound style problem To: TiogaImplementors^.pa cc: Taft
Tioga documents that use things from the default style assuming that it is Cedar.style are becoming increasingly widespread; and I am finding this to be a considerable nuisance. I assume there is no likelihood of this being fixed before Cedar 5 or Tioga 2 or whatever.
I wonder whether there is a way of circumventing the problem. For example, is it possible to make my default style effectively say, "If the document in question contains Tioga formatting then use Cedar.style, else use PlainText.style"? Or is there any other way to get a similar effect?
Reading through the Cedar 4.2 documentation, I noticed the ExtensionStyles feature which has recently been added. This might help somewhat, but it doesn't completely solve the problem for me. For example, I regularly deal with both Tioga formatted and plain text files whose extensions are ".mesa".
Hint: TEditInput.Normalize[NIL] causes an address fault.
warren
29-Jun-83 Beach.pa Use of <Cedar>Styles and <Cedar>Icons
Date: 29-Jun-83 17:30:01 PDT From: Beach.pa Subject: Use of <Cedar>Styles and <Cedar>Icons To: CedarDiscussion^ Reply-To: Beach
Recently I have been curious to see how people use Tioga styles in packages and eager to change or augment icons provided by a couple of packages. The current location for such files (mumble.style and mumble.icons) is determined by the package implementor and must be identified by examining the package DF file. However, there exist two directories: <Cedar>Styles and <Cedar>Icons. Disappointingly, they contain only a small number of samples.
Following the convention for <Cedar>Documentation, I wonder about the merits of package implementors placing styles and icon files on <Cedar>Styles and <Cedar>Icons. There seem to be stronger reasons for placing documentation in one place than for placing supporting files in one place. However one argument for a centralized location is to enumerate the use of styles or icons (or tip tables?) in Cedar clients. This would benefit the curious and the style or icon implementor in a similar manner to the documentation directory.
A related issue to the location of styles and icons is the difficulty of registering commands which rely on package styles and icons. The command registry accepts only a filename for the BCD. Some packages supply styles, icons, or tip tables (TSetter, Walnut, Remember) and thus the package must be brought over before it can be effectively used. I wonder how the advent of better remote file accessing conventions in Cedar FS would help the use of package support files.
29-Jun-83 Taft.PA Re: Use of <Cedar>Styles and <Cedar>Icons
Date: Wed, 29 Jun 83 17:44 PDT From: Taft.PA Subject: Re: Use of <Cedar>Styles and <Cedar>Icons In-reply-to: "Your message of 29-Jun-83 17:30:01 PDT" To: Beach cc: CedarDiscussion^
Seems to me that your last issue could be addressed by either of two means:
1) Invoking a registered command should (when necessary) BringOver a DF file, not just retrieve a BCD.
2) Programs should be responsible for bringing over their own auxiliary files.
Approach (1) seems more desirable since it retrieves a consistent set of files. But approach (2) has the appeal of locality and transparency. With the new Cedar FS, it may be possible to get the best of both approaches.
Ed
1-Jul-83 lamming.pa TIP Testing
Date: 1-Jul-83 8:44:14 PDT From: lamming.pa Subject: TIP Testing To: ISL^ Reply-To: lamming
I have this Micky Mouse program for testing new TIP tables. It creates two viewers: an input and an output viewer. You point at a TIP file name and hit LOAD and it parses the TIP file and tells you where the problems are if any. It then prints in the output viewer all tokens generated in the input viewer.
I have found it helpful for some while and it suddenly occurred to me that I hadn't heard of a better tool. Is there is a better tool for testing TIP tables or is this a non-problem. If the tool already exists what is it called. If there isn't is anybody interested in mine?
Mik
6-Jul-83 bier.pa Cycling Through Options
Date: 6 Jul 83 14:30:42 PDT From: bier.pa Subject: Cycling Through Options To: McGregor, Pausch cc: Bier
In the solidviews edittool, there are many buttons which cycle through possibilites when pushed (for instance: "Shadows" cycles through TRUE and FALSE, "Material" cycles through plastic, metal, and moondust).
I use a separate button to mean "use the value now displayed" much as the Tioga edit tool uses its "Set" buttons. The problem is that, if the value is being displayed by a Label, I cannot read the value displayed so I must remember what it is in another variable (presumable updated in parallel). Another choice is to use edittable viewers as Tioga does since these can be read. However, I don't want my Labels to be edittable.
I am getting good at updating associated variables in parallel with setting new values to my labels, but there is a potential variable/label consisitency problem here.
Perhaps there should be a Labels.Get command.
Eric
6-Jul-83 McGregor.pa Re: Cycling Through Options
Date: 6-Jul-83 14:45:49 PDT From: McGregor.pa Subject: Re: Cycling Through Options In-reply-to: "bier's message of 6 Jul 83 14:30:42 PDT" To: Bier cc: Pausch
Eric;
There is a "Labels.Get" command (but alas not documented in the interface). You can call rope ← NARROW[ViewerOps.GetViewer[label]] or just cheat and note that labels store their contents in the viewer name field: rope ← label.name.
Randy: Let's put a "Get" routine in the Labels interface next recompile...
Scott.
7-Jul-83 kolling.pa openh or viewers bug
Date: 7 Jul 83 12:29:34 PDT From: kolling.pa Subject: openh or viewers bug To: atkinson, tiogaimplementors^.pa cc: kolling Reply-To: kolling.pa
When I do a long Find in a viewer that's been OpenHed, and meanwhile change the input selection to another viewer, when the Find completes the OpenHed viewer is not displaying the newly Found section of the file, rather it is still where it was at the start of the Find. If the intervening change selection is not done, the viewer is set up correctly. I don't know if this is a problem for normally opened viewers as well.
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.
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
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
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.
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
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:
Date: 15-Apr-83 15:09:47 PST From: kolling.pa Subject: Re: A proposal for eliminating the need for a Levels menu In-reply-to: teitelman's message of 15-Apr-83 14:49:13 PST To: teitelman.pa, TiogaImplementors^, cedardiscussion^ cc: kolling Reply-To: kolling.pa
it would be nice if in 3.5 viewers made it easy for clients to put up new menu lines and take them down. It would also be nice if the repainting for same were instantaneous, i.e. the repaint of the main viewer area used blt. Maybe a different hint would be required for PaintViewer, or maybe a new procedure like AddMenuLine or RemoveMenuLine. I think that the repainting issue is going to be more important now that the new action area scheme puts up menus and takes them down every time you proceed or abort from an action.
warren
8-Jul-83 Maxwell.pa new boolean in viewer class record
Date: 8 Jul 83 10:03:21 PDT From: Maxwell.pa Subject: new boolean in viewer class record To: McGregor cc: Pausch, Maxwell
Scott,
Next time you change the ViewerClasses interface please add a boolean to the class record which indicates whether or not new instances of this class can be constructed just with ViewerOps.CreateViewer[$ClassFlavor, info: [name: instanceName]]. This will allow Clean and Desktops to know when it is ok to reconstruct a dead viewer. The data base may also be able to make use of it. Eventually we will want all of the classes to conform to this convention, but it will be nice until then to have some way of determining whether or not a particular class does.
I would like to insert at the end of a given Tioga text viewer v two nodes h and t whose contents are respectively the given ropes rheader and rtext, with h a first-level node and t it's child. My code for this is:
Question 1. I expected this to work provided that the last node in v is at level 2. If the level of the last node in v is not known, then the first call to TiogaOps.UnNest[] should be replaced by
WHILE "level of insertion caret is not 1" DO TiogaOps.UnNest[] ENDLOOP.
But I can't figure out how to determine the level of the insertion caret. I could just call UnNest[] a hundred times, but Tioga seems to flash "can't do it" in the message window when UnNest[] is called and the caret is at level 1. How can I solve this problem?
Question 2. In fact even when the last node of v is at level 2, the above code works sometimes and doesn't work other times, unreplicatably, and I can't figure out what's going on. When I set breakpoints in the code, the action area grabs the insertion carat as soon as the breakpoint is hit. It seems to restore the selection before proceeding, and, in fact, the code always works when I step through it with breakpoints. When I remove the breakpoints, it sometimes flashes "can't do it", and fails to insert the new nodes. Sometimes it inserts only rheader and not rtext. Does anybody have any idea what's going on, or suggestions for how to debug this?
Question 3. I question the practice of operating on Tioga node structures by maniputing the global variables of the user interface. I would like to replace the code above with something like:
The basic idea I want to propose is to break the direct link from menu button to procedure and insert an "interpretive" step. This makes it easy to drive menu actions from programs.
1) Each button has associated with it a list of atoms. Clicking a button causes its list of atoms to be passed to the button interpreter.
2) The button interpreter keeps a registry of command atoms. It looks up the atoms to find the procedures and calls them. The details of the user interface are hidden from the command interpreter -- it simply gets a list of command atoms and a viewer. This is analogous to the situation with TIP in which the user interface details are dealt with by TIP and the viewer notify procedure takes care of interpreting the lists of command atoms, etc. that come from the TIP table.
Interpret: PROC [viewer: Viewer, list: LIST OF ATOM];
3) To make it easy for people to experiment with adding to the functionality of buttons, the interpreter saves a list of procedures for each atom. It goes down the list calling each procedure in turn until it finishes the list or one of the procedures raises the signal QuitList. When registering a command proc, you can specify whether it goes at the front of the list or the end. If you are adding a special interpretation for some standard button, you register your proc after the standard one and put your's at the front of the list. If your operation preempts the normal one, it can raise the signal to prevent the normal one from being executed. However, it your operation decides to do nothing, the normal operation will be executed as usual.
4) The command procedures are passed the viewer and a client data which can optionally be provided at registration.
ButtonCommandProc: TYPE = PROC [viewer: Viewer, clientData: REF];
Register: PROC [ name: ATOM, proc: ButtonCommandProc, clientData: REF ← NIL, front: BOOL ← TRUE]; -- if front is true, put this proc at the front of the list of proc's for this atom
UnRegister: PROC [name: ATOM, proc: ButtonCommandProc]; -- removes the proc from the list for this atom
QuitList: SIGNAL; -- raised by command proc to tell interpreter to stop with this atom
-- blah, blah, blah -- This is where I stopped before coming to talk to you.
--Bill
13-Jul-83 PolleZ.pa Levels in Tioga
Date: 13-Jul-83 17:05:09 PDT From: PolleZ.pa Subject: Levels in Tioga To: TiogaImplementors^ cc: PolleZ Reply-To: PolleZ.pa
As you probably know, I am writing my thesis using Tioga. Here's an item from my wishlist for your consideration for future releases of Tioga.
When I have anything other than AllLevels selected, what I usually want to see is just the head nodes. In other words, I want to see just the outline, so that I can see how the structure of the document is progressing. With the current Tioga, I can get the first level of such an outline for free, but the rest tends to be obscured by the text in the upper levels. Having the outline come for free when you write a document is extremely helpful.
To implement this, a HeadersOnly toggle button could be added to the Levels menu line. A user could then browse the outline of a document to whatever level she wishes without giving up the ability to browse the text at multiple levels also.
The problems may come from the fact that Break behaves differently depending on whether the node is empty or not (try it -- notice where the caret ends up). Try rewriting it so that you 1) make a caret selection at the end of the last node, 2) save the selection, 3) insert the rope, 4) restore the selection, and 5) break the node. Do this for rheader and then do it again for rtext. Then select the last node and Nest.
Regarding "the practice of operating on Tioga node structures by maniputing the global variables of the user interface" -- I agree completely. Tioga2 is being designed to support client code more in the style you suggest. Tioga1 cannot quite manage it for a variety of reasons.
--Bill
14-Jul-83 Maxwell.pa scrolling very large files
Date: 14 Jul 83 12:48:50 PDT From: Maxwell.pa Subject: scrolling very large files To: McGregor, Pausch
Could this be an off-by-one error somewhere in the thumbing logic? Russ says that OpenHuge has nothing to do with scrolling. It is just a convenient interface to using a virtual rope on the file.
I opened a 2250913 byte file using openhuge. I cannot use the middle mouse button to scroll to the end. Selecting with the middle button very close to the bottom of the bar moves the window down somewhere into the file (not the end). The scroll bar indicates that you are at the end, but thumbing down using the left mouse button reveals much more text. -- Bob
14-Jul-83 McGregor.pa Re: scrolling very large files
Date: 14-Jul-83 12:59:36 PDT From: McGregor.pa Subject: Re: scrolling very large files In-reply-to: "Maxwell's message of 14 Jul 83 12:48:50 PDT" To: Maxwell cc: Pausch
I don't believe that this is a Viewers problem. Tioga should probably treat anything between 95% and 100% of the viewer as 100% for thumbing purposes (ditto for 0% to 5% or some other suitable metric).
I'm actually passing 100% to the client; what they choose to do with it is another problem...
"It will all be wonderful in Tioga2".
Thanks,
Scott.
14-Jul-83 PolleZ.pa Spaces at ends of lines
Date: 14-Jul-83 14:04:20 PDT From: PolleZ.pa Subject: Spaces at ends of lines To: TiogaImplementors^ cc: PolleZ Reply-To: PolleZ.pa
Spaces at the ends of lines seem to be second-class citizens: no matter how hard I try, I can't select one so that the insertion caret is at the right edge of it, whereas I can with other characters. How come? I really would like to be able to do this - for example, sometimes the next character (on the following line) is in a different font, so that selecting the left edge of it and inserting is less convenient.
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.
"When I set breakpoints in the code, the action area grabs the insertion carat as soon as the breakpoint is hit. It seems to restore the selection before proceeding, and, in fact, the code always works when I step through it with breakpoints. When I remove the breakpoints, it sometimes flashes "can't do it", and fails to insert the new nodes. Sometimes it inserts only rheader and not rtext. Does anybody have any idea what's going on, or suggestions for how to debug this?"
I don't want to go into why the action area grabs the carat (for almost all break points, you are going to want to type smoething to the action area anyway), but you are right that it does grab it and therfore, it does save and restore it. In addition, if you want to see what the current selection was before the action occurred, there is a command called showselection. If you want to interpret expressions in the action area which require that the selection be where it was, e.g. calls to TiogaOps. there is another command called restoreselection which restores the current selection before each event. (Both of these are documented in userexec.tioga.) I hope this helps. Otherwise, let's discuss what I could provide that would.
warren
18-Jul-83 teitelman.pa Proceed be guarded button
Date: 18 Jul 83 9:55:20 PDT From: teitelman.pa Subject: Proceed be guarded button To: cedarusers^ Reply-To: teitelman.pa
It has been suggested that the proceed button in actionareas be guarded, the reason being that it is awfully easy to hit Proceed when aiming for Find. This would of course mean that you would have to quick proceed twice to proceed. Is there a strong groundswell for this change?
warren
18-Jul-83 teitelman.pa buttons, menus etc.
Date: 18 Jul 83 9:40:16 PDT From: teitelman.pa Subject: buttons, menus etc. To: tiogaimplementors^ cc: teitelman Reply-To: teitelman.pa
appropos of earlier conversation on things I would like to see done with buttons, we (Randy and I) discussed ways of making the menu information into a data structure that the user could edit. For example, some users might want to make certain buttons be guarded, and others might not. It is hard to make this sort of change when the information is stored in a program, but a lot easier if it is represented as data in a file, e.g. a profile.
warren
19-Jul-83 McGregor.pa Interface changes for PreISLCedar vs Cedar 4.4 ...
Date: 19-Jul-83 10:30:33 PDT From: McGregor.pa Subject: Interface changes for PreISLCedar vs Cedar 4.4 release To: Atkinson cc: Pausch, Wyatt
Russ;
Could you let Randy and me know when you've snapshotted the TIP and Viewers stuff from <PreISLCedar> and stored them on <PreCedar> or <Cedar>? We'd like to use that directory as a staging area for the new Viewers changes...
Thanks,
Scott.
19-Jul-83 PolleZ.pa Interaction between Look.s and Look.d
Date: 19-Jul-83 15:44:37 PDT From: PolleZ.pa Subject: Interaction between Look.s and Look.d To: TiogaImplementors^ cc: PolleZ
When you select a section of text containing subscripts and make it use a smaller font, why don't the subscripts get smaller too?
Polle
20-Jul-83 teitelman.pa rolling back at inopportune times
Date: 20 Jul 83 11:36:11 PDT From: teitelman.pa Subject: rolling back at inopportune times To: mcgregor cc: pausch, levin, teitelman
Scott,
this is a recapitulation of our discussion.
There are various times in the running of a program when clicking the rollback button to cause a rollback will result in information being lost. The case that is currently covered (built in to the implementaiton of the rollback button) is where tioga documents have been edited but not saved. Rollback asks the user whether to go ahead with the rollback, thereby losing edits, or to abort.
I have another situation where I would like to inform the rollback button to inform the user that it might not be a good idea to rollback at that exact point, namely when the user has done something requiring that rememberevents.txt be rewritten, and this has not yet been done (completed).
What we discussed as a way for a client program to register/inform rollback that this was not a good time, and to allow the user the option of saying go ahead anyway, abort, or possibly spin and wait for the operation (the exact nature of which the user might not be aware) to complete.
warren
26-Jul-83 Stewart.pa Scrolling message sets
Date: 26 Jul 83 13:46:25 PDT From: Stewart.pa Subject: Scrolling message sets To: TiogaImplementors^, WalnutSupport^ cc: Stewart Reply-To: Stewart.pa
It is impossible to keep scrolling a typescript or text viewer after one is at the bottom. It is possible to keep scrolling a message set. Probably the scrolling should stop working when the last message is displayed in the first line of the viewer. This seems to be a general problem with containers.
------------------------------------- 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.
28-Jul-83 vanleunen.pa omigod, now she's fooling around with .tip tables
Date: 28 Jul 83 12:39:17 PDT From: vanleunen.pa Subject: omigod, now she's fooling around with .tip tables To: TiogaImplementors^ cc: vanleunen Reply-To: vanleunen.pa
It would be nice if saving a new version of one's own .tip table did an automatic CTRL-! ReadTiogaTipTables, the way that saving a new version of one's .profile automatically processes for changed entries.
28-Jul-83 vanleunen.pa CTRL-! and ReadTiogaTipTables
Date: 28 Jul 83 13:09:50 PDT From: vanleunen.pa Subject: CTRL-! and ReadTiogaTipTables To: TiogaImplementors^ cc: vanleunen Reply-To: vanleunen.pa
Hmmm ... sometimes I do not seem to be able to get CTRL-! to pay attention to me, and so I have to go do ReadTiogaTipTables instead. Twice now (I think) CTRL-! ignored my deleting an entry from my .tip table. Is there some magic I don't know about?
28-Jul-83 vanleunen.pa more on CTRL-!
Date: 28 Jul 83 13:20:25 PDT From: vanleunen.pa Subject: more on CTRL-! To: TiogaImplementors^ cc: vanleunen Reply-To: vanleunen.pa
Nor can I get CTRL-! to attend to changes within an entry. (It's a shame, too, I think "control-bang" is one of the more attractive expressions I've acquired since coming here.)
Then again, sometimes CTRL-! does attend to changes within an entry. Obviously there's something crucial missing in my grasp of what's going on. Words of one syllable, please?
Here's what I think I did; I don't know if this is reproducible. I was doing a save on a (non-split) viewer; while it was saving I selected something for deletion, moved the input focus to the exec typescript & did a login. I then noticed that the file had been saved, the deletion done, but [New Version] did NOT appear in the caption. A Reset did restore the version I had just saved.
What I want is a mouse click that selects a logical word, eg given SprintFileAndDatabase it would allow me to select "Sprint" or "And" or whatever, rather than just one letter or the whole thing.
Mike Sprietzer points out that although the documentation in ViewerOps.mesa implies that the children of a viewer won't be repainted if hint = client and clearClient = FALSE, they in fact get repainted no matter what. He would like the implementation changed so that the children don't get repainted in this case.
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
Date: 6 Aug 83 11:01:30 PDT From: crow.pa Subject: Color Cursor and Overlays To: ISL^ Reply-To: crow.pa
The standard mode for the color display allows a 2-bit overlay plane which can be useful for the cursor, pop-up menus, etc. The two extra bits, in effect, allow switching between 4 different color maps on a pixel-by-pixel basis. I propose that the default use of the four maps be as follows: 0 - Standard or user-supplied color map 1 - Cursor color (may be chosen to complement or otherwise modify map 0, or be constant) 2 - Constant overlay color 3 - 2nd constant overlay color
This gives a cursor color which is guaranteed to show up and two colors (eg. black and white) to use for opaque pop-up menus, etc.
The color display allows the overlay bits (also the regular display) to be panned around with very low overhead (no BitBlts necessary) by updating "Channel Control Blocks". As I understand it, it is possible, by manipulating control blocks to independently control a number of cursors and overlays as long as no more than one occupies a given scan line (shades of Atari game computers!!).
What level of function would people like for the above purposes? I am about to start mucking around with the B-channel and I'm willing to build as much generality into the resulting imager functions as it appears people will use. Full generality is possible (overlapping overlays, cursors, etc.) with only minor hiccups as bitmaps get combined and separated when occupying overlapping sets of scan lines.
One major purpose here is to try to better understand what sorts of features belong in the Dragon display. Very little use has been made of the Dorado color board's capabilities so far, and I need evidence that all the goodies therein really are useful.
Note that none of this will work on 24-bit color. Also note that up to 4 bits can be used for the overlays if less than 8 are used for the primary display (primary + overlay <= 10 bits).
Frank
8-Aug-83 vanleunen.pa embarrassing question for the evening
Date: 8 Aug 83 18:51:59 PDT From: vanleunen.pa Subject: embarrassing question for the evening To: TiogaImplementors^ cc: vanleunen Reply-To: vanleunen.pa
(Oh well, I figure silly mail from me is probably much more entertaining than anything else you have to think about at the moment.)
How can I see on line where I've put PageBreak nodes in a document?
8-Aug-83 Pier.PA Tioga/Viewers bug
Date: Mon, 8 Aug 83 17:06 PDT From: Pier.PA Subject: Tioga/Viewers bug To: McGregor, Pausch cc: Pier
1. Open a new viewer. Load a text file into it, say FOO.TIOGA. 2. RIGHT (Blue) Bug CLEAR in that viewer. Viewer closes and new one appears. 3. Load a different text file, say FEE.TIOGA into the new viewer. 4. Open the iconic viewer, FOO.TIOGA 5. Observe: viewer opens with FEE in it instead of FOO. FOO may appear as the name of the viewer, but FEE is in it. Resetting the viewer will bring up FOO correctly.
10-Aug-83 teitelman.pa minor flame
Date: 10 Aug 83 15:39:23 PDT From: teitelman.pa Subject: minor flame To: tiogaimplementors^ Reply-To: teitelman.pa
the fact that tabs line up differently on your screen than when printed is to my mind the single biggest annoyance in tioga. I usually have to make about five trips down the hall to the printer to get something right, and then it looks terrible on my display. I hope you fix this sometime.
warren
11-Aug-83 Cattell.pa I'm told you should have this
Date: 11 Aug 83 9:44:17 PDT From: Cattell.pa Subject: I'm told you should have this To: Pausch
------------------------------------- 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? ------------------------------------------------------------
11-Aug-83 McGregor.pa Bug File
Date: 11-Aug-83 9:49:09 PDT From: McGregor.pa Subject: Bug File To: Plass Reply-To: McGregor cc: Pausch, Paxton
Michael;
I've stored the collected set of user requests regarding the Viewers package on /Indigo/CedarViewers/Temp/Bugs.mail.
Many of the requests will be fixed as a result of Randy's menu rework.
Scott.
11-Aug-83 Horning.pa Caret Looks
Date: 11 Aug 83 17:47:45 PDT From: Horning.pa Subject: Caret Looks To: TiogaImplementors^ cc: WalnutSupport^, Horning Reply-To: Horning.pa
For your file of "things that ought to be fixed in the next go-round."
------------------------------------- Date: 11 Aug 83 17:16:10 PDT From: Willie-Sue.pa Subject: Re: Two Walnut glitches In-reply-to: "Your message of 11 Aug 83 11:33:55 PDT" To: Horning cc: Willie-Sue
Yes, the caret has looks attached to it. The problem is that there is no easy (and almost NO) way to find out what the current caret looks are, so they could be saved & restored. Since the odd looks in sent messages are pretty much harmless, this won't get fixed.
I didn't think about perhaps having to make the typescript smaller when changing databases. SMOP.
Date: 12 Aug 83 11:51:24 PDT From: Horning.pa Subject: Re: Tioga Q&A - PageBreak nodes In-reply-to: "PolleZ's message of Fri, 12 Aug 83 11:33 PDT" To: PolleZ cc: Plass, CedarDiscussion^ Reply-To: Horning.pa
Polle,
You CAN put text in pageBreak nodes. It appears in a paragraph at the bottom of the page (sometimes useful for footnotes and that sort of thing). It's only empty pageBreak nodes that are invisible. Unfortunately, that's usually the kind that I need to use.
Your other points make a lot of sense to me, except that Tioga 1 is not WYSIWYG editor (ever try to build a table where the columns line up?). Hopefully, this is one of the things that will be fixed in the wonderful world of Tioga 2.
Jim H.
12-Aug-83 Willie-Sue.pa the next time interfaces can change
Date: 12 Aug 83 12:03:33 PDT From: Willie-Sue.pa Subject: the next time interfaces can change To: TiogaImplementors^ cc: Willie-Sue Reply-To: Willie-Sue.pa
Date: 12 Aug 83 12:38:44 PDT From: mitchell.pa Subject: Re: Tioga Q&A - PageBreak nodes In-reply-to: "PolleZ's message of Fri, 12 Aug 83 11:33 PDT" To: PolleZ cc: Plass, CedarDiscussion^ Reply-To: mitchell.pa
What I would like to see in Tioga II is a way of displaying some or all of the properties and their values associated with every node (this includes Format, Comment, etc.) so that I don't have to use the EditTool to probe for them one at a time. In fact, I think of the contents as just one of the interesting properties that I want to see, and I would like to specify what properties are displayed at a give time - this is a property of a viewer and not of the document itself.
Date: Fri, 12 Aug 83 11:33 PDT From: PolleZ.PA Subject: Re: Tioga Q&A - PageBreak nodes In-reply-to: "Your message of 12-Aug-83 10:19:00 PDT" To: Plass cc: CedarDiscussion^
Mary-Claire's question has reminded me that PageBreak node invisibility is something that I've groused about to myself in the past.
I don't doubt that PageBreak nodes can be found in the way you've described. However, my experience with them has been that I would MUCH prefer that they were visible in some way--as a blob, a sequence of dashes, anything! Having to explicitly hunt for them (via a nontrivial set of actions, yet) is too much work. Even after you've found them, you scroll the document a few times and you've forgotten where they were. Furthermore, if you're editing someone else's document, you don't even know to hunt for them until you get some strange and undesirable results from the printer. WYSIWYG editors are supposed to reduce the number of trips to the printer, not increase it.
This is an area where WYSIWYGness traditionally has trouble, but resolving it in favor of "what you can't see is what you get" seems like a lose. I think it's better for things to appear in the document that don't appear in the printed version than vice versa. Editing is easier when you can see--directly, without excess incantations--the things that affect the printed result (in those cases that you can't see a facsimile of the result).
Is there some overriding reason why PageBreak nodes are invisible on the screen? If you don't want to make the node appear on the screen as something, you could make the contents of a PageBreak node not print, so that users could insert their own text to alert themselves. This solution is not as good for editing someone else's document, though.
Polle
12-Aug-83 Maxwell.pa Target with node breaks
Date: 12 Aug 83 15:00:35 PDT From: Maxwell.pa Subject: Target with node breaks To: TiogaImplementors^.pa Reply-To: Maxwell.pa
Mike Sprietzer observed that 'Find' and 'Search' both fail to work if the target contains a node break. For example consider the two following lines:
Foo Bar
Bar Foo
Foo Bar
Bar Foo
If you select "Foo Bar Bar Foo" and click 'Find', it will not find the second example. If you copy "Foo Bar Bar Foo" into the Edit Tool and then click 'Search', it will search for just "Foo Bar". (Clicking 'Count' will count 5 examples of in this message, even though there are only two.)
John.
12-Aug-83 Maxwell.pa a change for MBQueue
Date: 12 Aug 83 12:47:45 PDT From: Maxwell.pa Subject: a change for MBQueue To: TiogaImplementors^.pa Reply-To: Maxwell.pa, Willie-Sue.pa
------------------------------------- Date: 12 Aug 83 12:07:44 PDT From: Willie-Sue.pa Subject: a change for MBQueue To: Maxwell cc: Willie-Sue
Walnut is currently using a private version of MBQueue (called WQueue to save sanity) with the following change:
Flush: PROC [q: Queue, proc: PROC[Action]← NIL]; -- Flushes all pending button presses and menu selections in the context of q. This procedure -- can be called, e.g., when some illegal actions suggests the user is confused an further -- mouse-ahead should be ignored. -- proc will get called for each Action in the queue, to allow cleanup, NOTIFY's, etc
The reason is that Walnut sticks things on its queue which contain condition variables; the programs hanging on any variables that get flushed from the queue would then be hung forever (a good way to lose your exec, etc.) The implementation:
Flush: PUBLIC ENTRY PROC [q: Queue, proc: PROC[Action]← NIL] = { event: Event; IF proc = NIL THEN q.firstEvent← NIL ELSE UNTIL q.firstEvent = NIL DO event← q.firstEvent; q.firstEvent← q.firstEvent.rest; proc[event.first]; ENDLOOP; };
Date: 15-Aug-83 9:36:40 PDT From: Plass.pa Subject: Re: Tioga Q&A - PageBreak nodes In-reply-to: "mitchell's message of 12 Aug 83 12:38:44 PDT" To: mitchell cc: Plass, CedarDiscussion^
Reply-To: Plass.pa
There is a program called AnnotateProperties (written by Rick Beach last summer) that will insert comment nodes in your Tioga-I document that describe the format, properties, etc. Run it, and it registers two commands with the exec, AnnotateProperties and PruneAnnotations; the latter undoes the effect of the first. These programs save the document after they make their changes, so it might be prudent to back your file up first, although I haven't had any files clobbered by them.
Michael
16-Aug-83 Horning.pa MIDDLE-select
Date: 16 Aug 83 13:48:31 PDT From: Horning.pa Subject: MIDDLE-select To: TiogaImplementors^ cc: CedarSupport^, Horning Reply-To: Horning.pa
I notice the following anomalous property of MIDDLE-select: If I am over a word when I go down on MIDDLE, I get word-select. However, if I roam around with MIDDLE down, I can get into a mode where single characters are selected (and underlined). One way to get into this mode appears to be to pass a point that causes the selection to be the end of a typescript, but there may be others. Once in the mode, it seems to persist, even into other viewers, and sometimes even after MIDDLE released and depressed again. Strange. Like a confusion about what TIP table to use?
Jim H.
16-Aug-83 Plass.pa Vewers bug fixes
Date: 16-Aug-83 9:55:24 PDT From: Plass.pa Subject: Vewers bug fixes To: Pausch Reply-To: Plass cc: McGregor, Plass
Randy,
I found and fixed several bugs in the new Viewers, and put the fixed versions on CedarViewers. The changes were in
CaretsImpl.InvertCaret
VFontsImpl.EstablishFont
ViewerBLTImpl.BLTViewer
WindowManagerImpl.PostScrollFeedback
Let me know if you need any help merging these changes in.
Michael
17-Aug-83 vanleunen.pa Desktops
Date: 17 Aug 83 22:58:16 PDT From: vanleunen.pa Subject: Desktops To: CedarUsers^, CedarFolklore^ cc: vanLeunen Reply-To: vanleunen.pa
Jim Horning just recently mentioned John Maxwell's Desktops to me, and I love them and thought I might draw them to other people's attention as well. A desktop is a way of capturing a configuration of viewers, and it's possible to move from one desktop to another. Here is how I use them:
After a Rollback my screen contains an open UserExec and icons for one text file (called, perspicuously, ThingsToDo.tioga), a TSetter, the FileTool, and the Clock. I putt-putt along merrily in that world, reading my mail, writing about commas, trying to write with the Alpine documentation, fooling around with some demonstration button-helps for Maintain -- all the while opening viewers and creating icons. Finally things start getting messy enough to offend me and slow me down. At that point, I do:
&n Desktop Messy
to create a desktop of my current messy state. (I might destroy some viewers first, but usually I don't bother.) Down at the lower right-hand corner of the screen, Desktop makes a nice little squared-off icon named Messy. I then do Desktop again, immediately, for the task I plan to continue or begin next; say for instance:
&n Desktop Buttons
Down at the lower right-hand corner of the screen, Desktop makes a nice little squared-off icon named Buttons. The Messy desktop shows that it is the current one by showing its name in white on black; the Buttons desktop has its name in black on white. I then "fly to" the Buttons desktop (that's Maxwell's metaphor, not mine) by control-middle-clicking it. (I could equally well have opened the Buttons desktop icon and left-clicked FlyTo.)
Shazam, my screen is clear again and I have icons for only my A: UserExec and the two desktops. (Every desktop automatically includes the A: exec and all desktops.) Buttons is now the current desktop and has its name in white on black.) I open the icon for the old Messy desktop and left-click only the things I want for my current task, several files and the FileTool and the Clock and Maintain. I don't actually want the exec on this desktop but I don't destroy it -- that's the only inconvenient thing about desktops, that destroying such a viewer would have awkward results.
Again I putt-putt along till the desire to read my mail overwhelms me. So I do:
&n Desktop Mail
That creates my third desktop. Again I fly to it and again I fetch the things I want from my old Messy desktop. Meanwhile the Buttons desktop is preserving exactly the state I had reached in doing my button-helps. When I have temporarily sated my mail addiction, I fly back to Buttons and resume fooling around.
The documentation for Desktops is in [Indigo]<Cedar>Documentation>ViewerDoc.tioga. I believe Jim uses them rather differently from the way I do -- maybe he and John would be willing to describe what they do?
(To destroy a viewer other than a plain Tioga viewer on one desktop while keeping it on another desktop, select the viewer you want to destroy and left-click AddSelected on the desktop where you want to keep it. Even if it's already there.)
(One small sorry note: Building up Desktops I had my first experience of running out of virtual memory.) (At least now I know what virtual memory is.)
18-Aug-83 Horning.pa Re: Desktops
Date: 18 Aug 83 10:42:43 PDT From: Horning.pa Subject: Re: Desktops In-reply-to: "Your message of 17 Aug 83 22:58:16 PDT" To: vanleunen cc: CedarUsers^, CedarFolklore^ Reply-To: Horning.pa
Mary-Claire,
Yes, my style of using Desktops is considerably different. Perhaps it is because my activities are more predictable, or because I am compulsively tidy (about some things--certainly not about my real desktop!).
I include three Desktops in my Checkpoint, so that when I start the day or Rollback I'm conveniently set up for any of three modes of activity:
- On my Mail Desktop (which is Current in the Checkpoint) I have opened Watch, Executive A, Walnut, Active Messages, and Whiteboard Scratch (which I use like your ThingsToDo.tioga, but with 5 text boxes--for Priority Activities, This Week's Calendar, Pending Activities, Long-term Calendar, In Progress Activities, Past Calendar (accumulated for Activity Report time)). I also have icons for Maintain, Debug Local, File Tool, Clover, Encryption Tool, Clock, and Edit Tool.
- On my Editing Desktop, I have opened Watch, Executive A, Edit Tool, Clover, and Larch-Handbook.tioga (my current editing task). I also have icons for Edit History Tool, Encryption Tool, Clock, Debug Local, File Tool, Walnut, and TiogaDoc.tioga.
- On my Phone Desktop, I have opened Watch, Executive A, Horning.TDir, Finch, and Telephone Directory: Personal. I also have icons for Clock, File Tool, Walnut, and Debug Local.
I rarely create further Desktops during a session. When one of my existing Desktops gets too cluttered, I just start deleting icons. Switching Desktops corresponds to a fairly major switch of attention.
Jim H.
18-Aug-83 Horning.pa Levels: Bugs or Features?
Date: 18 Aug 83 12:18:44 PDT From: Horning.pa Subject: Levels: Bugs or Features? To: TiogaImplementors^ cc: Donahue, Maxwell, Horning Reply-To: Horning.pa
Since Whiteboard text boxes don't have Level menus, I find myself relying on the "scroll with level adjustment" more there than in other documents. Two aspects of this have surprised me:
- I can't seem to get minimum levels with SHIFT-CTRL when the cursor happens to be alongside a bottom-level node (in a small text box, it can frequently be the case that only bottom-level nodes are visible). Is Tioga trying to protect me against myself or something?
- SHIFT and CTRL only seem to be effective in combination with LEFT. I find myself wanting to do things like "thumb to middle and show all levels" or "return to top and show minimum levels." Is there any reason not to make SHIFT and CTRL effective with all three mouse buttons?
Jim H.
22-Aug-83 McGregor.pa Re: BNF (best read on a wide viewer
Date: 22-Aug-83 13:18:41 PDT From: McGregor.pa Subject: Re: BNF (best read on a wide viewer In-reply-to: "Your message of 22-Aug-83 12:57:50 PDT" To: Pausch
Randy;
In general, it looks fine. Before you make your slides though...
A few comments/questions:
1) What's an ID? It only appears in LHS's. I assume you'll tell people that the new menu files contain a list of ITEMs. 2) What are the defaults for breakBefore, breakAfter, beginsActive, and notifyProc? 3) I don't understand notrigger. 4) shiftLeftUp was left out. 5) I suggest defining PROC as "'#' IMPL '.' ITEM" or some such where IMPL and ITEM are STRINGs. That way, you convey a bit more semantics. 6) How about renaming "COMPLEX" to be "TRIGGERLIST" and rename "TRIGGERLIST" to be "TRIGGER" since it really isn't a list. 7) Nit: in one place you use "STRINGORPROC" in another you use "(STRING | PROC)" 8) Something to ponder: Could you always use STRINGORPROC in place of STRING?
Scott.
22-Aug-83 Maxwell.pa viewer blt bug
Date: 22 Aug 83 11:24:45 PDT From: Maxwell.pa Subject: viewer blt bug To: Pausch cc: Plass, McGregor
I found the source of the viewer blt bug that we saw Friday. I had an unmonitored call to CloseViewer with paint: FALSE. To fix it, replace ViewerOpsImplA.GrowViewer with the following code:
GrowViewer: PUBLIC PROC [viewer: Viewer, paint: BOOL ← TRUE] = BEGIN
LockedGrowViewer: PROC = {
FOR v: Viewer ← rootViewerTree[viewer.column], v.sibling WHILE v # NIL DO
IF v = viewer THEN LOOP;
ViewerOps.CloseViewer[v, FALSE]; -- must be under a lock!
IF paint THEN ViewerOps.PaintViewer[v, all]; -- just paint the icon
ENDLOOP;
InternalComputeColumn[viewer.column, paint]};
IF viewer.iconic THEN {ViewerOps.OpenIcon[viewer, TRUE, paint]; RETURN};
IF ViewerEvents.ProcessEvent[grow, viewer, TRUE].abort THEN RETURN;
IF viewer.offDeskTop THEN ChangeColumn[viewer, left];
FOR v: Viewer ← rootViewerTree[viewer.column], v.sibling WHILE v # NIL DO
IF v # viewer THEN KillInputFocus[v]; -- done here to prevent deadlock
Date: 18 Aug 83 11:48:37 PDT From: Maxwell.pa Subject: locking the message window To: Pausch cc: Plass, McGregor
There is a simple deadlock involving the message window:
Process A: PaintViewer => read lock a column. Process B: OpenIcon or CloseViewer => CallUnderColumnLocks[static, column] => write lock the static column then wait for Process A's column. Process A: MessageWindow.Append (print error message) => PaintViewer => attempt to read lock the static column. (dead lock)
I can think of two ways around it: 1) Make up a new column just for the message window, or 2) have CallUnderColumnLocks lock the static column last.
1) is conceptually cleaner, but 2) is easier to implement. Can you think of any reason a process would acquire the static column and then later decide it also wanted another column?
John.
25-Aug-83 vanleunen.pa Re: interlineation
Date: 25 Aug 83 12:03:40 PDT From: vanleunen.pa Subject: Re: interlineation In-reply-to: "Your message of 25-Aug-83 9:59:04 PDT" To: Beach cc: vanleunen, TiogaImplementors^ Reply-To: vanleunen.pa
... see edittool "Patterns for Search and Substitute" which describes how to use patterns to match things. Perhaps you can use the multiple instances of named subpatterns to generate the duplicates you desire. Possibly ... etc.
Hmmm. This is not exactly my idea of a straightforward solution. Let me pose the problem in the degenerate case:
I have a list like this (but forty items long rather than three):
Apple baker charlie. Dog easy foxtrot? Golf helical isotherm.
And I want to make a list like this:
Apple baker charlie. Apple baker charlie. Dog easy foxtrot? Dog easy foxtrot? Golf helical isotherm. Golf helical isotherm.