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


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

Submitted by:  Felipe G. Nievinski <fgnievinski>
Submitted on:  Wed 12 Mar 2014 04:49:52 AM UTC  
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Feature Request
Status:  Need Info Assigned to:  None
Originator Name:  Open/Closed:  Open
Release:  dev Operating System:  Microsoft Windows

Add a New Comment (Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

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>
Project 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>
Project 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>
Project 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>
Project 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>
Project 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>
Project 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>
Project Administrator
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:

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 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)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.




    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    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.6