[comp.windows.x] Properties option in olwm workspace menu

jdb26@LOCAL.UUCP (05/16/91)

We have a problem with the Workspace Properties option in the workspace
menu under OpenWindows 2.0.  When you apply changes, your .Xdefaults file
is overwritten with the entire contents of the RESOURCE_MANAGER property.

This is a problem in our environment since user's typically have many
more resources loaded in RESOURCE_MANAGER than what is in their .Xdefaults
file and we don't want those other resources in .Xdefaults.

Do others feel this is a problem?
Any suggested workarounds?
Any possibility SUN may change this in the future?


Jeff Bailey                        |  All opinions are my own and do not
Chemical Abstracts Service         |  necessarily reflect those of my
Columbus, OH 43221                 |  employer.
(614) 447-3600 (x3092)             |
                                   |
BITNET: jdb26@cas.bitnet           |
UUCP:   osu-cis!chemabs!jdb26      |

doug@genmri.UUCP (Doug Becker) (05/17/91)

The OW Workspace Properties tool does present a nice veneer over X
resources (mostly for the X novice's benefit), but it does have its
deficiencies.
    
    Do others feel this is a problem?

Yes.  On top of the reason you listed, Xrm doesn't maintain resource file
comments.  Although the props client displays a notice to warn you that
your comments are about to be obliterated (thankfully), I still find this
annoying (enough so that I don't use props).  This is not really props'
fault, but props could probably be improved upon nonetheless.

    Any suggested workarounds?

How about "Don't use props"?  I read documentation and modify resources the
traditional way, i.e., by hand (although I'll be very interested to see
Chris Peterson's EditRes client in R5).

    Any possibility SUN may change this in the future?

I don't know.  Speaking about my problem, I think it would be nice if Xrm
were modified to preserve comments in the databases it creates.  (I'll
expect the letter from Bob Scheifler now saying either "That wouldn't
work," or "Yes, we've thought of that -- how about writing the spec (and
the implementation)?" :-)

I think a reasonable solution to your problem might be to have props create
and maintain its own private resource database (containing no entries from
any other source).  The user could choose where he wanted the resultant
resources to be merged/put when Apply is pressed (the default being
~/.Xdefaults).  Props could then merge its (fully-qualified) resources with
a database created solely from the specified file (if any), and write out
the result.

-- 

Doug Becker
doug@nmri.ge.com
crdgw1!sane!doug