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.
This isn't needed as QMenu takes care of deleting removed actions (that
are children of it). Confirmed with QObject::connect() call on
QObject::destroyed signal. And skimming the upstream QMenu::actionEvent()
code.
_preventClose has to be set to false right at the end, so as to prevent
crashes if the user selects the "close session" action from the context
menu in a Konsole KPart (e.g. the terminal panel in Dolphin).
Check menu object isn't null before deleting actions from it.
BUG: 429538
