Bug 151966 - Flow control active indicator appears anyway, when flow control keys are disabled for a profile
Summary: Flow control active indicator appears anyway, when flow control keys are disa...
Status: RESOLVED FIXED
Alias: None
Product: konsole
Classification: Applications
Component: general (show other bugs)
Version: 1.9.2
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: Konsole Developer
URL:
Keywords:
: 154093 154106 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-11-07 01:04 UTC by Will Stephenson
Modified: 2008-04-07 03:45 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Changes for better support of Ctrl+S/Ctrl+Q/ScrollLock flow control. (47.37 KB, patch)
2008-04-07 03:03 UTC, Vladimir Rutsky
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Will Stephenson 2007-11-07 01:04:26 UTC
Version:           1.9.2 (using KDE Devel)
Installed from:    Compiled sources
OS:                Linux

re #48485 - the code in TerminalDisplay::outputSuspended showing the warning widget does not check whether the user disabled flow control for the profile.
Comment 1 Pushyamitra Navare 2007-12-10 09:08:06 UTC
I've seen this as well. Indicator appears anyway even if I have disabled flow control option. I am using 4.0 RC1 testing package from Ubuntu. Any way I can disable the indicator for now?
Comment 2 Ivo Anjo 2007-12-13 18:03:41 UTC
I can confirm this too, on recent svn, and it's very annoying.
Comment 3 Robert Knight 2007-12-15 22:31:50 UTC
*** Bug 154106 has been marked as a duplicate of this bug. ***
Comment 4 Robert Knight 2007-12-15 22:32:28 UTC
*** Bug 154093 has been marked as a duplicate of this bug. ***
Comment 5 Robert Knight 2007-12-16 00:08:22 UTC
Fixed in SVN revision #748936
Comment 6 Vladimir Rutsky 2008-04-07 03:03:39 UTC
Created attachment 24257 [details]
Changes for better support of Ctrl+S/Ctrl+Q/ScrollLock flow control.
Comment 7 Vladimir Rutsky 2008-04-07 03:36:39 UTC
Posted attachment above...

Goal of above attachment is not to show bothering message about "Ctrl+S was pressed" when it is not needed, because not always Ctrl+S locks output.
My favorite Midnight Commander disables flow control on output (Xon) and Ctrl+S is a very useful shortcut in mc for searching.

This is a pretty big patch, I tried to finalize work on described below articles so that there be more logic and less hack.

I divided 2 kind of locks: Ctrl+S/Ctrl+Q and ScrollLock.
Ctrl+S/Ctrl+Q supported by terminal, and Konsole only guess when this lock is enabled, and show warning about this. Guessing is done by checking process terminal IXON flag when Ctrl+S key combination invoked. 
ScrollLock is a "software" lock, as I understanded it should be done through Pty::lockPty() method, but it is not working due to some bugs in library.

Changed options menu to have buttons for:
1) Enable disabling/enabling on-the-fly Ctrl+S/Ctrl+Q flow control support.  Implemented, but when I change terminal flags through Pty::setXonXoff() they changes only on some period of time, something isn't correct...
2) Enable disabling/enabling on-the-fly ScrollLock flow control support. Implemented, but until Pty::lockPty() not works disabled.
3) Enable showing warning label.

There are 2 warning labels now for each kind of lock.

Added Ctrl+S/Ctrl+Q flow control commands to KeyboardTranslator: stopOutput, restartStoppedOutput, so shortcuts is definable, not sure is this thing needed, but it's comfortable in code. 
So now there are additional strings in keyboard layouts files:
> +key S     +Control : stopOutput
> +key Q     +Control : restartStoppedOutput

As I understanded from documentations about TTY it is possible to redefine keys for suspending/resuming with Xon/Xoff, so this is completele unsupported now.

Comment 8 Robert Knight 2008-04-07 03:44:16 UTC
Hi Bob,

Comments on the patch in comment #6:

1.  The changes in your patch are not fixes for this bug report.  It helps maintenance if each bug report is kept to one bug or feature, plus links to any reports which this one depends on.  Non-trivial new features or bugs should go in a new report.    

2.  If you want to propose new features, with patches, then that is appreciated but I do need a rationale for why Konsole should have them and who would want to use them and how.  If you plan to make user interface changes then it is best to discuss those first before writing the code.  In this case for example you add two new checkboxes to the "Advanced" tab of the profile editor.  This tab is already quite tall - which means that it would need to be re-arranged first rather than just adding the new controls in-place.

3.  That is a large patch which has a mix of API documentation fixes, multiple new features and refactoring.  This is not easy to review and comment on because there is a lot going on.  Please break it down into separate patches - one per feature, bug fix, refactoring or documentation update.  Formatting changes, which I'd rather not see too many of, come under refactoring.    

Comment 9 Robert Knight 2008-04-07 03:45:59 UTC
Regarding point 2 in comment #8 - I wrote that after seeing the huge patch but before your explanation was posted.  Please add the explanation first.