bugGNU Octave - Bugs: bug #63741, gui command window text boundaries...

 
 

bug #63741: gui command window text boundaries do not match window dimensions after resize, font dependent

Submitter:  Dmitri A. Sergatskov <dasergatskov>
Submitted:  Thu 02 Feb 2023 03:24:54 PM UTC
   
 
Category:  GUI Severity:  2 - Minor
Priority:  5 - Normal Item Group:  None
Status:  Confirmed Assigned to:  None
Originator Name:  Open/Closed:  * Open
Release:  * stable Operating System:  * Microsoft Windows
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 09 Feb 2024 03:26:02 AM UTC, comment #7: 

It appears to be present with all fonts, sometimes it is more obvious (try to reduce the font size to make it more obvious).
It is also more obvious on high-res displays.

Dmitri.
--


Dmitri A. Sergatskov <dasergatskov>
Fri 09 Feb 2024 03:18:54 AM UTC, comment #6: 

I'm still seeing the same behavior in the Octave 9 RC1.  I had forgotten that it was font dependent and switching to Courier New seems to fix it.  But after installing the RC1 the default was set to Lucida Console.  Reproducing the issue when font set to Lucida console:

Open octave gui

maximize the window

>> help integral   #or some other function with a long docstring


scroll the mouse up and down. 

the text will only paint as far down as the size of the window before maximizing it, everything below that is white with no text as if it was the bottom of the window. Scrolling it down further you'll sometimes see the cursor in the whitespace.   if you type it will jump the cursor / input line up to wherever it 'thinks' the bottom of the window is. 

changing font to something like Courier New fixes the problem, even on a reload and trying to repeat the above steps. switch back to Lucida Console and the problem can be recreated again.

Nicholas Jankowski <nrjank>
Group Member
Fri 27 Oct 2023 01:38:17 PM UTC, comment #5: 

Testing on Windows so don't regularly test default there.  My tests on ubuntu with default (hg id: fd5ae4140483) could not recreate this issue.  querying __octave_config_info__, that still had QT5 active, but i don't know if that just means there wasn't a triggering font over there.  Is there a qt6 enabled windows build i can test, since i know how to trigger it there.

Nicholas Jankowski <nrjank>
Group Member
Fri 27 Oct 2023 05:34:32 AM UTC, comment #4: 

Is this an issue with a current head of the default branch and Qt6¿

Markus Mützel <mmuetzel>
Group administrator
Thu 26 Oct 2023 05:29:08 PM UTC, comment #3: 

the horizontal scrolling/wrapping issue may be related to bug #63504

Nicholas Jankowski <nrjank>
Group Member
Thu 26 Oct 2023 05:05:45 PM UTC, 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'.

Nicholas Jankowski <nrjank>
Group Member
Wed 15 Feb 2023 03:28:03 AM UTC, comment #1: 

Changing default font for the command windows from Courier to Consolas (10pt size) fixed this problem for me.

Dmitri.
--


Dmitri A. Sergatskov <dasergatskov>
Thu 02 Feb 2023 03:24:54 PM UTC, original submission:  

Command window in octave gui does not use all availabel space.
See attached screenshots on display 3840x2160 with scaling set at
comwin100.png (100%), comwin150.png (150%), and comwin200.png (200%). The white spce below the prompt is not being used
(if scroll, it would scroll text in those top lines already occupied).
A similar problem occur in horizontal space (e.g.
running a=(1:100) would wrap the line at about 20 in a window
that can accommodate ~50.

The problem becomes less noticeable at lower resolution, but it still there. At 1920x1200 I had to make the command window full heights tall to get a few lines of empty space at the bottom.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #54301:  comwin100.png added by dasergatskov (274KiB - image/png)
file #54302:  comwin200.png added by dasergatskov (346KiB - image/png)
file #54303:  comwin150.png added by dasergatskov (259KiB - image/png)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by nrjank (Posted a comment)
  • -email is unavailable- added by nrjank
  • -email is unavailable- added by dasergatskov (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-10-26 nrjank Severity3 - Normal 2 - Minor
        StatusNone Confirmed
        Release8.0.90 stable
        Summarygui command window does not use available space gui command window text boundaries do not match window dimensions after resize, font dependent
        Carbon-Copy- Added ttl
    2023-02-02 dasergatskov Attached File- Added comwin100.png, #54301
        Attached File- Added comwin200.png, #54302
        Attached File- Added comwin150.png, #54303

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code