Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!bloom-beacon!gatech!hubcap!ncrcae!ncr-sd!hp-sdd!hplabs!ucbvax!ZERMATT.LCS.MIT.EDU!RWS
From: RWS@ZERMATT.LCS.MIT.EDU (Robert Scheifler)
Newsgroups: comp.windows.x
Subject: For comment: problems with toolkit arg processing/philosophy
Message-ID: <871106083928.4.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Fri, 6-Nov-87 08:39:00 EST
Article-I.D.: KILLINGT.871106083928.4.RWS
Posted: Fri Nov  6 08:39:00 1987
Date-Received: Sun, 8-Nov-87 16:08:19 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 96

Date: Mon, 2 Nov 87 15:21:44 PST
From: bilbo.geoff@CS.UCLA.EDU (     Geoff Kuenning)
Subject:        Bug report -- problems with toolkit arg processing/philosophy

VERSION:
	X11 release 1
SYNOPSIS:
	Argument processing buggy, nonstandard, and problematic
DESCRIPTION:
	The argument processing in XrmParseCommand is both buggy and
	poorly designed.  The bugs are in the handling of special
	characters:  any argument that contains a colon, or that
	begins with an equals sign, will be taken as a display name
	or geometry specification, respectively.  This is done
	without regard to whether or not such an argument has
	already been seen, so that in a command such as:  

	    xedit athena:0 /usr/src/cmd/sys5:mk

	will fail because it can't connect to machine "/usr/src/cmd".

	This bug brings up a much larger issue, which is the X
	project's approach to argument design.  The standard for
	command-line arguments, adopted by AT&T, Sun, and the Posix
	groups, calls for single-character flags only, with
	arguments accepted either concatenated or separate.  The
	ONLY acceptable leadin character is "-";  negating flags
	with "+" or using special characters such as "=" to indicate
	certain types of arguments are not allowed.  

	Note that there is very little to be gained from the special
	treatment of the equals sign and colon.  The programs I have
	written use getopt-style parsing, and accept "-d" for the
	display name and "-g" for geometry.  I do not find it
	especially onerous to type these two extra characters,
	especially because it frees me up to use colons and equals
	signs in my file names and other arguments.  

	A related issue is the approach to resource setting in the
	toolkit.  The current approach requires the main() routine
	to support a wide variety of switches, several per widget
	used.  If there are several similar widgets, it can be
	difficult to come up with switch names for their many
	resources (e.g., horizscrollthumbcolor...).  Furthermore,
	the table in the main() routine must be aware of all of the
	command-line-settable resources supported by every widget it
	uses.  (This is in contrast to the parsing of the .Xdefaults
	file, where the information table comes from the widget
	itself.)
  
	A possible solution to the latter issue is to use a generic
	"-R" switch to specify resources, for example:  

	    xterm -d athena:0 -g =-0-0 \
	      -R 'scroll.background: green,scroll.thumb: blue'

	The -R switch could be repeated to specify multiple
	resources, or a comma can be used as in the example above.
	(This should be a user option).  Newline should also be
	supported as a separator.  

	This supports complete flexibility without forcing a whole
	incompatible switch scheme on the programmer.  For a cost of
	three switches, I can set any resource of any widget ever
	invented, and the rest of the single-character switch space
	is still available for my application.  

	One minor detail is in the implementation:  XtInitialize,
	which needs to know the display name, should be separate
	from resource initialization.  This is so the user can
	write:  

	    XrmInitialize ();
	    while ((optch = getopt (argc, argv, "d:g:R:")) != EOF)
		{
		switch (optch)
		    {
		    case 'd':
			displayname = optarg;
			break;
		    case 'g':
			geometry = optarg;
			break;
		    case 'R':
			XrmAddCommandResources (optarg);
			break;
		    }
		}
	    XtInitialize (displayname, ...);
REPEAT-BY:
	Eyeball the code
FIX:
	Nontrivial, though not difficult.  See the suggestions
	above.

	Geoff Kuenning	geoff@lcc.ucla.edu	geoff@ITcorp.com