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 2.0.51.19 (default-linux/x86/2005.0/2.4, gcc-3.3.5-20050130, glibc-2.3.4.20041102-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)] 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/binutils: 2.15.92.0.2-r7 sys-devel/libtool: 1.5.16 virtual/os-headers: 2.4.22-r1 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O2 -march=i686 -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" 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 /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=i686 -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/home/thoth/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" 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 =x11-terms/xterm-201 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, etc.
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 far).
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 $ *saveLines: 1024 +*toolBar: False *SimpleMenu*BackingStore: NotUseful *SimpleMenu*menuLabel.font: -adobe-helvetica-bold-r-normal--*-120-*-*-*-*-iso8859-* 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 issue.
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: 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).
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.
