Review Request 123806: [klipper] Ignore empty / blank entries
Patrick Eigensatz
patrick.eigensatz at gmail.com
Sat May 16 12:44:48 BST 2015
> On Mai 15, 2015, 7:31 nachm., Martin Gräßlin wrote:
> > thanks for rebasing!
> >
> > I just had a look at the bug report and have to agree with comment #1: I do from time to time copy on purpose whitespaces (yes I'm weird). I also tend to copy newlines and I do want to have them in the history. If I understand your commit description correctly this "feature" would break.
> >
> > Given that I think we need more input on whether we want to break that feature or whether we want to create a config option for it.
>
> Patrick Eigensatz wrote:
> Hi Martin!
>
> Yes, this "feature" would break. However, if you copy more than one whitespace sequence you won't be able to identify them in the klipper menu.
> But your concerns are right. I could try to implement an option for this, although I've never done this before and I would surely need some assistance...
>
> Kai Uwe Broulik wrote:
> I also sometimes copy whitespace but then I immediately paste it in, so I wouldn't need it in the history, its representation in the history could probably be improved, if so desired. Perhaps add the usability group to this review request so they can have a look at this.
>
> Thomas Lübking wrote:
> I usually copy whitespaces and newlines w/ the primary selection buffer (for RMB) to click and paste commands when there's no WM ;-)
>
> As for distinguishing entries in the history, whitespaces could be replaces w/ something printable like "·" or "?" resp. "?"?
> Maybe in a different color to hint that this is a placeholder?
>
> Patrick Eigensatz wrote:
> I think the idea of (colored) placeholders is great! I've started to create an option in the configuration dialog, we could add an option for whitespace placeholders, too.
>
> Thomas Pfeiffer wrote:
> This is indeed one of the cases where having something configurable is a good idea. While hardly any "regular user" is likely to want to copy only whitespace, apparently this is an important feature for developers, so it should not be taken from them.
>
> It should be turned off by default, however, because presumably developers are more likely to hunt for the option to turn it on than regular users are to hunt for the option to turn it off.
>
> As for making whitespace placeholders configurable: That is too much. Either it is useful to have placeholders or it isn't, there isn't one group of people for whom it is useful and another for whom it isn't. Since the main usecase for copying only whitespace is in coding, where the actual number of whitespace characters often is relevant, it appears to make sense to have placeholders.
> I would not use a printable character as a placeholder, though, because then it won't be distinguishable from the actual character. Can't we maybe just use a different color for the whitespaces (but only in cases where there are only whitespaces)?
>
> Kai Uwe Broulik wrote:
> We could enable styledText for such cases and then use arbitrary html formatting for colors. However, I think there are even Unicode characters that look like blocks with "TAB" and similar written in them.
>
> Thomas Pfeiffer wrote:
> I'm fine with anything that isn't a regular character.
>
> Patrick Eigensatz wrote:
> I remember there is a programming language called "Whitespace" only consisting of space/tab/newline. Whitespace IDEs highlight those chars somehow. I think we might change the background color of a char, for example spaces are "marked" green and so on... (Using HTML formatting? I'm not sure what is possible here...) (The point to do this *only* where there are only whitespaces is important!)
>
> I'm currently trying to develop the configuration setting "Ignore whitespace characters" to but I'm new to Qt and KDE development in general.
>
> Thomas Pfeiffer wrote:
> I'd call it "Ignore selections that contain only whitespace", because we're not ignoring whitespaces completely.
>
> Thomas Lübking wrote:
> > I'm fine with anything that isn't a regular character.
>
> Oh, cool - RB screwed it.
>
> Run kcharselect and select "Symbole" and "Symbole für Steuerzeichen" (anybody around not german? =)
> There're special glyphs for non-printable characters. I added them to my former post, but RB apparently replaced them w/ nothing :-(
>
> eg. U+2424 (newline) and U+2420 (space)
>
> Patrick Eigensatz wrote:
> You're right on this one! ;-)
>
> Thomas Pfeiffer wrote:
> Okay, Patrick (or anyone else who can run Master), I'd like you to do something called "guerilla usability testing": Once the placeholder feature has been implemented, please do the following:
> Take a machine with Klipper open and a line with the placeholders in it to a few people who
> - are used to coding or writing a markup language
> - ideally are at least somewhat familiar with Klipper
> - are not not involved in this review request
> and ask them what they think they see there.
> If all of them at least _guess_ it's whitespace, we've won. If some of them think it's something else, we have to go back to the drawing board.
> Unicode actually gives us a few options here. In addition to the characters Thomas mentioned, we also have U+2423 (open box, graphic for space) and U+2422 (blank symbol, graphic for space). And if all of those fail, we can still try colors.
>
> Could you do that? We don't want to introduce something which only we think works, so this would be really helpful. It's also interesting/fun to do and doesn't cost much time.
> Thanks!
>
> Patrick Eigensatz wrote:
> Hi Thomas!
>
> Indeed! The test seems to be fun! U+2423 seems almost perfect for spaces!
> But as I told you, I'm new to Qt and I'm new to KDE development and I'm not sure
> if I can write all this code alone, but I hope to do so...
>
> Patrick Eigensatz wrote:
> I already run into some troubles reading the code. Inside the *Klipper* class, there seems to be the method *loadSettings()* respectively *saveSettings()*.
> They use functions from a namespace called *KlipperSettings*. But this namespace is nowhere defined. Often, a file called "klippersettings.h" is included,
> but in this git commit, this file does not exist...
>
> Thank you for your help :)
>
> Jeremy Whiting wrote:
> Patrick,
>
> First off, welcome to the community! To answer your question though, the klippersettings.h and it's matching .cpp file are autogenerated files from the .kcfg file. More information can be found here: https://techbase.kde.org/Development/Tutorials/Using_KConfig_XT You should be able to find them in your build folder somewhere.
>
> Heiko Tietze wrote:
> One option to show those charcters in dialogs is to use the regular expression \t (tab), \n (new line), and space as it. That's what Kate does at replace > 'escape sequences'.
>
> Kate and similar text editors show tabs by this 'much greater than' symbol ? (U+226B) in documents. No idea how Kate handles newline and spaces but Libreoffice, for instance, takes the usual pilcrow symbol (U+00B6) http://en.wikipedia.org/wiki/Pilcrow and a 'middle dot' U+00B7 for spaces (Wikipedia knows more subsitutes http://en.wikipedia.org/w/index.php?title=Whitespace_character&action=view§ion=4#Substitutes). Libreoffice applys an arrow for tabs, guess it's the 'halfwidth righwards arrow' U+FFEB (it's rather U+21E5 ? rightwards arrow to bar http://en.wikipedia.org/wiki/Tab_key#Unicode). Calligra might draw the arrow since its length depends on the tab width.
>
> Another option is to show the html/xml equivalents
which would be useful for people who regularly deal with that type of representation.
>
> To summarize RegEx and HTML are good for developers, visual replacements for people who are familiar with office suites. But unfortunately I do not have a favorite here, all have advantages and disadvantages. And clutter the tool with options makes no sense to me. However if you want to offer the option to show the whitespaces this selection could include the way it is represented (a menu with none, html style, regex style, office style).
>
> Last but not least I want to point out that there are much more non-printable characters. E.g. Arab has a couple of zero width white spaces. It could be a use case to type the letters first and add those spacers later. I'm pretty sure we will miss something.
>
> Martin Gräßlin wrote:
> html and regex have the disadvantage that one cannot know what one has now. What's the difference between I copied "\n" and I copied a newline? It's visually difficult to destinguish. Given that I think (U+00B6) and friends are the better solution for representing them visually.
>
> Patrick Eigensatz wrote:
> I think there is a problem, if we only replace a tab by '\t' and so on, we might write whitespace italic; Which, however, is not very nice
> if you copy for example idented code containing newlines because you would have both (italic '\n' and normal '\n') in the klipper history.
>
> I think the pilcrow symbol (never knew how this "Zeilenumbruchsanzeige" was really called), the arrow and the open box are good possibilities to represent
> those whitespace characters.
>
> @Jeremy: Thank you, I'll have a look at how to build the files from .kcfg file ;)
>
> Patrick Eigensatz wrote:
> Is this approach okay?
>
> Obviously, the first option "Ignore the clipboard if it contains only whitespace characters" would disable "Display whitespace characters using symbolic placeholders" and vice versa.
>
> 
>
> Heiko Tietze wrote:
> The checkbox captions do not meet the HIG. In particular you have to check something to disable it (rather uncheck by default and write "Show foo") and indent subordinate items (both notes are true as well for other items). However I'd still favor a menu here (has more flexibility, e.g. if html representation will be added as an alternative to symbolic placeholders, and eases the wall of checkboxes). Same for ignore selection and text selection; no idea about synchronization - all in all the dialog is not user friendly.
>
> Don't know how the full dialog looks like but please take also care of grouping. It seems as only the selection stuff is grouped.
>
> https://techbase.kde.org/Projects/Usability/HIG/Check_Box
> https://techbase.kde.org/Projects/Usability/HIG/Alignment
>
> Patrick Eigensatz wrote:
> Hi Heiko, thanks for your remarks on the HIG.
>
> The current (german) dialog in KDE 4.14.8 look like this:
> 
>
> So I need to rename the first option:
> "Ignore the clipboard if it contains only whitespace characters" -> "Allow history items to consist only of whitespaces"
>
> Thank you!
I'm still working on this... I still have to set the QT slots and I'm not quite sure if this code will run as expected.
However, here's an updated patch/diff and I'd really appreciate if you gave me some feedback. ;)
- Patrick
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123806/#review80423
-----------------------------------------------------------
On Mai 16, 2015, 11:44 vorm., Patrick Eigensatz wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123806/
> -----------------------------------------------------------
>
> (Updated Mai 16, 2015, 11:44 vorm.)
>
>
> Review request for kde-workspace, KDE Usability and Patrick Eigensatz.
>
>
> Bugs: 192922
> 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/20150516/8f0ff74d/attachment.htm>
More information about the kde-core-devel
mailing list