Bug 103040

Noone of us have ever seen this with KDE but only with GNOME.

It looks really funny. If anyone would want to take a look, I have everything
ready here.

Why is this component 'YaST2' ? 
 
BTW, Michael, its more convenient to attach a screenshot. 

It shouldn't have been component YaST, sorry. It's not possible to show in a
screenshot since the XEmacs window actually moves. I'd need a screen movie
maker. ;-)

*** Bug 104080 has been marked as a duplicate of this bug. ***

It's not fullscreen, it's maximize. And for reproducing it is necessary that the space 
for maximizing is not an exact multiple of xemacs' resize increments, so you may 
want to shuffle around your panels in order to reproduce. 
 
This is xemacs bug. It tries to fight back the window manager when it gets a side it 
doesn't quite like, although the ICCCM (section 4.2.4) is quite clear on the fact that 
it should try to cope with any size it gets and not do this. In KDE this can be worked 
around in Alt+F3/Special window settings/Workarounds and enabling Strictly obeying 
geometry, and I think I can enable this by default for SL10.0. Then maximize doesn't 
actually really work, but do I need to repeat this is xemacs bug? 
 

I can confirm that the work-around works. Thanks!

Werner fixed a very similar bug for XEmacs a while ago.

Werner, is it possible that the fix in XEmacs is not complete?

Lubos: imho such workarounds for broken applications should be added to the 
default package. 

I assume this is platform independent. 

Werner, do you have any idea?

Is this related to bug #115226 ?

By the way, I cannot reproduce the behavior described in the original
comment on beta4. Michael, can you still reproduce this?

On beta4, clicking the maximise button of the window title maximizes
XEmacs but clicking it again doesn't reproduce the original size.

Yep IMHO it could be. Btw: the workaround to break the ping/pong
between the size request and the not so good responce of xemacs
was done by me for SL 9.2

-> /work/SRC/old-versions/9.2/all/xemacs/xemacs-21.4.15-gnomebug.dif

... maybe we should re-add this to enable xemacs to ignore several
resize attacks from the window manager.

I'm not sure whether your patch will still apply cleanly because
the upstream developers also tried to fix it in the meantime after
looking at your patch. But they "solved" it slightly differently.

Mike> On beta4, clicking the maximise button of the window title maximizes
Mike> XEmacs but clicking it again doesn't reproduce the original size.

This is still the case with 10.0 final.

And the update to XEmacs 21.5.22 doesn't fix it either.

(XEmacs 21.5.22 packages for SuSE 10.0 are available at

    ftp://ftp.suse.com/pub/projects/m17n/10.0

and of course already in STABLE).

I've added a vew fprintf to stderr to see what happens in the
callback of the Xt interface.  It seems that KDe does not provide
the correct data at least on x86_64.

The xemacs uses the following callback of the Xt interface:

        initialize
        realize
        resize
        set_values
        query_geometry

this is enough to work e.g. with the old KDE, fvwm2, GNOME.
Beside this for the

         actions

callback table of the Xt interface is only used to for the

         <Mapping>

entry.  Beside this the xemacs does it right, this because
the values for width/height are provided by Xt and xemacs
does only react on this values.

IMHO this looks like the KDE does not provide the correct
values for width/height in case of maximize/minimize. 

Created attachment 53976 [details]
testapp

Sigh. How many more times do I need to repeat this? The bug is that xemacs tries to fight back geometry changes from the window manager. That's what's causing the loops. Run X in failsafe mode with one xterm and launch xemacs. Use xwininfo to get the window id of the xemacs window. Run this testapp as "./testapp <windowid> <width> <height>", with width and height being e.g. 402/302, the testapp will resize the window just like if it was a window manager. Run xwininfo on the xemacs window again, this time check the window width and height. If you'll be lucky and they'll actually match the geometry you used just go one up to 403/303 and repeat until you see that the geometry doesn't match. Now read http://tronche.com/gui/x/icccm/sec-4.html#s-4.2.4 , especially the second sentence in the second paragraph and tell me what's still not clear.

> It seems that KDe does not provide
the correct data at least on x86_64.

Well, given the above and the fact that pretty much everything except xemacs works I don't think this is true or relevant, but if you want to argue this way I'm afraid you'll have to provide something more than just this mere claim.

First of all your test application is not Xt nor Motif based.
The KDE manager provides the _WRONG_ width/height if the
application uses XT or XT/Motif.

Second: the Xemacs of SL10 does _NOT_ fight back geometry changes.
This is and was fixed by me since SL9.2 for the GNOME manager.
With this patch the Xemacs try to fit as near as possible to the
request of the manager at least with in the charactes cell size.
Further request wil lbe answered with XtGeometryAlmost which is
what Xt provides in this case.

Third: There are many other applications based on Xt or Xt/Motif
which handle this in the same way.

Fourth: Im' not interessted in http://tronche.com/gui/x/icccm/sec-4.html#s-4.2.4
nor I'm willingly to rewrite the Xt engine of Xemacs.

Fifth: Give the Xt and Xt/Motif based applications a chance to 
work together with KDE or I'll do this for you.

First: It's completely irrelevant if the testapp is or is not Xt or Motif based. For 
testing purposes it's a window manager that demostrates xemacs does fight back 
geometry changes. That's rather obvious from the fact that it resizes xemacs to 
some size and the window ends up with a different size. 
 
Second: See previous two sentences. 
 
Third: Like? Not that it really matters, if there are such apps they're just as well 
broken, but I'd like to check. 
 
Fourth: And I'm not interested in you not being interested in standards. Moreover the 
"rewrite" of the Xt engine of xemacs is most probably a one-liner, just like with 
xterm. 
 
Fifth: They have it. 
 

btw: xterm shows the same behaviour 
same for gnome-terminal 
 
 

The new xterm 205 does NOT work.  This one line is useless.
The gnome-terminal does not work.
The Xemacs does not work.
Don't know how many other Xt/Motif based programs do not
work together with KDE.

Fix this in KDE.

I can confirm that xterm 205 on SuSE 10.0 shows the same behaviour.

(xterm 205 for SuSE 10.0 is available in
ftp://ftp.suse.com/pub/projects/m17n/10.0/RPMS/)

Add xterm author Thomas Dickey to CC:.

Btw: all those Xt applications which are not supported by KDE
anymore do the same thing: they doe not answer the resize
request from the KDE manager with the exact values but with
values nearby ... well known in Xt as XtGeometryAlmost.

So KDE developers are now also responsible for fixing broken old toolkits like Xt? Ok  
*shrug*.  
  
Xterm 205 does work. It's just that SL10.0 has enabled a workaround for the  
cuts-last-line bug of older xterm versions, if you set Alt+F3/Advanced/Special window  
settings/workarounds/strictly obey geometry to force and leave the checkbox  
unchecked, it'll work just fine. Gnome-terminal kind of works too, you just have to 
maximize twice, don't ask me why.  
 

Hmmm ... and how do you want to fix the statically linked Motif
applications out there?  Do you want force all customers out there
to do Alt+F3/Advanced/Special ... ??

Btw: This `maximize twice' I've seen also with xemacs on _some_
screens.  This looks like using the first mouse button twice works
like pressing the second mouse once ... but in my case with this
screen the width remains maximized whereas the height changed.

And ... on other screens nothing happens with the exact same
binary Xemacs.   And the numbers get from the KDE via the Xt
interface are definitly the new geometry _almost_ used by the
Xemacs.

Lubos> It's just that SL10.0 has enabled a workaround for the cuts-last-line
Lubos> bug of older xterm versions, if you set Alt+F3/Advanced/Special window
Lubos> settings/workarounds/strictly obey geometry to force and leave the
Lubos> checkbox unchecked, it'll work just fine.

If you do this for xemacs, xemacs will start shrinking after maximising
until only a narrow strip at the left border of the screen remains.

Regarding comments 20-22: I can only guess (xterm is wobbling around
the screen?).  Sounds like KDE is the moving target, since xterm's
working acceptably on the version of KDE I have in Debian/testing.
Current xterm patch is #207, but the changes for layout since 205
are minor - still wouldn't hurt for someone to test current code
with the KDE du jour.

I'll try to update xterm to -207 for Alpha3 to release this week.

Re #27: Yes, for about a zillionth time, this is known, xemacs is broken.
Re #28: As already said in #25, xterm 205 and up works, if the workaround is disabled as described there. Nothing more needs to be done WRT xterm.

ok - I guess.  There are two fixes in #206 for layout, but they're
much less noticeable than "wobbling".  When I committed #206, the
only problems I had with KDE were with the toolbar configuration
(which SuSE is not using).

Currently "wobbling" is a problem with KDE libs.  Im case of
a maximize request the KDE manager expects the exact pixel size
as new geometry of the client. Any offset due XtGeometryAlmost
will be answered by the KDE manager with a new request but with
wrong values. The GNOME manager force also a new request for
XtGeometryAlmost but with correct values.

This problem is caused by a patch that seems to work around xemacs' maximize problems in GNOME (namely gnomebug.patch), it can be clearly demonstrated by building unpatched xemacs, trying it, building again with only this patch and trying again. So much for KDE providing wrong values or whatever.

If the patch is considered needed for GNOME's Metacity, I suggest making that code optional only for the case when this WM is running. I'll attach a small testapp with a function that detects which WM is running (note the function is several X roundtrips and as such should be probably called only once during startup).

Created attachment 67664 [details]
test.c

Testapp finding out if Metacity is running.

I'm testing unpatched xemacs with metacity

OK, unpatched xemacs works perfect in metacity - trying to find out why leaves as an exercise to the interested reader. For this bug we're done

*making 3 crosses* 

I have a similar problem with emacs in kde. I am using openSUSE 10.3, emacs 22.1.1 (rpm emacs-22.1-40.7), kde 3.5.7 (rpm kdebase3-3.5.7-87). I start emacs and press the Maximize button: emacs becomes almost maximized, but not totally. It does not provide Restore button, it keeps the Maximize button - and when I press it once more, emacs becoms fully maximized with the Restore button. Pressing it does not restore the previous size of emacs, but it restores the almost maximized size.

The described workaround does not solve the problem.

I tried to download emacs source (v22.1) and compile it myself. Emacs compiled without gtk widgets works fine, emacs compiled with gtk widgets behaves as described above. In other window managers, emacs never has the problem (tested with blackbox and gnome).

I'm sorry. I did read all the comments but I did not understand them clearly. Reading them once more I realize the problem should have been solved (#36). Then I just do not understand why I still have the problem...

You're are talking on Xemacs or GNU Emacs?  Please do not
reopen an old and solved bug but open a *new* bug against
the Product openSUSE 10.3