Path: utzoo!attcan!uunet!cs.utexas.edu!yale!mintaka!mit-eddie!ll-xn!knorr.ll.mit.edu!jjh
From: jjh@knorr.ll.mit.edu (James J Hunt)
Newsgroups: comp.windows.x
Subject: Re: what's most important to you for R5?
Message-ID: <1924@xn.LL.MIT.EDU>
Date: 3 Jul 90 16:54:20 GMT
References: <RAMANI.90Jun30171548@modesty.Stanford.EDU>
Sender: news@XN.LL.MIT.EDU
Organization: MIT Lincoln Laboratory, Lexington, MA
Lines: 46

There are three things I would like to see in R4:

	1) an additional standard resource & switch which would allow a user
	   to specify any valid X11 bitmap file of any size as icon for an
	   application,

	2) have a standard event for ``drag and drop'' which includes the
	   files machine, path, and mount information (both local and
	   remote),

	3) a method to change the event inheritance so that events not in a
	   given windows event mask could be passed to any window.

The first item may not seem very important, but being able to customize
icons really improved their informational content and hence their
usefulness.  For instance, I like to have a special icon for my console
xterm.  I suggest using -ibm for the switch and .iconBitmap as the resource
name.

Drag and drop is well suited to unsophisticated users.  I do not
particularly like this metaphor, but many people do.  We are starting to see
it used in X based UIs such as XView, and it would be nice to have a single
standard.  Specifying just a file path name is insufficient in a multi-host
environment, so passing a host name as well is appropriate.  This is often
not optimal do to the use of a remote file system, so enough mount
information should be given to decide if the receiving application has the
file mounted locally, and if not where is the best place from which to get
it.  This is better than sending the entire file, especially for things like
editors that want to write the file back at the end.

Being able to change the event inheritance is another way of smoothing out
the user interface.  For example, in a panel it should be possible to direct
all keyboard inputs to a particular window when the cursor is over the
panel; and in a drawing window it should be possible to send keyboard events
to a command interpreter window.  In general this would reduce the necessity
to move the cursor when doing mix mouse/keyboard entry.

Certainly all the tools in the mit directory will accept and follow all the
standard switches/resources.  It is probably too much to ask that all the
tools in the contrib directory do likewise.  Instead the contrib directory
should be broken up into those tools that CLAIM to follow the user interface
standards and those that do not.  This should not require much extra work on
the part of the distributors of X, but would give the user community a
little more information about the contributed tools in the distribution.

	JJHunt