bugGNU Octave - Bugs: bug #41842, linux GUI Command Window should...

 
 

bug #41842: linux GUI Command Window should show horizontal scroll bar if necessary

Submitter:  Felipe G. Nievinski <fgnievinski>
Submitted:  Wed 12 Mar 2014 04:49:52 AM UTC
   
 
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Feature Request
Status:  Confirmed Assigned to:  None
Originator Name:  Open/Closed:  * Open
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Mon 12 Dec 2022 07:42:14 PM UTC, comment #20: 

created bug #63504 about typing offscreen on windows.

Nicholas Jankowski <nrjank>
Group Member
Sun 11 Dec 2022 03:52:13 AM UTC, comment #19: 

and now i just tried in linux/ubuntu, octave 8.0.1 and 9.0.1, and in neither case do i get a horizontal scrollbar. 

type a long line, it wraps.  shorten the window, and the window is shorter without a h-scrollbar.  the new line wraps to the new, shorter window width, but no scroll bar appeared to see the now-hidden previous line. up-arrow to the previous now-too-long command, and it wraps to the new length. but still no way to see the previous full line without stretching the window.

so instead of closing, seems this can be kept open, retitling that the h-scrollbar would be nice to have on linux

Nicholas Jankowski <nrjank>
Group Member
Sun 11 Dec 2022 03:47:06 AM UTC, comment #18: 

I'm able to recreate some of these older gui issues on Windows 10 with Octave 8.0.1, but not all. Can anyone indicate whether any of this behavior should be different?

if i close octave with a narrow window, on restarting the welcome message is line wrapped. no h-scrollbar.  if I widen the window, it unwraps the welcome message.

if i start typing a paragraph, when it gets to the end of the stretched window, it wraps to the next line.

if i then make the window narrower than the long line shown, a horizontal scroll bar appears.

AT THAT POINT, if i start typing another paragraph, the text continues off screen, typing out of sight, until i reach the length of that first long line. then it wraps the text.

before hitting enter if i then stretch the window wider than the wrapping length, it will unwrap the current line i'm typing until i reach the end of that new width. then it wraps. this continues until hitting enter.

the horizontal scrollbar appears again if you make it narrower than the new longest line.

unlike what i remember with older versions, anytime i select blocks of text with lines heading offscreen, the whole line (even unseen part) is copied. this happens with every combination of window widths above.

'clc' when there is a horizontal scrollbar keeps the same horizontal scrollbar. even if you rezise the cleared window to larger than the width that set the scrollbar.

entering something like

>> 1:50

will always wrap columns at whatever the current window width is, whether or not there's a horizontal scrollbar from something being off screen.

after a clc, new paragraph will wrap at the old width (blindly typing off screen) unless you shrink the window, at which point it will now start wrapping at the new length. (if you stretch the window, then shrink it, even though it's still wider than before, it will still start wrapping. seems something about new_width<old_width triggers the change)

I think Rik's comment #5 concerns have been fixed. the comment #0 scrollbar concerns seem to be fixed. Up-arrowing to old commands will keep whatever line wrapping they were executed, but there will be a horizontal scroll bar. clc doesn't seem to create a case where you can up-arrow to old commands that inaccessibly off the window. The lines and cursors all seem to stay where they should, rather than 'moving up' as some noted.

The only item i can see an issue here, is that there are conditions where you're blindly typing off screen.  I think that can be a new report.

Nicholas Jankowski <nrjank>
Group Member
Tue 28 Jul 2015 12:28:09 PM UTC, comment #17: 

I fixed the look of the horizontal scrollbar and added horizontal scrolling with a mouse wheel/trackpoint.
I also changed the patch so that terminal output is formatted according to the current window size. I'm not happy with the terminal resize, and anyway it should be moved to the TerminalModel object, but I wanted to hear some thoughts about my code before I continue.

(file #34547)

Stefan Miereis <stefanm>
Wed 24 Jun 2015 09:32:34 PM UTC, comment #16: 

Yes, I think the implicit 10,000 column display is a problem.  Anything that has horizontal dimension is never going to be wrapped.  As an example,


format long
y = rand (1, 10)


I don't know how to think about solving that.  Maybe you need to poll people on the octave-maintainer's list since this would change the interface quite a bit.

Another thing I noticed about the patch is that the bottom horizontal scrollbar has a different appearance from the vertical scrollbar.  See the attached screenshot.  The new scrollbar appears clunky, like old 1980's X11 displays.  For example, see that the black color from the command window is showing through under the left/right scroll arrows.


Rik <rik5>
Group administrator
Tue 23 Jun 2015 07:50:02 PM UTC, comment #15: 

Hmm, Matlab calls the system ls command, but the output is wrapped. I suspect for system commands like this, the wrapper takes the output and linewraps it to the window size. This is certainly a side effect that hadn't occurred to me for octave.

I wonder what effect it has on 'disp' and so on.

Richard <crobar>
Tue 23 Jun 2015 04:30:26 PM UTC, comment #14: 

I tested my patch a bit further and it seems to work fine, but one thing bothers me: If I type 'ls', all files and folders are written in one output line (obviously, because of the semi-infinite line width), so if I have a lot of files I don't get an overview over them but instead have to scroll to search for a file or folder, which seems like a step backwards from the status quo.
Any thoughts on this?

Stefan Miereis <stefanm>
Sun 10 May 2015 10:08:58 PM UTC, comment #13: 

Sorry for the delay, the qterminal code proved to be more complex than I thought.
I attached a patch that implements a horizontal scrollbar with a line width of 10,000 columns.

(file #33972)

Stefan Miereis <stefanm>
Wed 01 Apr 2015 10:08:49 AM UTC, comment #12: 

@Rik: That seems doable, I can probably put a patch together over easter.

Stefan Miereis <stefanm>
Tue 31 Mar 2015 09:12:21 PM UTC, comment #11: 

@Stefan: I tested the patch in comment #10 and it works for me (horizontal scrollbar on Unix system).  Can you take a look at how difficult it would be to have infinite-length lines without wrapping as suggested by Richard in comment #8?

Rik <rik5>
Group administrator
Wed 25 Mar 2015 09:57:57 AM UTC, comment #10: 

I created a patch that implements a horizontal scrollbar for unix systems. At the moment long lines are still wrapped, but I could rewrite it so that the lines continue indefinitely, should that be deemed the better approach.

About Rik's #3: I noticed something similar (using linux). If I'm writing a long line and resize the window smaller and then bigger again, so that the line is wrapped and then unwrapped, the whole line moves up the screen and erases the text above it.
I can work on that, but I would need to know whether we want to use wrapped lines in the future.

(file #33447)

Stefan Miereis <stefanm>
Fri 06 Feb 2015 04:19:34 PM UTC, comment #9: 

@jwe: My testing was on Linux.  The first problem, I agree, is just because the maximize signal from the window manager has not been hooked up to the resizing terminal code.

Items 2 & 3 are still present.  When you drag and resize the window, make sure you make the window larger than the existing size rather than smaller.  Resizing smaller works.

On Windows, the terminal nicely just keeps expanding the line to the right, rather than putting in a pseudo-newline and starting input in the first column.  The only problem there, as the original reporter noted, is that there is no horizontal scrollbar.  I can use the cursor keys to scroll back to the start of the input just fine though.

Rik <rik5>
Group administrator
Fri 06 Feb 2015 03:48:24 PM UTC, comment #8: 

If you could just always tell the terminal to have a line width of, say, 10000, and always have a scroll bar, in all cases, this would simplify things for the gui. I tried to implement this myself a long time ago, but the qterminal code is so complex I couldn't figure out how it works in a reasonable period of time.

--the following rant can safely be ignored--

I still think a fixed width terminal isn't really required when you are definately embedded in a gui. If anything it's a hinderance to printing out nice tables and other output. In general I think qtterminal is over engineered for the Octave gui's purposes. FreeCAD is based on Qt and has an embedded python console which adds a scroll bar when required. If there was any interest in changing, it could possibly be repurposed. It's also cross-platform with the same implementation on both. There's probably a few python consoles which could be repurposed.

Richard <crobar>
Fri 06 Feb 2015 03:02:45 PM UTC, comment #7: 

I should say, I added that to the default branch, so you'd have to build from the default branch for Windows to test it.

Rik, if it works correctly when resizing but not when maximizing, then I guess we are not handling the window maximize signal in the same way that we handle the resize signal.  Hopefully that won't be too hard to fix.

I'm also not seeing the problem you describe with the cursor, at least on Linux systems.  Are you talking about Windows?

Also, I see the problem of not having a horizontal scrollbar with Unixy systems, though at least the text is not actually lost and you can recover it by resizing again...  Adding a horizontal scrollbar should not be too hard.

John W. Eaton <jwe>
Group administrator
Fri 06 Feb 2015 02:55:11 PM UTC, comment #6: 

The terminal window is currently implemented completely differently on Windows and Unixy systems, so if there are bugs in both, they are separate bugs.

The ultimate fix for these kinds of issues is probably a complete redesign of the way we handle command line input in the GUI so that the terminal window can be the same for all systems.

In the current Windows terminal window, a scrollbar should be added now when you shrink the window and previously displayed text in the terminal window should not be lost.  I made that change some time ago, but after June 2014.

John W. Eaton <jwe>
Group administrator
Fri 06 Feb 2015 02:39:49 PM UTC, comment #5: 

I see several undesireable things still.

1) The GUI comes up as a certain size.  If I maximize the window, the internal linewidth remains set at the previous window size.  This is not the case if I manually drag to extend the window size.

2) After one screenwidth of input the command line does not move to the next line, but goes back to column 1 of the existing line and starts overwriting the line.

3) If I use the up-arrow key to recall the previous command for a long line, it moves up the screen one line.  So if I repeatedly do up-arrow, down-arrow, up-arrow, down-arrow then the cursor retreats up the GUI screen.

Rik <rik5>
Group administrator
Mon 23 Jun 2014 02:18:27 PM UTC, comment #4: 

My last comment should have started "This is not a windows only problem, it also occurs in Linux ..."

Richard <crobar>
Mon 23 Jun 2014 02:16:38 PM UTC, comment #3: 

Linux. The problem can be reproduced in the following way:

1. Maximise Octave GUI window
2 Type long command which fills most of line in command window and run it
3. Resize GUI window to be smaller

The old commands (and output) are now not wrapped, and go off the size of the screen. You can still select them, but you can't read them without resizing the window again.


However, in my view a horizontal scroll bar is preferable anyway for long lines rather than wrapping in the command window. There is no need to wrap with a GUI. I wish my terminal emulator did this too, and actually had infinite width.

Richard <crobar>
Wed 12 Mar 2014 03:48:41 PM UTC, comment #2: 

long lines do not wrap; selection for copying misses the portion cropped horizontally.

Felipe G. Nievinski <fgnievinski>
Wed 12 Mar 2014 01:00:31 PM UTC, comment #1: 

So the line does not wrap in the Windows GUI? Or is it mouse selection across line breaks that is not working? Unclear from the description. Either way, long lines wrap in the unix terminal and can be copy and pasted correctly, updating to reflect Windows-only problem.

Mike Miller <mtmiller>
Group Member
Wed 12 Mar 2014 04:49:52 AM UTC, original submission:  

... when the user enters a command longer than the current maximum width, e.g.:


ddddddddddddddddddddd ddddddddddddddddddddddd dddddddddddddddddddddddd ddddddddddddddddddddddd ddddddddddddddddddddddddddddddddddddddddddddd


currently it's already possible to enter such long commands;
but it seems impossible to select and copy them to the clipboard.

the horizontal scroll bar would disappear upon issuing the clc command

Felipe G. Nievinski <fgnievinski>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #33972:  bug_41842-version-2.diff added by stefanm (27KiB - text/x-patch)
file #33447:  bug_41842.diff added by stefanm (24KiB - text/x-patch)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by nrjank (Posted a comment)
  • -email is unavailable- added by stefanm (Updated the item)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by crobar (Posted a comment)
  • -email is unavailable- added by fgnievinski (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 11 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-12-11 nrjank StatusNone Confirmed
        Operating SystemMicrosoft Windows GNU/Linux
        SummaryGUI Command Window should show horizontal scroll bar if necessary linux GUI Command Window should show horizontal scroll bar if necessary
    2022-12-11 nrjank StatusNeed Info None
    2018-04-27 mtmiller Carbon-CopyRemoved 80942 -
    2018-04-27 mtmiller Release3.8.1 dev
    2015-07-28 stefanm Attached File- Added bug_41842-version-3-experimental.diff, #34547
    2015-05-10 stefanm Attached File- Added bug_41842-version-2.diff, #33972
    2015-03-25 stefanm Attached File- Added bug_41842.diff, #33447
    2014-03-12 mtmiller StatusNone Need Info
        Operating SystemAny Microsoft Windows

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code