Fix notification reply window activation and focus

Ensures the reply window is raised using Qt::WindowActive state. This
properly raises the window reliably (including from plasmoid, which
didn't work at all before) and focuses the reply textbox.

CMakeLists.txt

@@ -88,6 +88,9 @@ endif()
 add_definitions(-DQT_NO_URL_CAST_FROM_STRING -DQT_NO_KEYWORDS -DQT_NO_CAST_FROM_ASCII)
 
 find_package(Qt5 ${QT_MIN_VERSION} REQUIRED COMPONENTS DBus Quick QuickControls2 Network Multimedia)
+if (UNIX AND NOT APPLE)
+    find_package(Qt5 ${QT_MIN_VERSION} REQUIRED COMPONENTS X11Extras)
+endif()
 find_package(KF5 ${KF5_MIN_VERSION} REQUIRED COMPONENTS ${KF5_REQUIRED_COMPONENTS})
 if (KF5_OPTIONAL_COMPONENTS)
     find_package(KF5 ${KF5_MIN_VERSION} COMPONENTS ${KF5_OPTIONAL_COMPONENTS})

plugins/notifications/CMakeLists.txt

@@ -21,4 +21,11 @@ target_link_libraries(kdeconnect_notifications
     Qt5::DBus
     KF5::Notifications
     KF5::I18n
+    KF5::WindowSystem
 )
+
+if (UNIX AND NOT APPLE)
+    target_link_libraries(kdeconnect_notifications
+        Qt::X11Extras
+    )
+endif()

plugins/notifications/notificationsplugin.cpp

@@ -11,6 +11,11 @@
 #include <dbushelper.h>
 
 #include <KPluginFactory>
+#include <KStartupInfo>
+
+#if !defined(Q_OS_WIN) && !defined(Q_OS_MAC)
+#include <QX11Info>
+#endif
 
 K_PLUGIN_CLASS_WITH_JSON(NotificationsPlugin, "kdeconnect_notifications.json")
 
@@ -152,6 +157,12 @@ void NotificationsPlugin::replyRequested(Notification* noti)
     SendReplyDialog* dialog = new SendReplyDialog(originalMessage, replyId, appName);
     connect(dialog, &SendReplyDialog::sendReply, this, &NotificationsPlugin::sendReply);
     dialog->show();
+#if !defined(Q_OS_WIN) && !defined(Q_OS_MAC)
+    auto window = qobject_cast<QWindow*>(dialog->windowHandle());
+    if (window && QX11Info::isPlatformX11()) {
+        KStartupInfo::setNewStartupId(window, QX11Info::nextStartupId());
+    }
+#endif
     dialog->raise();
 }
 

plugins/notifications/sendreplydialog.cpp

@@ -32,6 +32,7 @@ SendReplyDialog::SendReplyDialog(const QString& originalMessage, const QString&
     setWindowIcon(QIcon::fromTheme(QStringLiteral("kdeconnect"),
         QIcon(QStandardPaths::locate(QStandardPaths::AppLocalDataLocation, QStringLiteral("icons/hicolor/scalable/apps/kdeconnect.svg")))));
     setAttribute(Qt::WA_DeleteOnClose);
+    m_ui->replyEdit->setFocus();
 }
 
 SendReplyDialog::~SendReplyDialog() = default;

[Friedrich W. H. Kossebau]

Hi. Curious. what is providing the startupid in QX11Info::nextStartupId() before? Is it something which also delivers the notifcation which is handled here? Where would it be comming from? Sorry, no insight in kdeconnect itself, only interested to learn about the usages around the X11 startup id.

[Bharadwaj Raju]

Honestly I have no idea. I took this code from Discover: https://invent.kde.org/plasma/discover/-/blob/master/discover/main.cpp#L93 (which reminds me I've got to add the new Wayland activation-token codepath here)

From the QX11Info docs, I think it is something per-process, managed internally by Qt? Also see https://specifications.freedesktop.org/startup-notification-spec/startup-notification-latest.txt. Beyond that I really don't know, sorry.

[Friedrich W. H. Kossebau]

Thanks for the quick reply. When it comes to startip id, I know some bits around it, at least to what code in Qt/QXcbConnection itself uses that data, so less my curiousity :)

But curious here why the update is needed, usually that needs to be done only when the initial startup id had already been used with a window, and something prepared the new startup id and one wants to use it for an existing window instead of a new one.