Re: Program-specified positions ignored?

["Jan D." <jan.h.d@swipnet.se>]

> I looked at the bug report below, and it seems that the specified
> positions are not being used at all in the toolkit version, when the
> user-position parameter is nil.  (This corresponds to the USPosition
> flag for Xlib.)  Here is the code which does that?
> 
>       if (window_prompting & USPosition)
> 	sprintf (shell_position, "=%dx%d%c%d%c%d",
> 		 PIXEL_WIDTH (f) + extra_borders, 
> 		 PIXEL_HEIGHT (f) + menubar_size + extra_borders,
> 		 (xneg ? '-' : '+'), left,
> 		 (yneg ? '-' : '+'), top);
>       else
> 	sprintf (shell_position, "=%dx%d",
> 		 PIXEL_WIDTH (f) + extra_borders, 
> 		 PIXEL_HEIGHT (f) + menubar_size + extra_borders);
>     }
> 
>     len = strlen (shell_position) + 1;
>     /* We don't free this because we don't know whether
>        it is safe to free it while the frame exists.
>        It isn't worth the trouble of arranging to free it
>        when the frame is deleted.  */
>     tem = (char *) xmalloc (len);
>     strncpy (tem, shell_position, len);
>     XtSetArg (al[ac], XtNgeometry, tem); ac++;
>     XtSetValues (shell_widget, al, ac);
> 
> I am pretty sure that the reason for this is that including
> program-specified positions in XtNgeometry would override the window
> manager, which is wrong.  But if that is the wrong way to pass the
> program-specified positions to Xt, what is the right way?

If XtNgeometry is set in the program, it can't be overridden by
an entry in an .Xdefaults-file.  I think it is a mistake to set XtNgeometry
at all in a program, it disables the normal way to set this, via .Xdefaults.

Now, Emacs by itself reads .Xdefaults, so it takes these settings into 
account.  The way I prefer to handle these things is to set fallback
resources, either by using the ad2c (Convert app-defaults file to C
strings decls) program that floats around, or by hard coding the string
in the application.  The you pass an array of strings either to
XtAppSetFallbackResources (must be done before the Shell widget is created)
or to XtAppInitialize, which has such a parameter.  That way you get
reasonable defaults, that are all overridable by the user in his/hers
.Xdefaults file.

For example:
  String recs[] = { "*geometry: +100+100", NULL };
  XtAppSetFallbackResources (appC, recs);

I don't know if this is the "official" way, but many apps do like this and
it works well.  Ddd is one GNU program that does this.

Looking around, I see Emacs actually calls XtAppSetFallbackResources, but
it is rather pointless, because the second argument is:
  static String Xt_default_resources[] = {0};

	Jan D.

> 
> 
> X-Sender: jwj@alvie-mail.lanl.gov
> To: bug-gnu-emacs@gnu.org
> From: "Joseph W. Jackson" <jwj@lanl.gov>
> Subject: Emacs 21.2 Frame Parameters
> Sender: bug-gnu-emacs-admin@gnu.org
> Date: Tue, 06 Aug 2002 14:48:29 -0600
> 
> The more I dig into this the more I believe it is a bug.
> 
> I recently upgraded from Redhat Linux 7.2 to 7.3.  As part of the update, 
> my emacs changed from version 20.7 to Emacs 21.2 and I now find that 
> several of my frame customizations don't work.  In particular, the 
> frame-parameters "top" and "left" get ignored.
> 
> For example:
> In version 20.7 I used the following command to create a second frame 
> positioned all the way to the right of my screen:
>         (make-frame '((height . 70) (width .  93) (top . 0) (left .  581)))
> 
> under emacs 21.2.1 the command above produces a frame of height=70 and 
> width=93 but the window is positioned at top=0 and left=0.  I get an 
> identical result when I try to set "top" or "left" values for the variables 
> "special-display-frame-alist" and "default-frame-alist"
> 
> Something changed between the releases and, as of yet, I am unable to work 
> around the problem.
> 
> 
> 
> "No Single Raindrop Believes It Is Responsible For The Flood"  - Despair.com
> 
> 
> _______________________________________________
> Bug-gnu-emacs mailing list
> Bug-gnu-emacs@gnu.org
> http://mail.gnu.org/mailman/listinfo/bug-gnu-emacs
> 
> 
> 
> 
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://mail.gnu.org/mailman/listinfo/emacs-devel