* Re: Program-specified positions ignored?
@ 2002-10-03 20:06 Jan D.
2002-10-04 15:46 ` Richard Stallman
0 siblings, 1 reply; 9+ messages in thread
From: Jan D. @ 2002-10-03 20:06 UTC (permalink / raw)
Cc: rms, emacs-devel
> > 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?
A comment on the problem that started this, should not Emacs consider
positions and sizes specified in .emacs as user specified?
Jan D.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Program-specified positions ignored?
2002-10-03 20:06 Program-specified positions ignored? Jan D.
@ 2002-10-04 15:46 ` Richard Stallman
2002-10-04 16:01 ` Stefan Monnier
0 siblings, 1 reply; 9+ messages in thread
From: Richard Stallman @ 2002-10-04 15:46 UTC (permalink / raw)
Cc: jhd, emacs-devel
> > 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?
A comment on the problem that started this, should not Emacs consider
positions and sizes specified in .emacs as user specified?
There are arguments both ways, but I think the better choice is
not to do so.
Can you help us figure out how to make program-specified positions
work properly?
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: Program-specified positions ignored?
2002-10-04 15:46 ` Richard Stallman
@ 2002-10-04 16:01 ` Stefan Monnier
2002-10-05 16:33 ` Richard Stallman
0 siblings, 1 reply; 9+ messages in thread
From: Stefan Monnier @ 2002-10-04 16:01 UTC (permalink / raw)
Cc: jan.h.d, jhd, emacs-devel
> > > 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?
>
> A comment on the problem that started this, should not Emacs consider
> positions and sizes specified in .emacs as user specified?
>
> There are arguments both ways, but I think the better choice is
> not to do so.
Why is that ?
Every call to `make-frame' can use a different set of size/position
parameters, so it is clearly more specific than Xresource settings.
I think more-specific should imply higher-priority.
Similarly, I believe that custom face settings take precedence over
Xresource face settings, or am I confused ?
Stefan
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Program-specified positions ignored?
2002-10-04 16:01 ` Stefan Monnier
@ 2002-10-05 16:33 ` Richard Stallman
2002-10-05 16:55 ` Stefan Monnier
0 siblings, 1 reply; 9+ messages in thread
From: Richard Stallman @ 2002-10-05 16:33 UTC (permalink / raw)
Cc: jan.h.d, jhd, emacs-devel
> A comment on the problem that started this, should not Emacs consider
> positions and sizes specified in .emacs as user specified?
>
> There are arguments both ways, but I think the better choice is
> not to do so.
Why is that ?
Because "user specified" positions means positions specified for a
single session by the user. Defaults specified in configuration files
are not "user specified".
Every call to `make-frame' can use a different set of size/position
parameters, so it is clearly more specific than Xresource settings.
That is true but I don't think it relates to the question. If you
call `make-frame', your arguments can say that the positions are "user
specified". You can label th evalues either way you wish.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Program-specified positions ignored?
@ 2002-09-15 1:51 Richard Stallman
2002-10-03 18:58 ` Jan D.
0 siblings, 1 reply; 9+ messages in thread
From: Richard Stallman @ 2002-09-15 1:51 UTC (permalink / raw)
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?
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
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: Program-specified positions ignored?
2002-09-15 1:51 Richard Stallman
@ 2002-10-03 18:58 ` Jan D.
2002-10-04 22:09 ` Richard Stallman
0 siblings, 1 reply; 9+ messages in thread
From: Jan D. @ 2002-10-03 18:58 UTC (permalink / raw)
Cc: emacs-devel
> 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
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: Program-specified positions ignored?
2002-10-03 18:58 ` Jan D.
@ 2002-10-04 22:09 ` Richard Stallman
2002-10-05 23:47 ` Jan D.
0 siblings, 1 reply; 9+ messages in thread
From: Richard Stallman @ 2002-10-04 22:09 UTC (permalink / raw)
Cc: emacs-devel
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.
The code sets XtNgeometry for *user* positions. That is correct, I
believe; user positions are supposed to override .Xdefaults. But it
sounds like fallback resources are the right way to implement
program-specified positions.
Could you possibly implement that?
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: Program-specified positions ignored?
2002-10-04 22:09 ` Richard Stallman
@ 2002-10-05 23:47 ` Jan D.
0 siblings, 0 replies; 9+ messages in thread
From: Jan D. @ 2002-10-05 23:47 UTC (permalink / raw)
Cc: emacs-devel
> 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.
>
> The code sets XtNgeometry for *user* positions. That is correct, I
> believe; user positions are supposed to override .Xdefaults. But it
> sounds like fallback resources are the right way to implement
> program-specified positions.
>
> Could you possibly implement that?
I will put it on my TODO list.
Jan D.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2002-10-05 23:47 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-10-03 20:06 Program-specified positions ignored? Jan D.
2002-10-04 15:46 ` Richard Stallman
2002-10-04 16:01 ` Stefan Monnier
2002-10-05 16:33 ` Richard Stallman
2002-10-05 16:55 ` Stefan Monnier
-- strict thread matches above, loose matches on Subject: below --
2002-09-15 1:51 Richard Stallman
2002-10-03 18:58 ` Jan D.
2002-10-04 22:09 ` Richard Stallman
2002-10-05 23:47 ` Jan D.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.