Bugzilla – Bug 103040
XEmacs shrinks in a loop
Last modified: 2007-12-06 10:44:55 UTC
I start XEmacs (under KDE). Then I press "full screen". XEmacs grows to almost full-screen size, then it shrinks itself horizontally for a random value. I try it again, and same result, only it now gets a different width. And so on. Beware, you might catch nausea from watching. I've seen the same behaviour under 9.3 but always blamed it on my configuration. Now it's on my test box, too.
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