[Octave-bug-tracker] [bug #63741] gui command window text boundaries do not match window dimensions after resize, font dependent

[Nicholas Jankowski]

Update of bug #63741 (project octave):

                Severity:              3 - Normal => 2 - Minor              
                  Status:                    None => Confirmed              
                 Release:                  8.0.90 => stable                 
                 Summary: gui command window does not use available space =>
gui command window text boundaries do not match window dimensions after
resize, font dependent

    _______________________________________________________

Follow-up Comment #2:

I'm noticing behavior like this as well on the current stable build  [ 8.3.1
(hg id: 6a1f89bb969c)].  This is the first time i noticed changing the command
window font fixes things. switching back to the other font brings the problem
back up. Attempts to recreate the issue highlighted below:

On Windows 10. (same behavior seen on single and multi-monitor setups)


initialize:
1 - Start with Command default font set to Courier New, size 9
2 - select Reset Default Window Layout (moves window to monitor 1, upper left
corner, and sets height/width to some fraction of screen size
3 - close/restart Octave.

baseline:
4 - type a command that overflows the current window height and width, such as
`help plot` (several pages long and the first line "'plot' is a function from
the file C:\..." should wrap horizontally).  
5 - Verify vertical scroll is active and scroll uses full window height, and
note where the long line wrapped at the full window width.
6 - maximize the window
7 - verify that vertical scroll is active, it uses the full command window
height, and the long line wrapping has updated to fill the new width. (the
command window only uses ~half the width by default, so it may only be a few
characters wider as the left windows will also expand)
8 - Reset Default Window Layout, exit and restart octave.
9 - 'help plot' again.
10 - Using mouse, manually increase height and width of the application window
enough to see similar effects (not quite maximized)
11 - verify scroll and wrapping again.  

Trigger bug:
12 - Edit/Preferences change Command default font to Lucida Console (should be
a windows available true type, fixed width font)
13 - Reset Default Window Layout, exit and restart octave.
14 - 'help plot' again.
15 - verify vertical scroll, horizontal wrapping appear ok.
16 - maximize application.  
17 - verify vertical scroll should still be activated, and there should be
whitespace below current prompt created by the vertical expansion.
18 - attempt vertical scroll. Octave appears to think lower command limit
boundary is still below the prompt location after resize.  scrolling up
'wipes' the display and that new whitespace
remains as whitespace.  
19 - note the horizontal long line wrapping changed. a horizontal scroll was
activated. A wrapping point farther to the right that seems to align with the
new window width was selected, however characters to the right of the old
wrapping location are not displayed.  The new horizontal whitespace also
remains as whitespace as you scroll horizontally.  
20 - typing `help plot` again shows that the vertical and horizontal
whitespace behavior are unchanged. 
21 - Reset Default Window Layout, exit and restart Octave
22 - 'help plot' again. 
23 - Using mouse, manually increase height and width of the application window
enough to see similar effects (not quite maximized)
24 - verify the #18 and #19 behaviors are the same.

'correct problem'
25 - Edit preference, change font back to Courier New.  
26 - Note that all scrolling and whitespace behavior has returned to normal
expected behavior. 


The problem seems to appear only after you first trigger scrolling. It is most
noticeable if you:

27 - Set font to Lucida Console, Reset Default Window Layout, exit & restart
octave.
28 - manually reduce the height of the application window to minimum (i
believe the minimum is set by the other widget windows on the left, and still
should be tall enough to not trigger any new vertical scrolling.
29 - help plot
30 - manually increase the application window height again. 
31 - check vertical scrolling and note whitespace behavior.



I only first noticed this when I switched to a font that better differentiated
between 0 and O, 1 and l, etc, and until stumbling on this report didn't
realize the font selection seems to be tied to the issue. I haven't gone
through and tried to check which fonts trigger this, and ideally the answer
would be 'none'.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?63741>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/