From xemacs-m  Thu Sep  4 22:36:28 1997
Received: from turnbull.sk.tsukuba.ac.jp (root@turnbull.sk.tsukuba.ac.jp [130.158.99.4])
	by xemacs.org (8.8.5/8.8.5) with SMTP id WAA09979
	for <xemacs-beta@xemacs.org>; Thu, 4 Sep 1997 22:36:25 -0500 (CDT)
Received: from turnbull.sk.tsukuba.ac.jp(really [127.0.0.1]) by turnbull.sk.tsukuba.ac.jp
	via smtpd with esmtp
	id <m0x6qXV-000025C@turnbull.sk.tsukuba.ac.jp>
	for <xemacs-beta@xemacs.org>; Fri, 5 Sep 1997 14:02:37 +0900 (JST)
	(Smail-3.2 1996-Jul-4 #3 built 1997-Jun-24)
Message-Id: <m0x6qXV-000025C@turnbull.sk.tsukuba.ac.jp>
To: xemacs-beta@xemacs.org
Subject: Re: Bug with -xrm 
In-reply-to: Your message of "04 Sep 1997 12:22:01 +0300."
             <of0pvqpa0xy.fsf@gamgee.ntc.nokia.com> 
Date: Fri, 05 Sep 1997 14:02:37 +0900
From: "Stephen J. Turnbull" <turnbull@turnbull.sk.tsukuba.ac.jp>

>>>>> "Pema" == Pekka Marjola <pema@iki.fi> writes:

>>>>> In <qyjrabi48k6.fsf@metheny.enst.fr>,
>>>>> On 25 Aug 1997 16:54:33 +0200,
>>>>> "DV" == Didier Verna <verna@inf.enst.fr> writes:

    >>> Pekka Marjola <pema@iki.fi> writes:
    >>> 
    >>> > I have been using xemacs -xrm "*Desk: 4" to get XEmacs on
    >>> > certain fvwm desktop for a long time now. At some latest
    >>> > 20.3 betas it does not work anymore for some reason.

    DV> According to what they say in the fvwm man page, this Xt
    DV> resource is not handled directly by fvwm, but should be

Window manager man pages are notoriously lossy when anything related
to internals comes up....

If you look at the FVWM2 code, what apparently happens (fvwm-2.0.42)
is that FVWM parses the XEmacs command line to get that information.
There is no mechanism I could find (in a quick skim of the source) to
get the information but this (fvwm/add_window.c line 215/921):

  /* Find out if the client requested a specific desk on the command line. */
  if (XGetCommand (dpy, tmp_win->w, &client_argv, &client_argc)) {
      XrmParseCommand (&db, table, 4, "fvwm", &client_argc, client_argv);
      status = XrmGetResource (db, "fvwm.desk", "Fvwm.Desk",
                               &str_type, &rm_value);
      if ((status == True) && (rm_value.size != 0)) {
          Desk = atoi(rm_value.addr);
          tflag |= STARTSONDESK_FLAG;
      }
      XrmDestroyDatabase (db);
      db = NULL;
  }

    DV> supported by each application willing to support it (I think
    DV> it means that each application supporting this resource will
    DV> ask the WM for a particular position on screen). After

I don't think so.  "Supporting the option" apparently simply means not
spewing chunks when faced with the `-xrm' option.  In particular, FVWM
needed to have a backward compatible mechanism so could not depend on
applications setting properties and other ICCCM.  Parsing the client's
command line is a somewhat backward-compatible way (not perfect
because lots of programs mess with their command lines, eg to fool
`ps') to arrange for many older programs to put a quasi-resource where
FVWM can find it---if they don't abort and spew usage on the `-xrm'
option---_without_ rebuilding.

The right way[tm] of course is to define an XA_WM_DESKTOP property
which programs would set as a hint.  (I believe that in fact FVWM does
this after grabbing the data from the command line, but to be sure I'd
have to read the code a lot more carefully.)  But that requires
rebuilding all the clients.

    DV> checking in xemacs source code, I found no trace of such a
    DV> resource. So we can't really say it is a bug can we ?  It just
    DV> mean that xemacs doesn't support it.

    Pema> Actually, the man page says the the application must support
    Pema> resource loading that way (Xt). Just checked out... b15
    Pema> works correctly, b16 does not. I browsed through the b15-b16

Wrong place to look :-)

    Pema> patch, but didn't find out what's causing the
    Pema> change. Someone who made changes, please...

Something apparently is munging the command line returned by
XGetCommand().  Check with the people doing session-management code,
at a guess.  This should not be problematical to fix; it just requires 
doing whatever the session manager wants to do _after_ the top-level
window gets mapped and reparented.  But then, what do I know....

    Pema> BTW, for example xemacs-20.3-b18 xrm "Emacs.Foreground:
    Pema> white" & does (still) work.

    Pema> Hmm... 'Emacs*Desk: 4' resource didn't work for pre-b16s,
    Pema> either ('*Desk: 4' works).

This is an FVWM resource, not an Emacs resource.  The correct spec is
'Fvwm*Desk' (see the code snippet above).

Steve

-- 
                            Stephen J. Turnbull
Institute of Policy and Planning Sciences                    Yaseppochi-Gumi
University of Tsukuba                      http://turnbull.sk.tsukuba.ac.jp/
Tel: +81 (298) 53-5091;  Fax: 55-3849              turnbull@sk.tsukuba.ac.jp

