Bug#461773: fluxbox: xterm -e mc results in maximized xterm window but not maximized mc
* ?? [EMAIL PROTECTED] [080122 19:42]: 2008/1/22, Bernhard R. Link [EMAIL PROTECTED]: I just stumbled over this bug report and you might want to test if it is bug http://bugs.debian.org/347308 of xterm. Did your patch make it into upstream xterm version? I'm using xterm 231 and experiencing the bug. As far as I understand it, the patch disables some workaround for non-pty ttys (or perhaps even only Solaris non-pty ttys) that causes this race condition. Thus upstream wanted to further investigate this and I got no more feedback. If you believe the bug is in xterm and know how to fix it, I'll reassign the bug (once again ;-) 226's Changelog allegely says this might be closed, and I yet could not reproduce it myself with 231 (though race conditions are always a bit strange. Without some sleep call added to the sources, I could only reproduce the old bug myself by making sure the xterm binary is not in the kernel caches and my window manager ratpoison is). Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#461773: fluxbox: xterm -e mc results in maximized xterm window but not maximized mc
On Wed, Jan 23, 2008 at 10:50:13AM +0100, Bernhard R. Link wrote: * ?? [EMAIL PROTECTED] [080122 19:42]: 2008/1/22, Bernhard R. Link [EMAIL PROTECTED]: I just stumbled over this bug report and you might want to test if it is bug http://bugs.debian.org/347308 of xterm. Did your patch make it into upstream xterm version? I'm using xterm 231 and experiencing the bug. As far as I understand it, the patch disables some workaround for non-pty ttys (or perhaps even only Solaris non-pty ttys) that causes this race condition. Thus upstream wanted to further investigate this and I got no more feedback. If you believe the bug is in xterm and know how to fix it, I'll reassign the bug (once again ;-) 226's Changelog allegely says this might be closed, and I yet could not It says: Patch #226 - 2007/6/17 * modify logic which resets/updates the screensize on the child process side of the pseudo-terminal to do this only if a successful handshake was received, e.g., as determined by the waitForMap resource (prompted by reports by Emanuele Giaquinta and Bernhard R Link, but see also [249]patch #177 and [250]patch #159. As I recall that, the later resets/updates detail was causing the window manager's changes to be overwritten. reproduce it myself with 231 (though race conditions are always a bit strange. Without some sleep call added to the sources, I could only reproduce the old bug myself by making sure the xterm binary is not in the kernel caches and my window manager ratpoison is). It could of course be another old (or new) bug as yet undiagnosed... -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgpzXJiWQEUOl.pgp Description: PGP signature
Bug#461773: fluxbox: xterm -e mc results in maximized xterm window but not maximized mc
* Debian Bug Tracking System [EMAIL PROTECTED] [080122 13:36]: reassign 461773 mc Bug#461773: fluxbox: xterm -e mc results in maximized xterm window but not maximized mc Bug reassigned from package `fluxbox' to `mc'. I just stumbled over this bug report and you might want to test if it is bug http://bugs.debian.org/347308 of xterm. The problem is that Xterm resets the terminals geometry after some initialisations (in my understanding to work around shortcomings in non-Linux ttys), overwriting a possibly already changed terminal size due to an window resize. Hochachtungsvoll, Bernhard R. Link http://bugs.debian.org/347774 looks like another duplicate of this. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#461773: fluxbox: xterm -e mc results in maximized xterm window but not maximized mc
Hi Dmitry! Thanks for your fast reply. I don't really think it's a bug of xterm, because adding xterm*geometry: 98x34+0+0 to my .Xresources (instead of apps file customization) results in correct behavior. IMHO it means that Fluxbox is one responsible for the bug. Andrey -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#461773: fluxbox: xterm -e mc results in maximized xterm window but not maximized mc
АП Thanks for your fast reply. I don't really think it's a bug of xterm, АП because adding АП xterm*geometry: 98x34+0+0 АП to my .Xresources (instead of apps file customization) results in АП correct behavior. IMHO it means that Fluxbox is one responsible for АП the bug. When You start with geometry option (or resources) it creates a window with dimensions declared in this option. And in the case of starting under fluxbox a window changes dimensions when mc starts. This is the bug of xterm or mc :) Most probably it is mc bug. signature.asc Description: Digital signature
Bug#461773: Fwd: Bug#461773: fluxbox: xterm -e mc results in maximized xterm window but not maximized mc
I still insist it's Fluxbox bug ;-), and that's why. Window size may be specified on X Window System level. In my case, I specify it in my .Xresources and merge it into X server settings database via xrdb. These settings are applied in such a way that when mc is being run the parent xterm window already has desired dimensions. mc acquires proper size from parent xterm window and everything is nice. On the other hand, Fluxbox claims to provide similar feature. Actually, I like Fluxbox's feature more, because it allows to specify window size in pixels, not in characters. The problem is the feature doesn't work very well in case of xterm -e mc. I perfectly understand that underlying algorithms of setting window size are very different for X Server and Fluxbox window manager. However from the user point of view I see that .Xresources method works, and Fluxbox's does not. So, it's a bug of Fluxbox ;-) Andrey P.S: Don't get me wrong: I like Fluxbox much, and I understand this bug it a really minor one. I'm reporting so at least google indexes the page and other people might find a solution to already known problem. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#461773: fluxbox: xterm -e mc results in maximized xterm window but not maximized mc
I have tried to reproduse this bug with other programs (centerim, mutt, rtorrent...) and only few programs can reproduse this bug. As far as I understand all these programs (that work correctly, ex: centerim) constantly watch the changing of terminal dimensions. DEO And in the case of starting under fluxbox a window changes DEO dimensions when mc starts. I forwarded You bugreport to upstream, wait ;) АП Window size may be specified on X Window System level. In my case, I АП specify it in my .Xresources and merge it into X server settings АП database via xrdb. These settings are applied in such a way that when АП mc is being run the parent xterm window already has desired АП dimensions. mc acquires proper size from parent xterm window and АП everything is nice. in one case, the program itself sets the size of the window (option geometry), _before_ the child starts. in the other case window changes dimensions when mc starts (simultaneously). АП On the other hand, Fluxbox claims to provide similar feature. АП Actually, I like Fluxbox's feature more, because it allows to specify АП window size in pixels, not in characters. The problem is the feature АП doesn't work very well in case of xterm -e mc. АП I perfectly understand that underlying algorithms of setting window АП size are very different for X Server and Fluxbox window manager. АП However from the user point of view I see that .Xresources method АП works, and Fluxbox's does not. So, it's a bug of Fluxbox ;-) АП Andrey АП P.S: Don't get me wrong: I like Fluxbox much, and I understand this АП bug it a really minor one. I'm reporting so at least google indexes АП the page and other people might find a solution to already known АП problem. signature.asc Description: Digital signature
Bug#461773: [Fluxbox-devel] Bug#461773: fluxbox: xterm -e mc results in maximized xterm window but not maximized mc
On Jan 20, 2008 11:51 AM, Dmitry E. Oboukhov [EMAIL PROTECTED] wrote: It's more like a bug in xterm. Because the construction xterm -e 'sleep 0.1; mc' always works correctly. Looks like the bug declares itself because there's made simultaneously the resize of the terminal window and the start of the child application in it. However this bug is also reproduced with other terminals (rxvt). I think that fluxbox is an only manager with such an opportunity (.fluxbox/apps), that's why we can see terminal bugs in it. :) Yup. Nothing to do with fluxbox. The contents of windows are beyond our control, and there's no special notification required when we resize a window. Mark -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#461773: fluxbox: xterm -e mc results in maximized xterm window but not maximized mc
Package: fluxbox
Version: 1.0.0+deb1-4
Severity: normal
To reproduce:
1) Add the following (or similar) lines to your ~/.fluxbox/apps (the
dimensions must be larger then then default dimensions of xterm
window):
[app] (name=xterm)
[Dimensions] {1024 764}
[Position] (UPPERLEFT) {0 0}
[end]
Select Reconfigure from Fluxbox menu and try running xterm. Make
sure xterm window has dimensions you specified.
2) Run command xterm -e mc. Note that new xterm window is resized to
match specified settings, but mc is not. *
* If mc is resized to fill the window (correct behavior) then try
again (on my box the bug is reproduced at least 1 out of 5 times).
Note that resizing existing xterm window with mc in it seems to
*always* behave correctly. Also, xterm window is *always* correctly
resized on startup.
Random nature of the bug possibly means there is some kind of race
condition somewhere.
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.22-3-486
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages fluxbox depends on:
ii libc6 2.7-5GNU C Library: Shared libraries
ii libfontconfig1 2.5.0-2 generic font configuration library
ii libgcc1 1:4.2.2-4GCC support library
ii libice6 2:1.0.4-1X11 Inter-Client Exchange library
ii libimlib2 1.4.0-1 powerful image loading and renderi
ii libsm6 2:1.0.3-1+b1 X11 Session Management library
ii libstdc++6 4.2.2-4 The GNU Standard C++ Library v3
ii libx11-62:1.0.3-7X11 client-side library
ii libxext61:1.0.3-2X11 miscellaneous extension librar
ii libxft2 2.1.12-2 FreeType-based font drawing librar
ii libxinerama11:1.0.2-1X11 Xinerama extension library
ii libxpm4 1:3.5.7-1X11 pixmap library
ii libxrandr2 2:1.2.2-1X11 RandR extension library
ii libxrender1 1:0.9.4-1X Rendering Extension client libra
ii menu2.1.36 generates programs menu for all me
fluxbox recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#461773: fluxbox: xterm -e mc results in maximized xterm window but not maximized mc
It's more like a bug in xterm. Because the construction xterm -e 'sleep 0.1; mc' always works correctly. Looks like the bug declares itself because there's made simultaneously the resize of the terminal window and the start of the child application in it. However this bug is also reproduced with other terminals (rxvt). I think that fluxbox is an only manager with such an opportunity (.fluxbox/apps), that's why we can see terminal bugs in it. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
