To support focusing a session from a notification in Wayland, we need to
use the XdgActivation protocol. This is done by passing to
KWindowSystem an XDG activation token that we get from the notification.
Adds a "Show session" button to notifications, which, when clicked, will
focus the originating session.
Original patch by Kasper Laudrup at bug 305162, then updated by Martin
T. H. Sandsmark.
Now updated and extended to silence/activity/process termination
notifications, adding support for focusing a TerminalDisplay inside a
hierarchy of ViewSplitters inside a TabbedViewContainer, and using
KWindowSystem::forceActiveWindow() instead of ::activateWindow().
BUG: 305162
BUG: 344208
Before 3d6c839b, sessions were snapshotted every 2 seconds, and also
half a second after the associated view received focus or a key press.
This second timer could theoretically be postponed indefinitely.
Commit 3d6c839b tries to save energy by not taking a snapshot every 2
seconds, and instead has a timer that fires half a second after any
event received by the application.
This commit goes back to the old behavior, but still without the 2
second timer, and also sets the half second timer after receiving the
Emulation::outputChanged signal, which is sent at a maximum 40ms after
the emulation receives data. It also copies the idea from commit
3d6c839b of not restarting the timer if it's already started, since
otherwise, continuous output could postpone the timer indefinitely.
- Selecting Copy (or pressing ctrl-shift-c) when there is no selection
selects current output if current mode is output, current input if
current mode is input and input is non-empty, and last output if current
input is empty.
- Ctrl + mouse triple click selects the pointed input/output/prompt.
- There is also a fix that was missed in previous patch for keeping
track of current semantic mode through scrolls.
Bugs reported here:
https://invent.kde.org/utilities/konsole/-/merge_requests/691#note_480025
- Properly ignore OSC parameters for now. (later we'll support some).
- Handle Input end for when command gets shorter.
- Always draw separating line in foreground color
- Don't group characters of different REPL type.
- Don't reset double width/height attributes of erased lines.
This change removes some application attributes that are not necessary anymore (like disabling the global menu bar) or make Konsole behave slightly different when used from a KPart (e.g. inside Kate), and changes some keyboard shortcuts around (mainly using Command instead of Ctrl+Shift now.)
Unfortunately this does not resolve the requirement for the special keytab file for macOS; it looks like Qt does something funny with the QKeyEvents here: on Linux these have a `text` attribute set to e.g. `\u0003` for `^C`, that attribute is empty on macOS.
Note this could impact shortcut changes on non-macOS systems.
- Port QStringRef to QStringView (using Q5StringRef::toInt() because
Q5StringView::toInt() uses toString() internally to get a QString
which defeats the point of using a view)
- Fix creating a QKeySequence from OR'ing Qt::Key and Qt::Modifiers by
explicitly constructing a QKeySequence; IIUC, this is due to the two
values coming from two different enums:
"cannot convert ‘QIncompatibleFlag’ to ‘const QKeySequence&’"
- Implicit cast from int to QChar is gone in Qt6
- Implicit cast of QString to QFileInfo is gone in Qt6
- Create a QByteArray to make QStringBuilder work
- QHash::const_iterator can't be used in place of a
QMultiHash::const_iterator
There is no reason for a tab title to change if there is no QT event.
So, instead of snapshoting session regularly, we do it only if there is
some QT events. To catch all QT events an event handler is installed on the
QCoreApplication instance.
* Rename everything related to built-in profile both in code and UI.
* Unified style for [Read-only] and [Default] badges in profile
manager's list model.
* Change --fallback-profile option to --builtin-profile.
* Backward compatibility: yes. If a user happened to name their
profile "Built-in", it would continue to work as normal, and even
load with `--profile "Built-in"` command line flag. It will let them
modify any property including Name; but changing the name back
to "Built-in" shows a warning and reverts the change as usual.
* Remove "This option is a shortcut for" sentence. While it is still
technically possible to pass built-in profile's magic path, this
option is not a shortcut, nor implemented as such.
* Delete extra naming conditions in ProfileManager::changeProfile,
because they could never be triggered anyway, due to pre-flight
checks in EditProfileDialog::isProfileNameValid. Automatic unique
profile names generation has been done even earlier in either
SessionController or ProfileSettings. Just as before, users will
continue experiencing a generic "A profile with the name \"%1\"
already exists." message.
Tests:
* Improve test for uncreatable file name of built-in profile.
* Add backward compatibility test for loading existing profile
named "Built-in" which also references real built-in as its parent.
BUG: 438309
Commit c3b3ef19 introduced a regression when invoking the
clear-history-and-reset action. While RIS (Reset to Initial State) is
specified in DEC STD-070 as homing the cursor, konsole has grown some
hacks in the name of usability to preserve the command prompt line.
For a long time, it has sent two SIGWINCH with changed sizes after clear
and reset actions to force the shell to redraw the prompt (see d346a2cc,
temporarily disabled on 5d61b69e and re-added on 82778e87), which works
for bash, zsh, ksh, ...
tcsh doesn't redraw its prompt on SIGWINCH, but commit b8e96bcd modified
Screen::refresh() so instead of clearing the entire screen and homing
the cursor, it scrolled up everything but the last (usually the prompt)
line.
So, keep that last hack when called from clear-history-and-reset, and
behave as specified on DEC STD-070 otherwise.
Note that other ways of clearing the screen don't need hacks, e.g.
Ctrl-L, if handled at all, is handled by the shell, which then redraws
its prompt. Calling "clear" or invoking "printf '\ec'" will result in
the shell redrawing its prompt in the usual way.
BUG: 453568
This is also not optimal because only two file browsers
implements org.freedesktop.org/FileManager1
Missing filemanagers:
- Konqueror
- Krusader
- Thunar
But at least is freedesktop.org accepted
void KFileItemActions::insertOpenWithActionsTo(QAction*, QMenu*,
const QString) requires KF 5.78 while
void KFileItemActions::insertOpenWithActionsTo (QAction*, QMenu*,
const QStringList) requires KF 5.82. For any KF version earlier, use
void KFileItemActions::addOpenWithActionsTo(QMenu*, const QString)
Fixes build on older systems after
https://invent.kde.org/utilities/konsole/-/merge_requests/527
9f656939 introduced the possibility of showing a session in multiple
views, something which is no longer supported. In doing so, it started
passing QApplication::activeWindow(), instead of TEWidget (nowadays
TerminalDisplay) to KNotification.
7592e894 split notifications for focused/unfocused terminals.
Unfortunately, QApplication::activeWindow() returns nothing for unmapped
windows, which results in issues when notifications are configured to
mark the task bar entry or run a command with %w/%t substitutions (for
window id and window title).
BUG: 443117
There were two bugs with the previous implementation
one is that it didn't took in consideration the
Profile -> Mouse -> Advanced -> Underline Files
With that enabled, right click on the name of the folder
would give you a Open Folder With entry, so we would
end with two actions.
The other bug also triggered when that setting is enabled:
we never marked the Open Folder With for removal, after
inserting the menu for the underlined file.
Every time the selection is changed, the selection text is retrieved to
check whether to enable or disable the copy actions. Besides that, the
selection text is also used for the web search context menu entries.
Better just check if the selection is empty and make a note that the
selection changed, so the next time the context menu is invoked it can
retrieve the current selection text, which should happen much less often
than selection changes.
There is an inconsistence in "Find Next/Previous" icons in Edit menu and
the search bar. Make sure they are consistent whenever "Search backwards"
is checked or not.
BUG: 443244
This is similar to commit c413d543c1, EditProfileDialog's base class
(KPageDialog) already connects OK button clicked signal to accepted() signal;
creating another connection to accepted() in SessionController (which
creates the EditProfileDialog object), means the code will be run twice, not
ideal. Instead put the logic in EditProfileDialog::save() which is called by
the EditProfileDialog::accept() slot.
The same goes when ProfileSettings creates an EditProfileDialog.
- Add a type alias for QPointer<Session>
- Use TerminalDisplay::setSessionController() as early as possible
- Use Screen::setCurrentTerminalDisplay() in TerminalDisplay::mousePressEvent(),
this matches what's being done in keyPressEvent()
- Add convenience function TerminalDisplay::currentSession()
- More const
Now when creating a new profile, the title will be "Create new profile",
this is less confusing when the user tries to edit e.g. the Fallback profile,
which in effect will create a new profile as the Fallback one is immutable.
This should prevent opening two instance of the EditProfileDialog in the
same process, i.e. if "run all konsole windows in a single process" option is:
- Enabled, then opening the dialog will block user interaction with all
other konsole windows (including tabs).
- Disabled, then open the dialog will block user interactin with all
other tabs in the same window
This simplifies the code since it checked if such a dialog was open
somewhere else to prevent crashes.
exec() creates a nested eventloop, which could lead to some nasty
crashes ...etc.
ProfileSettings::editSelected(): since the dialog is modal, the user
can't interact with the konsole window at all, so no chance of opening
another instance of the EditProfileDialog.
This is a first step in simplifying the code; since the Fallback profile
doesn't have a file on disk, it's basically a corner-case that we have to
babysit in various places in the code.
Now when the user tries to "Edit current profile", if it's the Fallback
profile, a new profile is created, with a unique name "Profile 1",
"Profile 2" ...etc. This is similar to using the "New" button in the
ProfileSettings dialog.
