ddtl wrote:

> Hello,

> I would like to be able to maximize xterm's window so that
> it would fill the screen. The problem is, that xterm's window
> size is measured in terms of current font's width/height and not
> in pixels, so that you say: "I want xterm to be 79x39 chars" instead
> of 800x600 pixels. That causes xterm's window to be either bigger
> or smaller than the screen, because for most x

> (x chars) != (width/height of a screen)

> Is it possible somehow to make xterm's window exactly the same size
> as a screen (or any other size, for that matter) - of course in that

probably not without a lot of change to xterm's geometry management -
it's using the window manager to ensure that resizing is done in
whole character increments.

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

Thomas Dickey writes:

> ddtl wrote:
>
>> Hello,
>
>> I would like to be able to maximize xterm's window so that
>> it would fill the screen. The problem is, that xterm's window
>> size is measured in terms of current font's width/height and not
>> in pixels, so that you say: "I want xterm to be 79x39 chars" instead
>> of 800x600 pixels. That causes xterm's window to be either bigger
>> or smaller than the screen, because for most x
>
>> (x chars) != (width/height of a screen)
>
>> Is it possible somehow to make xterm's window exactly the same size
>> as a screen (or any other size, for that matter) - of course in that
>
> probably not without a lot of change to xterm's geometry management -
> it's using the window manager to ensure that resizing is done in
> whole character increments.

Perhaps the OP can adjust the window manager frame width and title
height to make up the difference.

In comp.windows.x, ddtl

wrote
on Thu, 17 Jun 2004 15:42:36 +0200
:
>
> Hello,
>
> I would like to be able to maximize xterm's window so that
> it would fill the screen. The problem is, that xterm's window
> size is measured in terms of current font's width/height and not
> in pixels, so that you say: "I want xterm to be 79x39 chars" instead
> of 800x600 pixels. That causes xterm's window to be either bigger
> or smaller than the screen, because for most x
>
> (x chars) != (width/height of a screen)
>
> Is it possible somehow to make xterm's window exactly the same size
> as a screen (or any other size, for that matter) - of course in that
> case the last line/column will have to show less than a whole character,
> but many applications do that (and the window is scrolled when cursor
> goes below the last line/column which shows the whole character).
>
> It is possible, of course, to find a font/size of a font for which
>
> (x chars) == (width/height of a screen)
>
> but I like the font/size currently in use and don't want to change it.
>
>
> ddtl.
>

There's not a lot that one can do here. If you're really sold on
xterm you're probably stuck. If you are willing to use other terminal
emulators you might have better luck; KDE's terminal emulator in
particular can fill the screen. (Gnome's apparently has the same
behavior as xterm in this case.)

I should note that your font/size has to take into account titling
and window borders, which makes the computation a little uglier.

--
#191, ewill3@earthlink.net
It's still legal to go .sigless.

Dan Espen wrote:

> Perhaps the OP can adjust the window manager frame width and title
> height to make up the difference.

That's a possibility (I was considering only the shell widget).

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

Dan Espen wrote:
>Thomas Dickey writes:
>
>> ddtl wrote:
>>
>>> Hello,
>>
>>> I would like to be able to maximize xterm's window so that
>>> it would fill the screen. The problem is, that xterm's window
>>> size is measured in terms of current font's width/height and not
>>> in pixels, so that you say: "I want xterm to be 79x39 chars" instead
>>> of 800x600 pixels. That causes xterm's window to be either bigger
>>> or smaller than the screen, because for most x
>>
>>> (x chars) != (width/height of a screen)
>>
>>> Is it possible somehow to make xterm's window exactly the same size
>>> as a screen (or any other size, for that matter) - of course in that
>>
>> probably not without a lot of change to xterm's geometry management -
>> it's using the window manager to ensure that resizing is done in
>> whole character increments.
>
>Perhaps the OP can adjust the window manager frame width and title
>height to make up the difference.
>

Another possibility is to use the -b option on xterm to set an inner border.

Kip Rugger wrote:

> Another possibility is to use the -b option on xterm to set an inner border.

That won't work, since the vertical and horizontal borders would in
general be different thicknesses.

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

Thomas Dickey wrote:
>Kip Rugger wrote:
>
>> Another possibility is to use the -b option on xterm to set an inner border.
>
>That won't work, since the vertical and horizontal borders would in
>general be different thicknesses.

True, but let's backup a bit.

The original question was how to get a full-screen xterm: I took this to
mean pushing window manager decorations off screen without clipping any
characters (except maybe on the top row). This is where I see setting
an internal border to be useful -- you only need to worry about the width.

The OP then made the assumption that the full-screen problem could be
solved by somehow requesting a size in pixels, rather than in characters,
and asked how that would be done. The answer that we would like to give
him is something like

xterm -xrm '?.width: 2000' -xrm '?.height: 1500'

but xterm's resource handling is in such breakage that this won't work.

This happens despite the fact that xterm can handle arbitrary sizes (if
you tell your wm to ignore xterm's size hints).

Kip Rugger wrote:
> Thomas Dickey wrote:
>>Kip Rugger wrote:
>>
>>> Another possibility is to use the -b option on xterm to set an inner border.
>>
>>That won't work, since the vertical and horizontal borders would in
>>general be different thicknesses.

> True, but let's backup a bit.

> The original question was how to get a full-screen xterm: I took this to
> mean pushing window manager decorations off screen without clipping any
> characters (except maybe on the top row). This is where I see setting
> an internal border to be useful -- you only need to worry about the width.

I assume that some window managers may not work properly if their decorations
are pushed offscreen.

> The OP then made the assumption that the full-screen problem could be
> solved by somehow requesting a size in pixels, rather than in characters,
> and asked how that would be done. The answer that we would like to give
> him is something like

> xterm -xrm '?.width: 2000' -xrm '?.height: 1500'

> but xterm's resource handling is in such breakage that this won't work.

> This happens despite the fact that xterm can handle arbitrary sizes (if
> you tell your wm to ignore xterm's size hints).

hmm - the last two sentences seem to imply you have some further comments.

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

Thomas Dickey wrote:
>Kip Rugger wrote:
>> Thomas Dickey wrote:
>>>Kip Rugger wrote:
>>>
>>>> Another possibility is to use the -b option on xterm to set an inner border.
>>>
>>>That won't work, since the vertical and horizontal borders would in
>>>general be different thicknesses.
>
>> True, but let's backup a bit.
>
>> The original question was how to get a full-screen xterm: I took this to
>> mean pushing window manager decorations off screen without clipping any
>> characters (except maybe on the top row). This is where I see setting
>> an internal border to be useful -- you only need to worry about the width.
>
>I assume that some window managers may not work properly if their decorations
>are pushed offscreen.

Really? That would seem to violate the user-in-control paradigm.

>> The OP then made the assumption that the full-screen problem could be
>> solved by somehow requesting a size in pixels, rather than in characters,
>> and asked how that would be done. The answer that we would like to give
>> him is something like
>
>> xterm -xrm '?.width: 2000' -xrm '?.height: 1500'
>
>> but xterm's resource handling is in such breakage that this won't work.
>
>> This happens despite the fact that xterm can handle arbitrary sizes (if
>> you tell your wm to ignore xterm's size hints).
>
>hmm - the last two sentences seem to imply you have some further comments.

I *always* have further comments, it just requires the suspension of
disbelief to think that anyone wants to hear them ...

I attach here a small program that does what xterm tries to do with Xt.
The difference is that this example handles resources properly. It can
take three types of parameters:

1. -b nnn for an internal border à la xterm

2. -geometry -rv -bg ..., the standard Xt options

3. -xrm '?.width:100' ..., the Xt method of specifying
command-line resources

There is a common error in OO programming, and that is the tendency to
fight with super-classes in order to force them to do exactly what you
think they should be doing. I think xterm has this problem big time:
there is no reason it should be trying to do the shell widget's work.


#include
#include
#include
#include
#include

static Dimension border;
static XFontStruct * font;
static Dimension fwidth, fheight;
static Display * dpy;

static void
Redraw(Widget w, XtPointer closure, XEvent * event, Boolean * cont)
{
Dimension wwidth, wheight, xoff, yoff;
Cardinal rows, cols;
int y, rn, nstring;
GC gc = DefaultGC(dpy, DefaultScreen(dpy));
static char * string="The quick brown fox jumped over the lazy dos";

XtVaGetValues(w, XtNwidth, &wwidth, XtNheight, &wheight, 0);

wwidth -= border * 2, wheight -= border * 2;

cols = wwidth / fwidth, rows = wheight / fheight;
xoff = (wwidth % fwidth)/2 + border;
yoff = (wheight % fheight)/2 + border + font->ascent;

nstring = strlen(string) < cols ? strlen(string) : cols;

XSetFont(dpy, gc, font->fid);
if (event->type == ConfigureNotify) XClearWindow(dpy, XtWindow(w));
for (y = yoff, rn = 0; rn < rows; y += fheight, rn++)
XDrawString(dpy, XtWindow(w), gc, xoff, y, string, nstring);
}

static XrmOptionDescRec options[] = {
{ "-b", ".intborder", XrmoptionSepArg, 0 },
};

int
main(int argc, char * argv[])
{
XtAppContext appc;
Widget toplevel, textwin;
XrmValue rmv;
char * type;

XtToolkitInitialize();
appc = XtCreateApplicationContext();
dpy = XtOpenDisplay(appc, 0, "text", "Text",
options, XtNumber(options), &argc, argv);

font = XLoadQueryFont(dpy, "fixed");
fwidth = font->max_bounds.width, fheight = font->ascent+font->descent;

border = XrmGetResource(XrmGetDatabase(dpy), "text.intborder",
"Text.Intborder", &type, &rmv)
? strtol(rmv.addr, 0, 10) : 0;

toplevel = XtVaAppCreateShell(0, "Text",
applicationShellWidgetClass, dpy,
XtNwidthInc, fwidth, XtNheightInc, fheight, // resize quanta
0);

textwin = XtVaCreateManagedWidget("textwin", coreWidgetClass, toplevel,
XtNwidth, fwidth * 30 + 2 * border, // default geom 30x10
XtNheight, fheight * 10 + 2 * border,
0);
XtAddEventHandler(textwin, ExposureMask|StructureNotifyMask,
0, Redraw, 0);

XtRealizeWidget(toplevel);
XtAppMainLoop(appc);
return 0;
}

and here is an Imakefile to build it:

SYS_LIBRARIES = -lXt -lX11
AllTarget(textwin)
NormalProgramTarget(textwin, textwin.o ,,,)

kbr@pangea.ca (Kip Rugger) writes:

> Thomas Dickey wrote:
>>Kip Rugger wrote:
>>> Thomas Dickey wrote:
>>>>Kip Rugger wrote:
>>>>
>>>>> Another possibility is to use the -b option on xterm to set an inner border.
>>>>
>>>>That won't work, since the vertical and horizontal borders would in
>>>>general be different thicknesses.
>>
>>> True, but let's backup a bit.
>>
>>> The original question was how to get a full-screen xterm: I took this to
>>> mean pushing window manager decorations off screen without clipping any
>>> characters (except maybe on the top row). This is where I see setting
>>> an internal border to be useful -- you only need to worry about the width.
>>
>>I assume that some window managers may not work properly if their decorations
>>are pushed offscreen.
>
> Really? That would seem to violate the user-in-control paradigm.

In the case of fvwm, the off-screen borders would show on adjacent
virtual pages.

I don't know if that was what was meant by "not work properly".

Dan Espen wrote:
> In the case of fvwm, the off-screen borders would show on adjacent
> virtual pages.

I had in mind the behavior of negative coordinates (upper-left).
Dimension is an unsigned 16-bit number...

> I don't know if that was what was meant by "not work properly".

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

Kip Rugger wrote:

> I attach here a small program that does what xterm tries to do with Xt.
> The difference is that this example handles resources properly. It can
> take three types of parameters:

thanks (will study ;-)

> There is a common error in OO programming, and that is the tendency to
> fight with super-classes in order to force them to do exactly what you
> think they should be doing. I think xterm has this problem big time:
> there is no reason it should be trying to do the shell widget's work.

the part you're referring to is noted in the source as a kludge
(not something I did, but equally something I've not rewritten).

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net