Bug 61153 (suse46153)

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. ***

*** 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.