Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 90717 - xterm-201 mishandles -geometry argument
Summary: xterm-201 mishandles -geometry argument
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Emanuele Giaquinta (RETIRED)
: 91967 (view as bug list)
Depends on:
Reported: 2005-04-28 07:57 UTC by Robert Forsman
Modified: 2006-05-30 15:26 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Robert Forsman 2005-04-28 07:57:26 UTC
Until I updated my xterm to ebuild xterm-201 I was able to use -geometry to control where the window pops up on the screen.
this morning my xterm -geom +0-0 popped up blank.

After a little experimentation, i discovered that -geom is controlling the placement of the text window WITHIN the application window.  I suspect the addition of the three menu buttons at the top triggered this.  The addition of the buttons is unwelcome in any case.

Reproducible: Always
Steps to Reproduce:
1. xterm -geom +100+100
2. laugh
Actual Results:  
The application window appears a some random location chosen by the window
manager, while the xterm graphics are drawn 100 pixels southeast of where they
should be within the window.

Expected Results:  
not suck

Portage (default-linux/x86/2005.0/2.4, gcc-3.3.5-20050130,
glibc-, 2.4.28-gentoo-r8 i686)
System uname: 2.4.28-gentoo-r8 i686 AMD Athlon(tm) 64 Processor 3000+
Gentoo Base System version 1.4.16
Python:              dev-lang/python-2.3.4-r1 [2.3.4 (#1, Feb 23 2005, 16:44:54)]
dev-lang/python:     2.3.4-r1
sys-devel/autoconf:  2.59-r6, 2.13
sys-devel/automake:  1.7.9-r1, 1.8.5-r3, 1.5, 1.4_p6, 1.6.3, 1.9.4
sys-devel/libtool:   1.5.16
virtual/os-headers:  2.4.22-r1
CFLAGS="-O2 -march=i686 -fomit-frame-pointer"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env
/usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config
/usr/lib/X11/xkb /usr/share/config /usr/share/texmf/dvipdfm/config/
/usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/
/usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/bind
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O2 -march=i686 -fomit-frame-pointer"
FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms strict"
USE="x86 3dnow 3dnowex X Xaw3d acl apache2 apm arts avi bash-completion berkdb
bitmap-fonts bonobo bzlib cdr crypt cups curl divx4linux doc dv dvb dvd dvdr
dvdread edl emboss encode esd fam ffmpeg foomaticdb gdbm gif gnome gpm gtk gtk2
gtkhtml guile imagemagick imlib ipv6 java jpeg junit kde libg++ libwww mad
maildir mikmod mjpegi mmx mng motif mp3 mpeg mysql mythtv ncurses nls nojython
ogg oggvorbis opengl oss pam pcmcia pdflib perl png python qt quicktime readline
sdl spell sse sse2 ssl svg svga tcltk tcpd theora tiff transcode truetype
truetype-fonts type1-fonts unicode v4l vim-with-x vorbis win32codecs wmf
xinerama xml xml2 xmms xv xvid yv12 zlib"
Comment 1 Preston Crow 2005-04-28 20:04:58 UTC
Yup.  This totally breaks it for me.

For now, I've added a line to /etc/portage/package.mask

I would suggest that this should be hard-masked until this is fixed.
Comment 2 Seemant Kulleen (RETIRED) gentoo-dev 2005-04-29 07:02:08 UTC
Thomas, I think I need your help/input/feedback on these issues :)
Comment 3 Robert Forsman 2005-04-29 08:52:04 UTC
I agree with Preston.  The short term solution is to mask that package so that nobody tries to compile it, and anyone who has compiled it will be downgraded to a less buggy version.

The long term solution is to pass the bug to the "vendor" so that they can release a fix.
Comment 4 Thomas Dickey 2005-04-29 10:11:47 UTC
Is #201 the first one where the package turns on the toolbar
feature?  (I wasn't aware of this particular bug, but haven't
changed the toolbar code for a few months).  Will investigate,
Comment 5 Thomas Dickey 2005-04-29 18:00:12 UTC
I have a fix for this (replaced a couple of XtParent() with SHELL_OF()).
That will be in #202.
Comment 6 Thomas Dickey 2005-05-02 17:11:03 UTC
On the other hand, I found a case where my short fix breaks xterm.
Since the other fixes for #202 look stable, I'm going to undo that,
and work on it for #203 (I've spent about 6 hours debugging it so
Comment 7 Seemant Kulleen (RETIRED) gentoo-dev 2005-05-06 04:21:35 UTC
Thomas, sorry -- I didn't respond to your comment two comments up.  Yes, this is the first release where the toolbar gets built by default, but I patch the resource file to not pop it up:

seemant@seemant /usr/portage/x11-terms/xterm/files $ cat xterm-no-toolbar-by-default.patch 
--- xterm-201/     2005-04-26 17:01:44.000000000 -0400
+++ xterm-201/  2005-04-26 17:01:59.000000000 -0400
@@ -7,6 +7,7 @@
 ! $XFree86: xc/programs/xterm/,v 3.30 2005/04/22 00:21:53 dickey Exp $
 *saveLines: 1024
+*toolBar: False
 *SimpleMenu*BackingStore: NotUseful
 *SimpleMenu*menuLabel.font: -adobe-helvetica-bold-r-normal--*-120-*-*-*-*-iso8859-*

Possibly, I did that wrong?
Comment 8 Thomas Dickey 2005-05-06 06:41:33 UTC
That part (setting the toolbar resource initially to false)
should not be a problem.  The -geom option is not closely
related to this issue.  To implement the scrollbar, I
added a level to widget hierarchy (see the SHELL_OF macro).
That complicates things - I had simply forgotten about
-geom since I rarely use the option.  My question was to
verify that older packages wouldn't be showing the same
Comment 9 Seemant Kulleen (RETIRED) gentoo-dev 2005-05-10 05:00:32 UTC
ok people, xterm-202 in portage now. please try and report, unless thomas
previously stated on this bug that 203 would bear the fix.
Comment 10 Robert Forsman 2005-05-10 10:36:27 UTC
202 does not fix the handling of the -geom argument, which is not surprising based on Comment #6.  I will back up and wait for 203.
Comment 11 Jan Rychter 2005-05-18 09:41:37 UTC
202 does not fix the problem.

A side note: I find it very sad that gentoo breaks one of my most trusted tools.
I mean, we have to go through enough pain with all the new apps that never seem
to remember where to place their windows. I spend lots of time just moving and
shuflling windows arojnd. We had good old xterm, which could be told via
-geometry, and now -- this is supposed to be broken? Because of some fancy toolbar?

Seemant, a suggestion: I'd much rather see a trusty, working old-style xterm and
leave the fancy stuff to  Eterms, gnome-terminals and other kterminals of the
world. I would suggest that the default build for xterm do the same thing that
it used to over the last X years: build a simple, working xterm.
Comment 12 Seemant Kulleen (RETIRED) gentoo-dev 2005-05-18 11:32:49 UTC
Jan -- 202 was designed to not have any fancy things (I enable the building of
the toolbar in the ebuild, but I *disable* it from runtime with the resources
file -- and leave that up to the sysadmins/users to do it for themselves).  I
had thought of going back to the USE="toolbar" thing.  And I tested that locally
and built 202 with USE="-toolbar" to see the same sorts of errors anyway.  I owe
Thomas some debugging output, and I hope to send that along this week.
Comment 13 Thomas Dickey 2005-05-18 14:00:15 UTC
But if the program is compiled to support toolbar,
the "-geom" option won't work, as noted, because
the widgets are organized differently.  The quick
fix I was looking at changed the XtParent's in the
XMoveWindow and XSetWMNormalHints to SHELL_OF -- that
made "-geom" work.  But then there was a further bug
with "xterm -e" which no longer worked.  For the short
term, simply disable toolbar in the ebuild.  (I use
toolbar all the time - but rarely use -geom, and then
usually for size, not position).
Comment 14 Georgi Georgiev 2005-05-18 17:15:51 UTC
Mr.Dickey, you may also want to take a look at Bug #91967 which seems to be
related to this one, as Mr.Kulleen pointed out.
Comment 15 Thomas Dickey 2005-05-18 17:21:29 UTC
I don't see the reference to 91967 here, but did point out in that
bug report that it should be merged with this one.
Comment 16 Thomas Dickey 2005-07-06 17:18:26 UTC
sorry - won't be fixed in #203.  I've spent the last 4-5 days working
on this, and haven't gotten it to be 100% right.  Since there are
more urgent fixes for #203, I'm wrapping up changes w/o this one, so
I can get the others out.
Comment 17 Seemant Kulleen (RETIRED) gentoo-dev 2005-08-05 05:18:41 UTC
Please everyone, test xterm-204 that just went into this tree to see if it
solves any of your issues.  It works pretty nicely for me.
Comment 18 Thomas Dickey 2005-08-06 14:36:12 UTC
I just found a case where the resizing (part of the layout changes)
isn't working properly with #204, will have to investigate that.
It shows up (for me) running uxterm and switching fontsizes with the
shifted keypad plus/minus.
Comment 19 Thomas Dickey 2005-08-06 14:54:21 UTC
A quick check shows the problem I mentioned whtn I set the borderWidth
resource like this:
   UXTerm*borderWidth: 1
Oddly, I was debugging with a nonzero borderWidth like this:
   XTerm*VT100.borderWidth: 20
but didn't see any remaining problems.  (The bug will be in the computation
for the form widget).
Comment 20 Thomas Dickey 2005-08-07 11:33:22 UTC
The problem that I found is that the borderWidth of the menubar
widget wasn't counted in the total used for the height.  Normally
that's zero, but a wildcard for borderWidth alters that.  That's
in my changes for #205.
Comment 21 Seemant Kulleen (RETIRED) gentoo-dev 2005-08-08 05:00:46 UTC
thomas, excellent -- I'll close this bug once 205 is released
Comment 22 Thomas Dickey 2005-08-08 05:52:35 UTC
ok.  My current understanding is that #204 fixes most
of the layout problems, and that there are a handful of
things to focus on for #205.  I'll work to resolve those.
Comment 23 Thomas Dickey 2005-08-09 14:54:54 UTC
I noticed that #204's layout changes do no work well with KDE and IceWM.
I mostly use fvwm; it seems to work with gnome's default window manager
as well.  Essentially what's happening (is not a new issue, just
aggravated by the recent changes) is that xterm's requesting a resize
that doesn't precisely match the window manager hints.  fvwm allows
that, KDE doesn't.  I'm guessing that fvwm only pays attention to the
hints when the user is resizing the window with the mouse - and in that
case xterm succeeds in making the window according to the hints.  What
window managers does GenToo use?
Comment 24 Preston Crow 2005-08-11 11:37:39 UTC
xterm-204 seems to behave exactly like xterm-200-r3.  In other words, it works
fine for me.

I'll admit that I was surprised that there was any work needed to begin with for
something that has been stable for 15 or 20 years.
Comment 25 Thomas Dickey 2005-08-11 13:01:31 UTC
Not exactly.  The whole issue is a feature of xterm that I added a few
years ago which is selected at compile-time. That changes the widget 
hierarchy to allow making a toolbar (or menubar).  Most of the 
change is hidden by a macro SHELL_OF(). If you grep xterm's source 
for SHELL_OF,  you'll see a lot of places where the hierarchy is 
changed for this case.  A few XtParent macros are left as-is, and 
the -geom option needed two of those changed.  What made it 
complicated the changes to avoid cutoff of characters.  If you look 
in xterm's scrollbar.c, you'll see a long comment  explaining that 
the resize code was an elaborate workaround. It gets harder when 
adding a toolbar that can be turned on/off, as well as the form 
widget that holds it together. 
Comment 26 Seemant Kulleen (RETIRED) gentoo-dev 2005-09-16 05:00:30 UTC
*** Bug 91967 has been marked as a duplicate of this bug. ***
Comment 27 Thomas Dickey 2005-09-16 05:56:41 UTC
I think I've got my geometry fixes workable (even for KDE),
and expect to put out #205 in a couple of days (after
visiting some of the easier bugs - not related to any of
the GenToo reports).
Comment 28 Seemant Kulleen (RETIRED) gentoo-dev 2005-10-19 07:59:55 UTC
Robert and others: does xterm-205 (just added into portage 30 minutes ago after
a month's delay -- sorry! --) solve this for you, then?
Comment 29 Robert Forsman 2005-10-28 11:38:50 UTC
I have been running with xterm-205 for a few days.  I have not encountered any bugs.
Comment 30 Thomas Dickey 2005-11-13 15:45:28 UTC
As of xterm 207, there are a few isolated problems with
geometry.  The problem reported in this bug has been fixed.
By isolated - here's an example: running in KDE, if I do
"resize -s 19 42" in uxterm, there's some conflict between
the form and toolbar, making the vt100 widget shrink badly.
But with normal mouse-driven resizing, I don't recall a case
where it's broken.
Comment 31 Emanuele Giaquinta (RETIRED) gentoo-dev 2006-03-21 07:39:01 UTC
Reassigning bug to myself.
Comment 32 Emanuele Giaquinta (RETIRED) gentoo-dev 2006-05-30 15:26:59 UTC
Closing, as this is fixed.