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.
Steps to Reproduce:
1. xterm -geom +100+100
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.
Portage 22.214.171.124 (default-linux/x86/2005.0/2.4, gcc-3.3.5-20050130,
glibc-126.96.36.19941102-r1, 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)]
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
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/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"
Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS
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.
Thomas, I think I need your help/input/feedback on these issues :)
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.
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,
I have a fix for this (replaced a couple of XtParent() with SHELL_OF()).
That will be in #202.
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
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/XTerm.ad.orig 2005-04-26 17:01:44.000000000 -0400
+++ xterm-201/XTerm.ad 2005-04-26 17:01:59.000000000 -0400
@@ -7,6 +7,7 @@
! $XFree86: xc/programs/xterm/XTerm.ad,v 3.30 2005/04/22 00:21:53 dickey Exp $
Possibly, I did that wrong?
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
ok people, xterm-202 in portage now. please try and report, unless thomas
previously stated on this bug that 203 would bear the fix.
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.
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.
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.
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).
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.
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.
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.
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.
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.
A quick check shows the problem I mentioned whtn I set the borderWidth
resource like this:
Oddly, I was debugging with a nonzero borderWidth like this:
but didn't see any remaining problems. (The bug will be in the computation
for the form widget).
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.
thomas, excellent -- I'll close this bug once 205 is released
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.
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?
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.
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.
*** Bug 91967 has been marked as a duplicate of this bug. ***
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).
Robert and others: does xterm-205 (just added into portage 30 minutes ago after
a month's delay -- sorry! --) solve this for you, then?
I have been running with xterm-205 for a few days. I have not encountered any bugs.
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.
Reassigning bug to myself.
Closing, as this is fixed.