Message-Id: <8807281549.AA00557@LYRE.MIT.EDU>
To: Win Treese <treese@ATHENA.MIT.EDU>
Cc: dmh@ATHENA.MIT.EDU, davis@ATHENA.MIT.EDU, thebeast@ATHENA.MIT.EDU,
        lerman@ATHENA.MIT.EDU, wdc@ATHENA.MIT.EDU, bgardner@ATHENA.MIT.EDU,
        mwmoor@ATHENA.MIT.EDU, steiner@ATHENA.MIT.EDU, hodges@ATHENA.MIT.EDU,
        henry@ATHENA.MIT.EDU, vanharen@ATHENA.MIT.EDU, rar@ATHENA.MIT.EDU,
        tjcoppet@ATHENA.MIT.EDU, kit@ATHENA.MIT.EDU, mackay@ATHENA.MIT.EDU,
        swick@ATHENA.MIT.EDU
Subject: Re: Xmh: summary of comments, with response 
In-Reply-To: Your message of Fri, 22 Jul 88 22:45:41 -0400.
             <8807230245.AA17093@SELENE.MIT.EDU> 
Date: Thu, 28 Jul 88 11:49:28 EDT
From: Ralph R. Swick <swick@ATHENA.MIT.EDU>

     Date:  Fri, 22 Jul 88 22:45:41 EDT
     From:  Win Treese <treese@ATHENA.MIT.EDU>

     1. Frequent rescans.  xmh often rescans your inbox for no apparent reason.

	I think there's still a problem here, even with the NFS fixes.

     2. The print option should be improved.  That is, it should give you better
     	control over where your output is going, and should be able to
     	handle non-PostScript printers.

	Better documentation for the PrintCommand resource might help, but
	there's a generic issue with setup.  I suspect most actions should
	have option sheets (screens) for interactive (re)configuration.

     3. Speed.

     	Is spread across all layers (from the server up) and will improve
	as additional effort is put into each piece.  We should, however,
	consider specific problem areas that are unique to xmh.  For example,
	we should look for opportunities for parallel processing or background
	execution of such things as print and pick.

     4. Default geometry is odd.

     	A simple change to the configuration file (which should appear in
     	the next 6.0 update) makes the default useable, but there is still
	work to be done to support the high degree of flexibility implemented
	in the X10 prototype.  I am thinking especially of the space
	allocated to each of the button boxes.

     5. Can't tell which button to press.

	I'd welcome suggestions as to ways to improve the intuitiveness
	of the presentation.  The current presentation relies upon the
	user having some familiarity with mh; this was appropriate for
	the original use of xmh, but isn't a reasonable basis for a
	primary mail interface.

	One notion I'd like to experiment with is an 'Explain' button ala
	emacs 'describe-key'.

	6. The manual page is not clear on the button usage for scrollbars.

	Yep, a general problem.

     7. Support for hierarchical folders would be nice.

     	I've wanted to add this for a long time.  The biggest stumbling
	block has been designing an appropriate visual interface that
	is real-estate efficient.

     8. How do you refile messages into folders?

	See #5.  Clearly, help needs to be task oriented as well as
	function oriented.

     9. The editor is slow.

	See #3.  Certain operations are un-necessarily slow (e.g. select)
	and warrant special attention in addition to the over-all performance
	tuning.

     10. Have double-click on a folder open it.  Have double-click on a sequence
     	open it.

	Fine.

     11. What do you think of a menu interface instead of the rows of buttons?

     	Ideally, one might want a user-configurable (via resource specifications)
	interface.  Folders, sequences and infrequently used commands might want
	to be implemented on a pop-up menu (to save real estate) but some
	combination of other functions remain as buttons (for fast access).

     12. MH is inherently clunky, and this is reflected in [X]MH.

     Xmh does perhaps expose too much of the structure of mh.  See #5.
	Suggestions for re-packaging functions are welcome, but one needs
	to consider whether xmh should remain as the visual front-end to
	mh or whether it should diverge in ways that would confuse a user
	desiring to alternate between mh and xmh.

     13. xmh requires one to fiddle with the resources.

	Any _requirement_ to change a resource should be reported as a
	bug.  The only such thing I'm aware of is the default geometry.
	I suspect, however, that there is no single geometry that will
	satisfy both the casual and the heavy mail user.

     14. How about a different editor interface (e.g., vi)?

	I'd like to consider ways to integrate foreign editors (as separate
	processes) into the text widget, but this is a long-range project.
	Editor fanatics seem to want the whole thing, not being able to
	agree on any substantial subset.

     15. The buttons aren't size and shape configurable (for changing fonts).

     This sounds like a bug, if it's true.  But in the case of fonts, I
	don't believe it.  Perhaps the documentation is insufficient.

     16. It requires use of the mouse.

	I concur with Win's response.  Additional work on the widgets to
	permit user configuration of any toolkit application for keyboard-only
	control is planned.

     17. It should not be so sensitive to errors.

	More attention can be paid to attempting recovery from some problems.
	Most errors, however, are due to file system problems which will
	eventually have substantial repurcussions.  The simplest quick fix,
	though, would be to give the user the option to continue or quit.

     18. The editor isn't really emacs.

	See #14.

     19. "reply" should allow "-cc all".

	See #2.  This also raises the issue of one-time modifiers vs.
	(semi-)permanent reconfigurations.  The layering on top of mh
	adds some restrictions on the interactive mechanisms that could
	be easily implemented.  For example, a set of buttons for all the
	combinations of options for a command would be disastrous, but
	a pull-down menu on the reply window (after it has been created)
	would be too late w.r.t. the mh command that constructs the
	initial window contents.

     20. A button for 'ispell' would be nice.

	Fine idea.  We should implement user-definable filters; ispell is
	only one possible instance.

     21. It would be nice to specify which folders are given buttons.

	Hmm.  And the others would be on a pop-up menu?  Or would you
	rather simply specify the order of the buttons so you can resize
	the pane and use the scrollbar to select sets?

     22. It takes up too much screen real estate.

	Suggestions on improvements are welcome.  See also #4 and #11.

     23. A way to interrupt, say,  a reply before the editor window comes up
     	would be nice.

	A reasonable idea for those actions that actually spawn mh processes
	(or take a indeterminate time, i.e. 'commit').

     24. It loses its place in the scan listing.

	Bug.