Bugzilla – Bug 61153
xterm: last line is incomplete
Last modified: 2006-01-11 16:59:25 UTC
Install 9.1, update to 9.2b3, all german/UTF8. If you resize a xterm window to fullscreen, the last xterm line is only shown half, the lower pixels are missing.
I cannot reproduce this with a default user created with "useradd -m" on a current STABLE system. Can you give me access to this machine?
No, too many firewalls. I will try to reproduce it on a machine at the office tomorrow.
Ok. I tried via NX. # knx --> Sessiontype: UNIX/KDE, host: shannon, user:linux, password: linux (needs packages NX,FreeNX,knx) Maybe I was to stupid to reproduce ...
Please try also with freshly created user on 9.2-Beta3.
Still waiting for feedback about comment #4. If I would find the time I could test it myself. :-(
Hmm ... I could not reproduce with the default user on a freshly installed 9.2.
I can reproduce it with a default installation and a new user. 1280x1024 resolution, normal kde taskbar (no big one), xterm in fullscreen mode.
Hmm ... IIRC I testet with the big one (default).
Than you only need to find another resolution where you can see this. But I cannot test this with my TFTs.
I can reproduce this with a normal kde taskbar. Indeed, it depends on the size of the taskbar. Try some settings with customized size. Maybe the KDE guys have some ideas other than "X bug, your problem" ...
Not sure I understand the problem. Does the taskbar overlap the xterm? Or does the taskbar cause a certain size of the fullscreen xterm that causes the xterm to misdraw its bottom line?
We don't know what the problem is. If you use a 1280x1024 resolution (our standard TFTs are using this) and have a KDE taskbar of "normal" size and resizes xterm to be full screen, the last xterm line is incomplete (unreadable).
KWin no longer honours the size increments if a window is maximized/fullscreened (http://bugs.kde.org/show_bug.cgi?id=86320, http://bugs.kde.org/show_bug.cgi?id=53784). Technically, the hints that apps use for requesting size are just that, requests, and they're not required to be honoured (since, if nothing else, the WM simply may not have the support implemented at all), and therefore xterm should cope with it somehow (it e.g. could show the half line at the top instead of the bottom). I could provide a patch for 9.2 that'd reverse the change from KDE#86320 if it's important (does somebody really use xterm with KDE?) and xterm cannot be fixed for 9.2, but I currently don't see a reason for reverting the change in KDE CVS.
Nealy every non-KDE developer at SuSE is using xterms with KDE.
Created attachment 24306 [details] kdebase patch Reverted patch from KDE #86320, if needed.
Looks like this is a bug, which should be fixed in KDE.
Which part of comment #13 and "The base_width and base_height elements in conjunction with width_inc and height_inc define an arithmetic progression of __preferred__ window widths and heights ..." (http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.2.3, emphasis mine) makes you think so?
Adrian: Since I don't expect this will be fixed in xterm for 9.2, please apply the attached patch, and reassign back.
@#14: I just counted through the half office flour: choeger and you are the only ones I could find that are using KDE and xterm exclusively. Another minority mixes konsole and xterm, the rest is using konsole. Quote HuHa "why should one use xterm when there is konsole". So far about your theories
okay
Ok. Assuming that Adrian applied the patch I set this now to LATER.
reopen for closing
AFAIK this is fixed meanwhile. Please reopen, if it still happens with 9.3-Beta3.
the bug is not fixed. it's pretty easy: open an xterm, maximize it and fill the screen
Hmm ... needs more investigation, which is something for ... LATER.
*** Bug 102515 has been marked as a duplicate of this bug. ***
Maybe Thomas Dickey can help here?
This is not due to a new change in xterm. Coincidentally, I know some useful information here, from recent work on the toolbar configuration. As far as I know, GenToo is the only group trying to use _that_, but the resizing code has a normally minor issue which is aggravated by configuring xterm to use the toolbar code. In #204, I got that (toolbar layout) working reasonably well with fvwm, only to find that (the toolbar layout) changes work worse with KDE (on Debian/testing) than before. My understanding of the difference is that KDE is more proactive about managing the resizing process than fvwm. xterm has "always" done resizing by (1) adjusting the widget resources, (2) using XtMakeResizeRequest() to negotiate the geometry layout and (3) updating the window manager hints to match the widget resource settings. What I observed is that step 2 is failing in the more complicated toolbar layout because the server is ignoring step (1), causing it to accept step sizes that differ from what xterm requests. This is when switching font sizes. In the normal (no toolbar) configuration, the error is usually small (and not noticeable). But it's still present, since the server prefers to use different step sizes than xterm's preferences. That seems consistent with the comment by Lubos Lunak (and also with misbehaviour by other applications than xterm - Opera for instance can be frustrating to use in KDE). I saw similar problems with IceWM, btw, but most window managers work properly.
Its actually a incompliance with netwm between xterm and kwin. you can adda window specific setting (RMB the window broder, select configure window behaviour, window-specific-settings, tab workarounds) to strictly obey geometry to "force enabled" for xterm. perhaps we should do that by default, its really reported quite often. I don't know what the problem with opera is but one of the workarounds should work too.
That setting doesn't appear in the version of KDE that I'm running. It must be a recent change. Reading the various responses, I see that KDE has broken more than one aspect of Xt/X11 layout. For this particular one, there might be a separate fix unrelated to the toolbar. Regarding comment #19 - having run vttest recently, I see no reason to recommend konsole. My regards to its developers. bye.
Good point. I've added vttest to our xterm package now. Should already be in Beta4.
its not really a recent change, it has been in KDE starting with KDE 3.3.0 or so. and yes, we're currently discussing to ship default workarounds for more broken but frequently used applications. I agree that konsole is much slower in repainting than xterm. However it provides features not available in xterm. So its a tradeoff, as usual.
It's RMB->Advanced->Special window settings ... etc. It's been there since KDE3.4. And if KDE has broken anything that it's that anything's fault, see comment #13 and comment #17 for details. KWin's behaviour is perfectly ICCCM-compliant in this regard. WRT comment #29 it basically doesn't make much sense to me, sorry - I see no toolbar in xterm nor understand what it should have to do with this bug, I don't know what "#204" is and I pressume "server" actually means "window manager". As for the practical side of things, this is a bug in xterm and it has to be fixed there, period. KWin has the relevant window-specific setting to work around such broken applications, but due to technical reasons it cannot be activated by default for SL10.0, so the patch from comment #15 will be used for SL10.0. KDE SVN will stay the way it is, with perhaps the window-specific setting added by default once I fix the technical problem with it.
I've just updated xterm to #205. ------------------------------------------------------------------- Mon Sep 19 10:58:24 CEST 2005 - sndirsch@suse.de - updated to xterm-205 [...] * modify computation of rows/columns on resize to avoid extending beyond the given limits, e.g., if resizing in response to a "maximize" in Gnome or KDE which do not use the window manager hints for this case (Debian #289123, Novell #61153).
fixed for SUSE Linux 10.1.
Does that mean xemacs has been fixed too?
Sorry, but this bugreport about xterm and not (x)emacs.
*** Bug 131531 has been marked as a duplicate of this bug. ***
*** Bug 131650 has been marked as a duplicate of this bug. ***
This problem occurs at rxvt, also. And I don't think is a vanilla KDE bug. I'm using KDE 3.4.2 at work, on a Slackware Linux and it maximizes normaly, not as SuSE behavoir.