Skip to content

fix: don't send clipboard network packets on empty text

Arjan Marku requested to merge bino/kdeconnect-kde:fix_empty_clipboard_packets into master

Summary

Ignore empty clipboard text updates in KDE since from an end-user it unnecessarily clears the current clipboard selection and results in many "Copied to clipboard" toasts.

BUG: https://bugs.kde.org/show_bug.cgi?id=484409

Before:

If you lock the screen in EndeavourOS (KDE Plasma 6), a signal KSystemClipboard::changed is emitted with empty text and clipboard mode QClipboard::Clipboard. Upon unlock the clipboard will be re-synced.

A clipboard network packet will be sent for KSystemClipboard::changed signals if:

  1. the received mode is QClipboard::Clipboard
  2. the new content and its type are different from the current ones.

The problem here is that, before locking the screen, current content is not empty. As of condition #2, a network packet with the empty text will be sent, which clears the current clipboard selection in GBoard but the contents stay the same. Upon re-sync in unlock, a packet will be sent again due to #2.

After:

Locking / unlocking in EndeavourOS will not send clipboard network packets to KDEConnect-Android (unless the phone has been locked for some time and a plugin reload is triggered by KDEConnect-KDE, reconnecting will resend the current clipboard content).

Edited by Arjan Marku

Merge request reports