Widget focus switching using tab/shift+tab keys. Allows to move between
input field and buttons. Switching is limited to IncrementalSearchBar's
children.
Summary:
The idea is that a SplitterHeaderBar will be added in the
near future so the checks for the parent widget could be
wrong.
If instead of checking for a specific widget we check for
anything and walk to the parent list untill we find
a TerminalWidget seems sane, and safer.
Phabricator messed with this review and send the wrong diff together (because of the same parent)
so I'm rephrasing it.
Reviewers: #konsole, hindenburg, ngraham, #vdg
Subscribers: aaronhoneycutt, kvermette, thsurrel, rizzitello, mart, hindenburg, gennad, fabianr, ndavis, shubham, konsole-devel
Tags: #konsole
Differential Revision: https://phabricator.kde.org/D21301
Summary:
Resetting the widget palette to the app main palette fixes black
background problem in short and clean way.
Reviewers: #konsole, hindenburg
Reviewed By: #konsole, hindenburg
Subscribers: tcanabrava, konsole-devel
Tags: #konsole
Differential Revision: https://phabricator.kde.org/D14039
Summary:
When the focus is in `IncrementalSearchBar`, unhandled keys (i.e. those
not handled by text input box or `unhandledMovementKeyPressed` signal)
are sent to a program running in the terminal, which is probably not
what user expects. Example of propagated keys: Up, Down, PgUp, PgDown,
Fn, Tab.
This patch disables propagation. Shortcuts, movement keys, and keys
handled by search bar still works.
Test Plan:
* Run `cat`
* Open search box
* Press Up/Down/PgUp/PgDown/Tab/Fn keys
Actual result: keys are sent to `cat`
Expected result: nothing should happen (implemented)
Alternative expected result: focus should move from text input to first
button
**Regression test**
Following keys/shortcuts should work:
* Shift+Up/Down/PgUp/PgDown - terminal contents scrolling
* Ctrl+Shift+T - open new tab (unless it was changed)
* Enter - search next
* Esc - close search box
Reviewers: #konsole, hindenburg
Reviewed By: #konsole, hindenburg
Subscribers: konsole-devel
Tags: #konsole
Differential Revision: https://phabricator.kde.org/D14037
Summary:
Parent propagates the font to the child,
this was messing up the font used in the SearchBar.
Test Plan: Manually opened the search bar and verified the font.
Reviewers: hindenburg, ngraham, #konsole
Reviewed By: ngraham
Subscribers: konsole-devel
Tags: #konsole
Differential Revision: https://phabricator.kde.org/D14012
Summary:
Move the SearchBar to TerminalDisplay, killing the dependency from
the MainWindow and allowing it to be positioned as an overlay.
This fixes the following bugs:
- Opening and closing the SearchBar while top/htop is open
would garble the screen as top would wrongly redraw
two rows below, filling the screen with wrong text
- with tabs and splits, opening two searchbars and
clicking in the close button of the first without
focusing the terminal display first would cause
the tabbar not to close
- Smaller and prettier.
This never belonged here.
Searchbar belongs to the TerminalDisplay
Correctly position the SearchBar on topLeft
Fix initial size of the SearchBar
Icons, Position and Borders
Change the icons, positions and borders
of the SearchBar
Fix fill background of the Search Tab
Don't show the menubar by default
Fix icons & text
Reviewers: #konsole, hindenburg
Reviewed By: #konsole, hindenburg
Subscribers: ahmadsamir, ngraham, konsole-devel
Tags: #konsole
Differential Revision: https://phabricator.kde.org/D13511
Summary:
Use initializer list to create QSet
Don't check what doesn't needs to be checked.
the QBitArray knows how to deal with true / false
directly, so remove the if's. the speedgain of the
if's are probabely slower than just setting the values
to true / false again anyway as we are not suffering
from a possible branch-prediction, and plus, code is
cleaner.
No need to test for true / false to set true false
Just set it directly
Subscribers: konsole-devel
Tags: #konsole
Differential Revision: https://phabricator.kde.org/D13512
the QBitArray knows how to deal with true / false
directly, so remove the if's. the speedgain of the
if's are probabely slower than just setting the values
to true / false again anyway as we are not suffering
from a possible branch-prediction, and plus, code is
cleaner.
Thanks to Ahmad Samir ahmadsamir3891 gmail com for patch.
Todo: any changes to the settings should auto proprogate to all tabs'
search bars.
Review: 129376
Feature: 332601
- Do not automatically reset the search start line on search hits
This was causing the annoying behavior that if you were to pause while typing
in a search term, and it would actually find a hit, then you would be searching
for the term a second time once you finish typing.
This commit introduces two new behaviors:
1. When you show the search bar, all searching will be done from the first
visible line in the terminal.
2. This start position is only reset when you
advance to the next result, by pressing "next", "previous", or the shortcuts
RETURN or SHIFT-RETURN
- When the view scrolls to a result, it will appear centered.
- When showing the search bar, do not invoke a search, only apply the highlight filters
- Add "search from beginning/end" button
This will scroll to the top/bottom before searching
Ctrl+return is also bound to this action
- Text highlighted by mouse will be set as the current search text when the incremental
search bar is opened
- Add "Search backwards" to search bar options
Button text is swapped according to reverse search switch
(cherry picked from commit aa42a27ef3)
- Do not automatically reset the search start line on search hits
This was causing the annoying behavior that if you were to pause while typing
in a search term, and it would actually find a hit, then you would be searching
for the term a second time once you finish typing.
This commit introduces two new behaviors:
1. When you show the search bar, all searching will be done from the first
visible line in the terminal.
2. This start position is only reset when you
advance to the next result, by pressing "next", "previous", or the shortcuts
RETURN or SHIFT-RETURN
- When the view scrolls to a result, it will appear centered.
- When showing the search bar, do not invoke a search, only apply the highlight filters
- Add "search from beginning/end" button
This will scroll to the top/bottom before searching
Ctrl+return is also bound to this action
- Text highlighted by mouse will be set as the current search text when the incremental
search bar is opened
- Add "Search backwards" to search bar options
Button text is swapped according to reverse search switch
Currently the presence of the search bar is maintained per-tab, but the
search term itself is per-window. This leads to curiously inconsistent
behaviour. I believe there is little to suggest search terms remain
relevant across different tabs, and there is significant user
expectation that search terms/bar constrained to a tab (see browsers).
Patch by Lindsay Roberts linds.r@gmail.com
REVIEW: 109130
So if someone notices later some Qt header is included in the form
of "#include <Class>" instead of the more common form of "#include
<Module/Class>", do not rush changing it.
REVIEW: 105819
Set '_searchEdit' field background to 'KColorScheme::PositiveBackground'
when a search has a positive result.
BUG: 167442
REVIEW: 105777
FIXED-IN: 4.10.0