From: bgardner@ATHENA.MIT.EDU
Date: Thu, 2 Nov 89 23:08:58 -0500
Message-Id: <8911030408.AA08512@PINK.MIT.EDU>
To: mackay@ATHENA.MIT.EDU
Subject: Re: more Bugs and features
Cc: argus2@ATHENA.MIT.EDU

   In response to Wendy's notes about the rulebrowser:

>1.  The rule browser should give me the option of creating a new
>ruleset with a little popup, rather than making me retype the
>command with "rulebrowser -force newruleset".

   I agree. I just didn't have the time to add it.

>2.  Help looks good -- but put a blank line between commands.  I
>know it makes it longer, but otherwise it's incredibly hard to
>read.

   These are actually not a continuous text widget, they are grouped
by separate form widgets with extra spacing between them. The week
before the release, there was a full line of spacing between them
as you suggest. The spacing was not taken out...What happen was that the
default font was changed on short notice just before the release.
The new font was larger and made the extra spacing appear negligable.
(It also made the help screen for large, that it couldn't fit onto my
screen. I had all I could do to get the help msgs short enough to barely
fit entirely on my screen before the release.)

>3.  Is it possible to remove the "contains" part for rules,
>and to suppress the field type?  I know it comes with all that
>stuff, but most of the time people only want to look at the
>basics of the rule, not the details (which they can get either
>by printing out the ruleset or by looking at individual rules
>with the ruleeditor).  This will also reduce the need for extra
>scroll bars across the top of the rule...which will leave more
>room vertically for displaying the rule.

   We had considered a "complex/simple" switch for desplaying rule in the
rulebrowser to allow for this. The "ruleprint" functions were not
designed for this originally. -- This enhancement as abandoned due to
lack of time; we ran out of time for adding new features before code freeze.

>4.  What causes a rule to convert between "new" and old?  I created
>a series of rules, using copy, and the ones I had saved all kept
>the "new" designation.  I'm not sure if this is wrong -- just
>curious what causes it to change.

   When a rule is added to the ruleset, it is considered "new" until
it is in some way touched or altered. The "new" icon severs as
a reminder to the user that they have created this rule and haven't
touched it yet. After testing some users, I found that they were
confused by copies not being declared "new"...so I added it.
(In particular, its useful to avoid duplicate rules in the ruleset,
and un-edited default rules...which are the usual cases.)

>5.  I tried to print and got the "Can't find Printer" message, which
>is fine.  But then I used setenv and it still didn't work.  It should
>either warn me that I have to get out and back in again for that
>to be updated, or, better yet, check for it whenever the PRINT button
>is pressed.

   This is the only "bug" in the rulebrowser (that I know of) and is
documented in the man page for the rulebrowser under the bold title "BUGS". :-)
In fact...its not really a bug...when you type "setenv", you are
setting the environment of the shell of the xterm you type it in...not
in the environment that the rulebrowser process was forked with....
(Ugh, Unix). We had hoped to add a function to the AlPop function set
to prompt the user for string (dialog) input, but this was another feature
that couldn't be done because of time constraints. As a best-fix, I
documented in the man page, and added an error msg.

   6.  I assume this is a Motifism, but when I expand the window
>horizontally, the rules don't get any longer and still have
>the little scrollbars.  It would be nice if there were a minimum
>size (so you could see the rules) and then the ability to see
>more of the rule if you choose.

    Yup, this is a Motifism. I have tried to do this from the start,
and was quite annoyed at this. It is currently the most
annoying "lack of a feature" in Motif, from what I've heard from other
Motif programmers/users. It is caused by the ScrollW widget not having
a resource to select automatic scrolling as active for XmHorizontal,
XmVertical, or XmBoth...(The ability to choose XmHorizontal or XmVertical
is the needed features.) The lack of such a resource force programmers to
either do automatic scrolling in XmBoth directions, or not at all.
As a result, we also don't have the feature of being able to
set the Working-Window's XmNrightAttachment to XmATTACH_FORM,
so that the working window can resize when its parent ScrollW resizes.

    -- Brian