Changes between Version 5 and Version 10 of Ticket #117


Ignore:
Timestamp:
01/11/14 23:21:13 (10 years ago)
Author:
ossi
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #117

    • Property Reporter changed from slavazanko to egmont
    • Property Cc ossi added; ossi@… removed
    • Property Branch state changed from to no branch
    • Property Milestone changed from 4.7 to Future Releases
    • Property Blocking changed from 2198 to

  • Ticket #117 – Description

    v5 v10  
    77||Release:||4.6.1||Operating System:||GNU/Linux|| 
    88 
    9 Discussion: 
     9Original submission: 
    1010{{{ 
    11 Tue 02 Oct 2007 09:18:19 AM UTC, comment #10: 
     11Modern desktop environments and window managers usually resize the 
     12windows in an opaque way: plenty of resize events are sent to the 
     13application while the edge of the window is being dragged. This 
     14gives users a much better feedback than the ancient method (only 
     15showing where the edges of the window will be, and resizing when 
     16the mouse button is released), though it definitely requires much 
     17more cpu resources. 
    1218 
    13 Please, do not steal existing bug reports. 
    14         Pavel Tsekov <ptsekov> 
    15 Project Administrator 
    16 Mon 01 Oct 2007 09:03:01 PM UTC, comment #9: 
     19Unfortunately mc is unable to properly handle when the terminal is 
     20resized opaquely. It receives tons of resize events (sigwinch), 
     21most likely ignores the new ones while processing an older one. 
     22Quite often when I finish resizing my window, mc draws its panels 
     23with a different size. Hence if I enlarge my terminal, I might get 
     24black columns/rows on its right/bottom part. If I shrink the 
     25window, the whole screen can be garbled. 
    1726 
    18 when a resize is sent before mc is completely up, it doesn't get 
    19 the geometry right, either - and yes, this happens about every time 
    20 an xterm -e mc is restored by session management on my system. so 
    21 the signal handler should be set up before the initial geometry is 
    22 queried. 
    23         Oswald Buddenhagen <ossi> 
    24 Mon 01 Oct 2007 03:21:44 PM UTC, comment #8: 
     27Then when I press one key, or click somewhere in the terminal with 
     28the mouse, suddenly mc's screen is repainted with the right size, 
     29and everything goes on perfectly. 
    2530 
    26 If you run without mouse support (mc -d), mc doesn't detect resizes. 
     31It would be nice to eliminate these race conditions and make mc 
     32resize correctly to the final terminal size, no matter how many 
     33resize events were sent in a very short time.  
    2734 
    28 You need to press a key for mc to resize itself to new window after 
    29 window is maximized or resized (press up/down arrow, Ctrl-O, almost 
    30 anything will work). 
     35Bonus (reported in #368): if you start mc in an xterm and resize the terminal before mc shows the panels, it will not be adjusted to the terminal's size until you resize again once the panels are there.}}} 
    3136 
    32 Tested on 4.6.2-pre1. 
    33         Denis Vlasenko <vda> 
    34 Wed 08 Nov 2006 01:38:24 PM UTC, comment #7: 
    35  
    36 Committed. Quite an improvement in behaviour. Thank you. 
    37         Leonard den Ottolander <leonardjo> 
    38 Project Member 
    39 Mon 06 Nov 2006 10:24:35 PM UTC, comment #6: 
    40  
    41 As I understand your patch/hack, eliminating the timeouts on a 
    42 window resize event significantly reduces the chance mc is still 
    43 waiting inside the get_event() loop when a new resize event occurs. 
    44         Leonard den Ottolander <leonardjo> 
    45 Project Member 
    46 Mon 06 Nov 2006 12:01:58 PM UTC, comment #5: 
    47  
    48 Please commit it if it seems to be okay for you (I've been using mc 
    49 4.6.1 with this patch for a month, and found no side effects, while 
    50 it makes mc much better when resizing the terminal). But please 
    51 don't yet close this bugreport to remind us that a proper fix is 
    52 still needed. This patch only makes it much better, but still 
    53 there's a small chance for the bug to appear. Until we have 
    54 a proper fix, it's good to apply a temporary hack to heavily 
    55 decrease the chance for the bug. 
    56         Egmont Koblinger <egmont> 
    57 Fri 03 Nov 2006 07:14:55 PM UTC, comment #4: 
    58  
    59 Shall I commit this patch or should I wait for the piped version? 
    60         Leonard den Ottolander <leonardjo> 
    61 Project Member 
    62 Tue 10 Oct 2006 04:22:16 PM UTC, comment #3: 
    63  
    64 Added a resize.patch. This does not suffer from the new bug, though 
    65 I don't understand what made a difference. 
    66  
    67 Still a rewrite to using pipes is needed to fill a minor race condition. 
    68         Egmont Koblinger <egmont> 
    69 Tue 10 Oct 2006 03:40:51 PM UTC, comment #2: 
    70  
    71 Oh, I just found the pselect() call which is supposed to solve this 
    72 problem. However, its manpage says the Linux kernel supports this 
    73 only since 2.6.16 which is a quite new piece. It says that glibc 
    74 had an emulation which is vulnerable to the race condition I just 
    75 mentioned and pselect was just introduced for. 
    76 The manpage also mentions and recommends the self-pipe trick which 
    77 is more portable. 
    78         Egmont Koblinger <egmont> 
    79 Tue 10 Oct 2006 03:27:46 PM UTC, comment #1: 
    80  
     37Comment 1 by Egmont Koblinger <egmont> at Tue 10 Oct 2006 03:27:46 PM UTC: 
     38{{{ 
    8139Normally mc stays in a select() call in key.c:get_event() which is 
    8240called by dialog.c:frontend_run_dlg(). 
    … …  
    13088select call. And of course we have to set the close-on-exec flag on 
    13189these fd's so that subprocesses don't inherit them. 
    132         Egmont Koblinger <egmont> 
    133 Fri 22 Sep 2006 01:04:44 PM UTC, original submission: 
    134  
    135 Modern desktop environments and window managers usually resize the 
    136 windows in an opaque way: plenty of resize events are sent to the 
    137 application while the edge of the window is being dragged. This 
    138 gives users a much better feedback than the ancient method (only 
    139 showing where the edges of the window will be, and resizing when 
    140 the mouse button is released), though it definitely requires much 
    141 more cpu resources. 
    142  
    143 Unfortunately mc is unable to properly handle when the terminal is 
    144 resized opaquely. It receives tons of resize events (sigwinch), 
    145 most likely ignores the new ones while processing an older one. 
    146 Quite often when I finish resizing my window, mc draws its panels 
    147 with a different size. Hence if I enlarge my terminal, I might get 
    148 black columns/rows on its right/bottom part. If I shrink the 
    149 window, the whole screen can be garbled. 
    150  
    151 Then when I press one key, or click somewhere in the terminal with 
    152 the mouse, suddenly mc's screen is repainted with the right size, 
    153 and everything goes on perfectly. 
    154  
    155 It would be nice to eliminate these race conditions and make mc 
    156 resize correctly to the final terminal size, no matter how many 
    157 resize events were sent in a very short time.  
    15890}}} 
    15991 
    160 Bonus (reported in #368): if you start mc in an xterm and resize the terminal before mc shows the panels, it will not be adjusted to the terminal's size until you resize again once the panels are there. 
     92Comment 2 by Egmont Koblinger <egmont> at Tue 10 Oct 2006 03:40:51 PM UTC: 
     93{{{ 
     94Oh, I just found the pselect() call which is supposed to solve this 
     95problem. However, its manpage says the Linux kernel supports this 
     96only since 2.6.16 which is a quite new piece. It says that glibc 
     97had an emulation which is vulnerable to the race condition I just 
     98mentioned and pselect was just introduced for. 
     99The manpage also mentions and recommends the self-pipe trick which 
     100is more portable. 
     101}}} 
     102 
     103Comment 3 by Egmont Koblinger <egmont> at Tue 10 Oct 2006 04:22:16 PM UTC: 
     104{{{ 
     105Added a resize.patch. This does not suffer from the new bug, though 
     106I don't understand what made a difference. 
     107 
     108Still a rewrite to using pipes is needed to fill a minor race condition. 
     109}}} 
     110 
     111Comment 4 by Leonard den Ottolander <leonardjo> at Fri 03 Nov 2006 07:14:55 PM UTC: 
     112{{{ 
     113Shall I commit this patch or should I wait for the piped version? 
     114}}} 
     115 
     116Comment 5 by Egmont Koblinger <egmont> at Mon 06 Nov 2006 12:01:58 PM UTC: 
     117{{{ 
     118Please commit it if it seems to be okay for you (I've been using mc 
     1194.6.1 with this patch for a month, and found no side effects, while 
     120it makes mc much better when resizing the terminal). But please 
     121don't yet close this bugreport to remind us that a proper fix is 
     122still needed. This patch only makes it much better, but still 
     123there's a small chance for the bug to appear. Until we have 
     124a proper fix, it's good to apply a temporary hack to heavily 
     125decrease the chance for the bug. 
     126}}} 
     127 
     128Comment 6 by Leonard den Ottolander <leonardjo> at Mon 06 Nov 2006 10:24:35 PM UTC: 
     129{{{ 
     130As I understand your patch/hack, eliminating the timeouts on a 
     131window resize event significantly reduces the chance mc is still 
     132waiting inside the get_event() loop when a new resize event occurs. 
     133}}} 
     134 
     135Comment 7 by Leonard den Ottolander <leonardjo> at Wed 08 Nov 2006 01:38:24 PM UTC: 
     136{{{ 
     137Committed. Quite an improvement in behaviour. Thank you. 
     138}}} 
     139 
     140Comment 8 by Denis Vlasenko <vda> at Mon 01 Oct 2007 03:21:44 PM UTC: 
     141{{{ 
     142If you run without mouse support (mc -d), mc doesn't detect resizes. 
     143 
     144You need to press a key for mc to resize itself to new window after 
     145window is maximized or resized (press up/down arrow, Ctrl-O, almost 
     146anything will work). 
     147 
     148Tested on 4.6.2-pre1. 
     149}}} 
     150 
     151Comment 9 by Oswald Buddenhagen <ossi> at Mon 01 Oct 2007 09:03:01 PM UTC: 
     152{{{ 
     153when a resize is sent before mc is completely up, it doesn't get 
     154the geometry right, either - and yes, this happens about every time 
     155an xterm -e mc is restored by session management on my system. so 
     156the signal handler should be set up before the initial geometry is 
     157queried. 
     158}}} 
     159 
     160Comment 10 by Pavel Tsekov <ptsekov> at Tue 02 Oct 2007 09:18:19 AM UTC: 
     161{{{ 
     162Please, do not steal existing bug reports. 
     163}}}