bugGNU Octave - Bugs: bug #67054, Cursor simultaneously shown in...

 
 

bug #67054: Cursor simultaneously shown in Command Window and Editor

Submitter:  None
Submitted:  Sat 26 Apr 2025 05:44:29 AM UTC
   
 
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  None Assigned to:  None
Originator Name:  DIV Originator Email:  -email is unavailable-
Open/Closed:  * Open Release:  * 10.1.0
Release:  Operating System:  * Microsoft Windows
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Mon 28 Apr 2025 06:50:41 PM UTC, comment #3: 

Confirmed, good catch!

On my system (Debian Linux), the editor is the only widget that "steals" the focus during mouse scrolling. However, this does not happen if the editor is floating.

Torsten Lilge <ttl>
Group Member
Mon 28 Apr 2025 01:31:00 PM UTC, comment #2: 

Thanks, Torsten Lilge <ttl>. 

I will check out the ideas you suggested. 

In the meanwhile I have just noticed another related behaviour that I find undesirable. 

With the specified GUI layout (both Command Window and Editor shown at the same time), I notice that there is inconsistent handling of mouseover scrolling. 

Compare the following.  

  • Working (typing) in Command Window;  move mouse pointer to hover above Editor region;  turn scroll wheel of mouse (no clicks):  Editor takes the focus. 
  • Working (typing) in Editor;  move mouse pointer to hover above Command Window region;  turn scroll wheel of mouse (no clicks):  Command Window does not take the focus. 


In my opinion clickless scrolling during mouseover should not be sufficient to change the focus. 

Alternatively, if (hypothetically, and contrary to my preference) Octave developers believe that clickless scrolling during mouseover should be sufficient to change the focus, then it should be consistent for all parts of the GUI. 

—DIV

Anonymous
Sat 26 Apr 2025 07:56:19 AM UTC, comment #1: 

Thanks for your report.

The reason for the different cursors and cursor behaviors in terminal and editor window is that both are using different underlying tools: the terminal window is a 'real' terminal and the editor window a Qt-version of the Scintilla editor.

The preference Set focus to Command Window when running a command from within another widget in the preferences dialog's Command tab might be helpful for your workflow. Maybe it is less annoying if you type something into the terminal that should go into the editor than vice versa. Another workaround might be starting octave with the option --experimental-terminal-widget. The GUI then uses a different, Qt-based terminal where the cursor is hidden when losing focus. However, user input is still not working and there might be other issues (it really is still in an experimental state).

Anyhow I will check if the terminal cursor can be hidden when the widget does not have focus.

Torsten Lilge <ttl>
Group Member
Sat 26 Apr 2025 05:44:29 AM UTC, original submission:  

Current Octave behaviour:
When the Editor has focus, a cursor is still shown in the Command Window. 
(Conversely, when the Command Window has focus, the cursor in the Editor is hidden.)
Sometimes even both cursors are flashing simultaneously! 

System: 
Freshly installed Octave 10.1.0 on Windows 10 x64. 
Extracted from 7z archive.  Ran "post-install.bat" and then launched from (undocumented???) "octave-launch-firsttime.exe".  I got a bunch of irritating error messages from Octave about the console, so I switched a Windows setting for the terminal from "Let Windows decide" to "Windows Console Host". 

Consequence:
It is very frustrating to me.  In the past couple of days I often run my script, which produces several output figures.  When I return to the main Octave window I see the cursor in the Command Window.  As I am developing the script, I might want to type something into the Command Window.  (For instance, "whos" or perhaps just check the value of some specific array element, like "myArray(1,2,3)".) 
But, of course, I had just run the script, so despite the cursor shown in the Command Window, the edit ends up somewhere (where I wasn't looking) in the Editor.  So I have to carefully undo the mistaken edit to the script, without inadvertently undoing any of my prior (intentional) amendments to the script. 

Workaround: 
Not much of a workaround, but following
https://savannah.gnu.org/bugs/?func=detailitem&item_id=63336
I have changed the default cursor from I-beam to block in the Octave Preferences. 
This does have a benefit of making it more obvious as to whether the cursor is flashing or not.  Also, the block cursor is less common, so it will jog my memory to be careful. 
However, I note that the preference only affected the Command Window.  Unexpectedly, the Editor continues to employ the "I-beam" cursor.  (Although, in practice it is shaped as a sans serif "I", so it might just be described as a plain vertical line.)  The user would naturally expect the cursor to be the same style in all panes, so this unexpected behaviour would qualify, IMHO, as a second (separate) bug. 

Speculation: 
Perhaps other users have not experienced this because of my window layout. 
I have both the Command Window and Editor docked, but not overlapped in the same screen region as in the default.  Rather, I have the Editor docked at top right of the GUI, and the Command Window docked at bottom right of the GUI. 

To resolve this: 
When the Editor has focus, the cursor in the Command Window should be hidden. 


Some other references to "cursor" in bug reports:
https://savannah.gnu.org/bugs/?func=detailitem&item_id=57635
https://savannah.gnu.org/bugs/?func=detailitem&item_id=63336
https://savannah.gnu.org/bugs/?func=detailitem&item_id=63857
https://savannah.gnu.org/bugs/?func=detailitem&item_id=65725
Maybe those are all resolved, and they don't seem to involve the same symptoms as I'm reporting.  Nevertheless, perhaps there's something relevant.

Anonymous

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by ttl (Posted a comment)
  •  

    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.

     

    No changes have been made to this item

    Back to the top

    Powered by Savane 3.15-e283.
    Corresponding source code