Review Request 123806: [klipper] Ignore empty / blank entries
Thomas Lübking
thomas.luebking at gmail.com
Sun May 17 13:02:28 BST 2015
> On Mai 16, 2015, 4:37 nachm., Christoph Feck wrote:
> > klipper/klipper.kcfg, line 32
> > <https://git.reviewboard.kde.org/r/123806/diff/3/?file=369517#file369517line32>
> >
> > It would be immensely useful, if Klipper also showed leading/trailing whitespace, i.e. for items that aren't completely whitespace.
> >
> > Firefox loves to add leading whitespace when copying double-clicked text, but Klipper does not show this in the menu.
>
> Christoph Feck wrote:
> See bug 159267.
>
> Patrick Eigensatz wrote:
> Question if we should make an option to replace whitespaces generally. Like:
>
> [ ] Allow history items to consist only of whitespaces
> [ ] Display whitespace characters with symbols
>
> The checkboxes would be independent, so it would be possible to see tabs and spaces **AND** the user would still be able select if he wants to see "blank" entries.
>
> Seems like the best solution to me. :)
>
> Heiko Tietze wrote:
> Did my pic before reading your last comment. Consider to use either a checkbox above the radio buttons, just instead of the title, or replace it all by a dropdown menu. Please don't use my bad English as a reference. The mockup illustrates only the alignment idea.
>
> 
>
> Patrick Eigensatz wrote:
> Heiko, I see your concerns on grouping and aligning; I could change the design and create a seperate patch and a seperate view request.
> Hmm, if we use radio buttons it won't be possible to have symbolic placeholders **and** ignore blank entries... How would you solve this?
>
> Thank you
>
> Heiko Tietze wrote:
> If an option is not exclusive the checkbox comes into play. But I don't think you can have both features. And finally I agree that the solution in #123821 is good and a simple checkbox 'Trim whitespace characters' would be sufficient.
> However, the grouping and the alignment has still room for improvements. To be honest the whole feature is not 'simple by default', which should be our first concern.
>
> Patrick Eigensatz wrote:
> Okay, so solution #123821 for default...
>
> I'm not sure if we should file a bug or if I just file another review request with a "design patch" to fulfill the HIG altough I'm new to QTDesigner...
>
> I start now implementing a simple checkbox "Trim whitespaces" additionally to solution #123821.
>
> Thomas Lübking wrote:
> @Heiko
> "Ignore selection" (i assume the entire selection part) refers to the primary selection buffer, the thing where stuff is copied when you "select" it (with the mouse) and that's pasted w/ MMB clicks.
>
> http://en.wikipedia.org/wiki/X_Window_selection
>
> I assume the timeout and history size items don't belong into that box, which could then be a checkable groupbox (but some klipper dev should confirm - or we must lookup the code ;-)
>
> Thomas Pfeiffer wrote:
> I do agree with Heiko that the whole dialog is in need of improvement. Let's please keep this thread to the discussion of the feature in question, however.
>
> As for that: Having the radio button group makes sense to me. And, like Heiko, I do not think that replacing whitespace with placeholders but not allowing whitespace-only entries is a useful option (even though it is technically possible, of course). Both are useful mostly for people which often work with "code" of some kind, so there aren't likely to be many users who want one but not the other. And those few users that may want only one are not worth making the whole thing more complex for all users.
>
> And this way we do not need any complicated "allow whitespace-only entries" label. Either whitespace is trimmed - which logically implies that entries consisting only of whitespace are eliminated altogether - or it isn't, which means that entries consisting only of whitespace are not eliminated.
>
> Patrick Eigensatz wrote:
> I will open another review request so we can improve the dialog.
>
> Did I understand correctly now?
>
> **Whitespace handling**
> ( ) Trim whitespace characters *(default?)*
> (o) Normal whitespace
>
>
> As you said, trimming would eliminate whitespace-only entries, too.
>
> Thomas Pfeiffer wrote:
> Either that plus
> ( ) Replace whitespace with symbols
>
> Or just
> [ ] Trim whitespace characters
> And then always use placeholders if trim is unchecked.
>
> I'm still not 100% sure if there might be people who want to keep their whitespace as is (which would be "Normal whitespace").
>
> Ideally someone would show the solution from #123821 to a few people and ask them what that is and if they find it useful. And ask those who do not find it useful whether they'd prefer just trimming the whitespace
>
> Patrick Eigensatz wrote:
> So, we need to decide:
>
> a) The symbols from Solution #123821 always. Plus a trim checkbox in the config dialog.
> 
>
>
> b) The 3 radiobuttons:
> 
>
>
>
> Quote from Christoph Feck, Solution #123821:
> *"The coloring isn't annoying, so I see no reason why anyone would need to turn this off."*
>
> If the people we ask think this is true, we would just make it default and renounce another checkbox.
>
> Thomas Lübking wrote:
> "Trim blank whitespace entries"? ;-)
>
> @Thomas P.
> > And then always use placeholders if trim is unchecked.
>
> Please notice itr. that "trim" is different from "simplify" - the former only removes trailing and leading whitespaces while the latter reduces every whitespace "area" to a single space, ie. trimmed text may still contain newlines (ie. pasting that into eg. konsole would cause a command execution)
>
> Patrick Eigensatz wrote:
> @Thomas Lübking: Yes, this wording is somehow ironic... Should I use "Trim whitespaces"?
>
> Thomas Lübking wrote:
> depends on what it ultimately will do.
> Either "Trim whitespace" or "Allow/Ignore whitespace-only text" (Ignore if the negative wording isn't changed)
>
> Thomas Pfeiffer wrote:
> Hm... I tend toward trimming all non-printable characters at the beginning and end of each selection, e.g. to avoid unintentional code execution while pasting into a console.
> On the other hand, people may want to select and paste words with leading or trailing spaces into a text.
> It may still make sense to only the choice between either trimming the whitespace or showing the placeholders. That way accidental code execution would be avoided.
>
> It's also something we should test with a few users, though.
if you paste QString(" \n \t sudo dd if=/dev/zero of=/dev/sda\necho BLAST\n \t \n ").trimmed() into konsole, you still have a problem (becomes "sudo dd if=/dev/zero of=/dev/sda\necho BLAST", "sudo dd if=/dev/zero of=/dev/sda" is executed)
If you want to prevent accidental code execution, you'll have to go for QString(" \n \t sudo dd if=/dev/zero of=/dev/sda\necho BLAST\n \t \n ").simplified(), which becomes "sudo dd if=/dev/zero of=/dev/sda echo BLAST"
So the toss is probably between verbatim whitespace (which should be indicated with placeholders) and simplified whitespace, where _all_ whitespace is replaced by a single space (and trimmed from the ends)?
PS: please don't try what that command does ;-)
- Thomas
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123806/#review80466
-----------------------------------------------------------
On Mai 16, 2015, 9:31 nachm., Patrick Eigensatz wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123806/
> -----------------------------------------------------------
>
> (Updated Mai 16, 2015, 9:31 nachm.)
>
>
> Review request for kde-workspace, KDE Usability and Patrick Eigensatz.
>
>
> Bugs: 159267 and 192922
> https://bugs.kde.org/show_bug.cgi?id=159267
> https://bugs.kde.org/show_bug.cgi?id=192922
>
>
> Repository: plasma-workspace
>
>
> Description
> -------
>
> [PATCH] plasma-workspace: klipper: Fix #192922 Ignore blank entries
>
> QString::isEmpty() is used to check if the string only consists of whitespace characters. If it does, the creation of the HistoryStringItem fails.
>
>
> Diffs
> -----
>
> klipper/generalconfig.ui f513e9c
> klipper/historyitem.cpp 36cbe61
> klipper/klipper.h 6952b11
> klipper/klipper.cpp 798b49f
> klipper/klipper.kcfg a03dd16
>
> Diff: https://git.reviewboard.kde.org/r/123806/diff/
>
>
> Testing
> -------
>
>
> Thanks,
>
> Patrick Eigensatz
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20150517/5f8b7ded/attachment.htm>
More information about the kde-core-devel
mailing list