Review Request 122382: [klipper] Sync history to disk after each change

[Martin Gräßlin]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122382/
-----------------------------------------------------------

(Updated Feb. 16, 2015, 10:12 a.m.)


Review request for Plasma and Eike Hein.


Changes
-------

To not overload the system the save operations are delayed and queued.
Each save is delayed by five seconds since the last clipboard change.
So if the clipboard is changed multiple times in a short interval it
doesn't get synced to the disk till the interaction has settled.


Bugs: 343333
    https://bugs.kde.org/show_bug.cgi?id=343333


Repository: plasma-workspace


Description
-------

By invoking saveHistory after each change we ensure that the clipboard
doesn't lose data in case klipper (or in dataengine mode plasmashell)
crashes.

To not cause stalls, the saving is performed in a thread using
QtConcurrentRun. As klipper itself is not thread save a Mutex is
used to lock changes in the HistoryModel.

BUG: 343333
FIXED-IN: 5.3.0


Diffs (updated)
-----

  klipper/klipper.h 8bb4286f39bb9855602dbe093be90e7a128c7c24 
  klipper/klipper.cpp 6b6d610f2ea4eda962530e2024b1b0a4da06cf7f 
  klipper/CMakeLists.txt 099cb712774c78faf61029e2b1c5706320010ddd 
  klipper/historymodel.h 78f955f0ec4b8f27dbca0573b68691be6a30e3be 
  klipper/historymodel.cpp 51860f6c3aca1022a2b721c27c859fc721915353 

Diff: https://git.reviewboard.kde.org/r/122382/diff/


Testing
-------

looked at ~/.local/share/klipper/history2.lst in Okteta, changed clipboard and pressed F5 in Okteta. Repeated these steps multiple times.


Thanks,

Martin Gräßlin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20150216/d157246b/attachment-0001.html>