Bug 115226

works fine here. I guess your bug report is incomplete. I tested with a 
konsole window 

checking again with Lars: it only exists for xterm - most likely because of 
the work around we had to add 

yes, thats the kwin problem that was introduced with 3.4. it drives me mad as 
well.  
 
 

Lubos, any chance we can have a working xemacs and xterm again? 
 
 

Sure, just fix them.  
It's rougly like this: Either we revert the patch for #61153, then maximize will work 
normally but xterm and xemacs will do all those funny things, or we don't revert the 
patch and just swap the consequences. Both cases can be selectively changed using 
window-specific settings. That's about it that can be done for SL10.0, I'm not going 
to rewrite the complete code for maximizing in kwin right now just because xterm 
and xemacs can't get things right. 
 

*sigh*.. there must be some solution so that both works.. perhaps even with 
fixing the applications.  
 
however there are some that we can not fix like e.g. opera, which has the same 
issue.  
 
  

Hmmm ... I'd like to know why xterm or xemacs works with e.g. fvwm2
but not with kwin?  With SuSE Linux 9.2 we had a problem with GNOME
and the resize command from the GNOME system where the xemacs was not
able to handle the resize command in pixel size but only in muliples
of the font metric which leads to a flood of resize commands from
GNOME and the resulting but helpless resize attemps of xemacs.

basically it comes down to: fvwm2 is not a NETWM compliant window manager, so 
it just happens to work by accident 

Ahmmm ... sorry then any NETWM compliant window manager has to
ask its clients if they can handle NETWM.  The world is not
KDE nor NETWM.

Dirk> basically it comes down to: fvwm2 is not a NETWM compliant window manager, so 
Dirk> it just happens to work by accident

fvwm2 claims to be NETWM compliant.

Add xterm author Thomas Dickey to CC: because of comment #5.
Thomas should know whether something needs to be fixed in xterm.

No, as explained in the original bugreport for this, it's like this:  
ICCCM section 4.2.4 (http://tronche.com/gui/x/icccm/sec-4.html#s-4.2.4) says that  
applications should try to cope with any size they get. Additionally in section 4.1.2.3  
there's a description of hints using which the applications may ask (i.e. hint, not  
demand) geometry they'd like, but they're not guaranteed to get it (because, if  
nothing else, the WM simply may not implement the feature).  
XEmacs's fault is that it's not compliant with section 4.2.4 and when it doesn't get  
exactly the geometry it requested it tries to force it (which leads to things like 
described in comment #7). XTerm also expects to always get the geometry it gets 
and that results in the cut last line if the geometry is not exactly the expected one 
(this can be easily fixed by e.g. cutting the topmost line instead). 
In KWin maximized state is defined as geometry == workarea. For windows that 
expect resize increments KWin therefore deliberately ignores them in order to fit the 
size exactly to the size of the workarea, and as explained above ICCCM allows this. 
With the workaround KWin strictly obeys the requested geometry, but then this 
geometry sometimes doesn't exactly match the workarea and therefore the window is 
never really maximized, leading to this bugreport. 
FVWM2 etc. work because they are not so strict in this area or they don't depend on 
section 4.2.4 at all; this has nothing to do with NETWM. 
Given the timeframe the only feasible solution seems to be picking which breakage 
should be the default and either keeping or reverting the KWin patch. 
 

as far as XEmacs is concerned, is this related to bug #103040 ?

Bug #103040 is basically the same problem. This bugreport is actually about a  
problem resulting from a workaround for that problem.  
 

how about treating a window as maximized if it is really close in size to the 
workarea? 
 
in all cases so far this was just a few pixels (3-4 usually) and in the user's 
perception a window that is 3-4 pixels smaller in height is still maximized.  
 
 

I fully agree with you ;)

But it's not maximized in kwin's perception and I'm not going to risk rewriting that   
code for SL10.0 just because few apps cannot get it right. And even post-10.0 I don't  
like the idea that much.  
 

Hmmm ... a character based window can not switch to any size.  Maybe
konsole cuts off some pixel or add some pixel, but IMHO this is not
what the user expects. Beside this IMHO add or removing pixel looks
terrible.   IMHO it is a clear bug of kwin not accepting nearby
window sizes after a request as this was for the GNOME window manager.

Ok, once more:  
  
ICCCM section 4.2.4 (http://tronche.com/gui/x/icccm/sec-4.html#s-4.2.4):  
"The response of the client to being resized should be to accept the size it has been  
given and to do its best with it. Clients must not respond to being resized by  
attempting to resize themselves to a better size. If the size is impossible to work  
with, clients are free to request to change to the Iconic state." => XEmacs behaviour  
is non-compliant.  
  
ICCCM section 4.1.2.3 (http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.2.3):  
"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 for nonnegative integers i and j:" (emphasis mine). Also please note the  
following part about aspect ratios uses sentences like "Window managers that honor  
aspect ratios should". Similarly introductory parts of section 4 and section 4.2.2 make  
it quite clear that, in simple speech:  
  
The window manager is the big boss who has the final say. Clients make polite  
requests, the window manager decides whether and how it honours the request. This  
makes it possible to develop new WMs with new UI paradigms (show this discussion  
to developers of some of the new WMs like e.g. Ion and I'm quite sure you'll hear the  
swearing). Also, the app may not rely on it also because the WM may not simply 
implement the feature. 
 
As for xterm/xemacs not being able to add or remove pixels, for xterm it clearly  
works at the bottom, so it shouldn't be a big problem to do it at the top instead.  
Xemacs has some graphical elements, so I fail to see how a couple of pixels can be a  
problem.  
 

Ahmm ... I'm _not_ talking about theory but real life.
IMHO at this two points ICCCM are devil for any character
based window program and force the developer to add
not needed code for nothing.

Isn't this the same as #61153 ?

As I noted there, the case for maximize is a less complicated problem
than the one that I've been working on with xterm's toolbar.  Looking
at _that_ yesterday, it appears to be fixed in my pending changes by
a small patch to screen.c (and will probably be in a #205 patch later
this week).

yes, its much related to #61153, they both have the same cause, just from 
different viewpoints 

> IMHO at this two points ICCCM are devil for any character based window program 
> and force the developer to add not needed code for nothing. 
No. In fact in both cases the fix seems to be about removing code. For example, the 
attached xterm patch seems to fix the problem, and as you can see xterm actually 
tries to handle this case, it just gets it wrong. I can't guarantee it's a complete fix, 
because I needed almost one hour to find the place (and a couple of minutes for the 
actual fix), but it works for me. 
For the xemacs case I'd expect the solution to be something along the lines of 
finding the place in sources where a comment says "the WM didn't give us exactly 
the geometry we want, so let's try to screw things up by forcing it again ourselves" 
and dumping that code. It seems xemacs actually can handle all geometries just 
fine, so it shouldn't be necessary anyway. 
 

Created attachment 49888 [details]
xterm patch

This patch seems to fix the incomplete last line xterm bug.

I already applied that change a few days ago, as you might have
guessed if you had read my comment #21.

Btw, I've updated to xterm-205 for openSUSE 10.1 Alpha1.

ok, I think we took care enough of this enough for now. And for xemacs is 
another bug open