[Groff] Re: Fw: More comments on groff-1.11a (and earlier versions)

[Larry Jones]

Nelson H. F. Beebe writes:
> 
> That is what I object to; the defaults should be compiled in, and THEN
> the user should be able to provide an additional place to look, such
> as the XFILESEARCHPATH, for changes.  That way, the program can run in
> the absence of any startup files.
>
> Emacs and almost all X applications follow this model, but groff is
> the bad boy that won't run unless it can find its app-defaults file.

On the contrary, according to the X Toolkit Intrinsics manual (my
emphasis):

        Lastly, the application-specific class resource file from the
        local host is merged into the screen resource database. [...]
        This file is expected to be provided by the developer of the
        application and MAY BE REQUIRED FOR THE APPLICATION TO RUN
        PROPERLY.  A SIMPLE application that wants to be assured of
        having a minimal set of resources in the absence of its class
        resource file can declare fallback resource specifications with
        XtAppSetFallbackResources.

A quick grep through the X11R6 distribution shows that only 25 programs
out of over 100 call XtAppSetFallbackResources; although some of those
programs may be very simple and not require any resource settings to run
correctly, it's a good bet that more than half the programs in the
standard distribution won't run correctly without their app-defaults
files.  In some respects, gxditview should be commended for refusing to
run rather than running and being unusable like many other applications.
(For example, the standard xditview, when run without its app-defaults
file, comes up, looks a little peculiar, and the file menu is completely
non-functional.  Other things probably are too, but I didn't look any
farther.)

> That is a big problem: we have 200+ UNIX systems running a dozen
> different O/S versions from all of the major UNIX hardware vendors,
> and 10,000 users who aren't expert enough to be able to figure out why
> groff stupidly complains about a zero window height and quits.  Even
> if we define XFILESEARCHPATH in a system-wide startup file, there is
> no way to prevent users from redefining it, and anywhere, on all of
> those systems, there is no standard way to even get such a definition
> reliably in place.  Unlike our old TOPS-20 and VAX VMS systems, UNIX
> has no notion of system-wide environment variables that all shells
> inherit from the kernel.

I understand the problem.  That is why most of us install X programs in
the system standard place instead of in /usr/local like we do for non-X
programs.  If you choose to install programs in non-standard places,
then you have to arrange for users to be able to run them (usually by
setting PATH) and have access to their documentation (usually by setting
MANPATH), arranging for them to be able to find their app-defaults file
isn't any different.

It's probably also worth noting that XFILESEARCHPATH is used to locate
files that are considered to be part of the system, *NOT* user-specific
files, so a user shouldn't be redefining it.  Users should define other
environment variables (like XAPPLRESDIR or XUSERFILESEARCHPATH) to
control where X looks for user-specific files.

Now, having said all that, I don't necessarily disagree that it would be
nice for gxditview to have fallback-resources.  It would also be nice if
it were up-to-date with xditview.  It would be even nicer if the changes
in it could be propogated back into xditview so we don't have to have
two very similar but slightly different programs.  Unfortunately,
gxditview is mostly without a maintainer.  Perhaps someone will take an
interest and find some time to do some of these things, but I wouldn't
hold my breath if I were you.  And I wouldn't count on it to solve all
your problems.

-Larry Jones

Girls are so weird. -- Calvin