> On Feb. 3, 2015, 8:36 a.m., Martin Gräßlin wrote: > > David E. just pointed out that this could become quite heavy for the system > > as the history size can be large (up to 2048 items). > > Martin Gräßlin wrote: > Unfortunately I couldn't find out why we support up to 2048 items. Commit > message is just: > > commit da8394ce42a24726392265436c3808f1ac9389aa > Author: Esben Mose Hansen <k...@mosehansen.dk> > Date: Fri Nov 19 22:28:55 2004 +0000 > > Introduced support for large clipboard histories up to 2048 items. > > svn path=/trunk/kdebase/klipper/; revision=364353 > > Martin Klapetek wrote: > I think 2048 is insane. Can we make it like 32 by default and have it > configurable with big fat warning when you choose more than say 100? > > Btw. does klipper store things encrypted or something? There's also a > security concern, especially if your klipper contains passwords, that saving > those to disk unecrypted after each copy is insecure (all you need is a > watcher on the history file).
> I think 2048 is insane. Can we make it like 32 by default and have it > configurable with big fat warning when you choose more than say 100? The default is 7. Adding a warning is certainly possible. > Btw. does klipper store things encrypted or something? There's also a > security concern, especially if your klipper contains passwords, that saving > those to disk unecrypted after each copy is insecure (all you need is a > watcher on the history file). If you are able to watch the file you are also able to connect to the X11 Display and just do a passive keyboard grab. So caring about that probably doesn't matter (on Wayland this might get more important - maybe we can skip passwords). But setting the file to 600 is certainly a good idea. - Martin ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122382/#review75264 ----------------------------------------------------------- On Feb. 2, 2015, 4:12 p.m., Martin Gräßlin wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/122382/ > ----------------------------------------------------------- > > (Updated Feb. 2, 2015, 4:12 p.m.) > > > Review request for Plasma and Eike Hein. > > > 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 > ----- > > klipper/klipper.cpp d49c165759f8171931167687c3b36b3a9d7dee07 > klipper/CMakeLists.txt a08f062480b15f32f049e2d0d0e311dbe2964c02 > 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 > >
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
