Version: (using KDE 3.5.8) Installed from: SuSE RPMs Select and copy A A those are two different entries but in Klipper history they look exactly the same (it took my a while to realize why I cannot login when I pasted the login as usual, then I found out that this time the space was added).
Confirmed for klipper in 4.2 trunk
From what application do you copy that string? Looks like this is this application's bug. I just observed the same wrong behavior when copying " A" from firefox. But it's just ok if i copy this string from any other app. So it's firefox which pastes wrong selection into clipboard. Can you confirm that?
Currently I don't have KDE4, but in KDE3.5.10 it was klipper fault. Besides, no app can influence the way klipper _shows_ data. I copied A I saw A I pasted it, I got A so the data are correct, displaying is not.
Please, can you answer my question? I asked not just for fun, but also because i'm trying to fix the bug :) From where do you copy this string? Just saying "it's klipper fault" doesn't help me a bit. Can you perhaps elaborate why you 100% sure it's klipper fault? Though i don't care much about that atm.I want to know from what app do you copy. If it's the same (wrong string) when you copy from konsole, kwrite, gedit, firefox, then it really might be a klipper fault. Please check all these apps and tell me the results. Thanks in advance.
app --> correct ---> klipper (*) --> correct --> app * -- showing is incorrect App has no influence on history at all. When I copy text A and text B, A and B is stored, managed by klipper. Just to double-test everything, KDE3.5.10 apps: konqueror kmail konsole amule akregator kftpgrabber opera And Dmitry, I didn't answered for fun or anything, I respect your time, and my previous answer was 100% accurate -- it takes only klipper to test the data storage vs. display.
Okay, so I'll recheck this once more for klipper KDE4, perhaps this is a bug in inserting into menu. I just found today that firefox sends wrong clipboard - that's for sure. Note that if this turns out to be KDE3 only bug, i'll close it as UNMAINTAINED, because that's what we do in KDE4 times :) Of course I'll do it only after i make sure it doesn't exist or fix it in KDE4's klipper. And sorry if i sounded offensive, I just found that just saying "it's klipper's fault" w/o answering my question isn't enough :) And fun is okay, really ;) It's all about that.
Ok, I found the reason if this behaviour. The thing is that klipper does some tricks to remove white space from copyied string and add "..." if necessary. That is needed because copied text may be very large, it can contain tabs, '\n' characters, a lot of spaces etc. So it just rips whitespace before inserting an item in the popup menu. That's why you don't see this space. But if you'll try to select & paste respective items, it will be the correct variant - with or without space respectively. So this is just a variant of user-friendly presentation. The data itself is not modified. I think this is sane. Though still might be confusing in cases like this. So I didn't decided whether i should just close this bug as INVALID or not :) I'll think some more about usecases and such
Dmitry thank you for the explanation but I already knew it (except for the internals), however it is not about usecases, but design. Klipper currently violates several of them: * WYSIWYG * principle of least surprise * data accuracy * data distinction (how user can tell the difference between "a" and "a"? -- one is really " a" and one is "a") In short user should see the data, it is absolute minimum for any reliable program -- midnight commander, kate, konsole, you name it. Klipper is not text processing system like tex, which processes data. Klipper should not process anything -- it is storage facility (very useful). The problem you described is displaying data in nice manner -- misleading user is not the key :-) I suggest to display special characters for non-printable characters and special characters for whitespaces as suffixes and prefixes. This way •hello hello hello•● you can easily say in first case you have space or tab before hello, in the third case you have tab or space at the end with some non-printable character at all after that (in unix system most likely -- LF). Now, what we would get all principles fullfilled.
PS. Color / underline could be used for special characters (additionally).
No, these symbols would be an overkill. What user needs from this menu is to be able to distinguish items. It's not a text editor, you don't need to know _exactly_ what the data is. You barely need to see an overall picture to understand what do you want to paste. And i'm sure that some novice users will be most probably scared when seeing something like "he•llo●my●●●dear•fr•en●d" than by missing space :) The only option here i could agree with is perhaps not removing whitespace from start of the string... The things you propose look to me like an overkill TBH :)
Dmitry, I repeat: " I suggest to display special characters for non-printable characters and special characters for whitespaces as SUFFIXES and PREFIXES" Your example would like this: he llo●my●●●dear fr en●d however for LF it would be more useful to provide multi-lines items, so I correct myself. So we would have he llo my dear fr en d However if you ask me personally for LF I would leave it up to user -- multiline or special character. With my PS it would be even nicer. _ denotes underlines not underscore he_llo_my___dear_fr_en_d and/or gray rectangles. But this is technical details -- the main point is to show in some way what data are stored, not hidding this information from user. > The only option here i could agree with is perhaps not removing whitespace > from start of the string... and the end :-) Anyway, there should be no stripping and klipper should provide visual indication for invisible characters -- that's my point. Otherwise it is only guessing what means what (I hope you agree with me that with stripping or/and no visuals you can only ensure about the real data by trial&error). For me it is nothing more frustrating that SEEING some text, selecting it, and getting something completely different -- see my original report :-)
Looks like you didn't read what I wrote :) This popup's menu purpose is not to show user what text is in clipboard precisely. Its purpose is to only make it possible for the user to _distinguish_ one entry form another. For that purpose seeing several letters at the beginning and at the end is more than enough. Putting some magical characters in a menu or making it contain items that span several lines will kill usability of this app. I'm sure that after average user will see this, the first thing he will do is file a bug saying "hey man what the hell klipper has done with my clipboard? what are this symbols?" Another point: klipper is out there for many years. If seeing the actual clipboard contents in a menu would be the most wanted thing for the users, I think it would be already implemented long ago :) So to conclude: i won't add this symbols. spaces at the beginning - perhaps. But nothing more.
> Its purpose is to only make it possible for the user to > _distinguish_ one entry form another. Ok. You said it yourself :-) > Putting some magical characters in a menu or making it contain > items that span several lines will kill usability of this app. When I am working with gimp usually I get two items per each menu and it does not kill anything. Besides it would be up to user -- show text as-is (multiline) or show it is as one line. > I'm > sure that after average user will see this, the first thing he will > do is file a bug saying "hey man what the hell klipper has done > with my clipboard? what are this symbols?" I differ in opinion :-). > Another point: klipper is out there for many years. If seeing the > actual clipboard contents in a menu would be the most wanted thing > for the users, I think it would be already implemented long ago :) False logic (but very popular) -- think: 1945, computers are not wanted, if they were they would be invented before. Nothing can exist before its own invention. > So to conclude: i won't add this symbols. spaces at the beginning - > perhaps. But nothing more. You said: " Its purpose is to only make it possible for the user to _distinguish_ one entry form another." so, I have 3 entries hello hello hello could you tell me which is which? This is task of distinguishing them -- if I remember correctly one is "hello" and two newlines, the other one is "hello " and the third one is "hello".
Case with 3 hello's is rather rare. Most time the klipper is used to paste different contents. I consider optimizing whole menu layout and presentation for this *rare* case (when almost similar entries are copied) to be a waste of time, really. And as i said this will scare most of the users (you're not among them ;))
> Case with 3 hello's is rather rare. Most time the > klipper is used to paste different contents. We are going into circles now: * if the content by definition is distinct then there is no need for distinguish it, right? * those three hello's are different "hello "!="hello" > I consider optimizing whole menu layout and presentation for this > *rare* case (when almost similar entries are copied) to be a waste > of time, really. Actually this is not the case -- the case is that I, user see one item "hello" (example) I select it and I get " hello " in result. And this is not rare for me, I use klipper all the time, and it is on the one hand useful, but on the other -- unreliable. Till I paste the item I cannot be sure what I have selected because klipper is oversmart. > And as i said this will scare most of the users (you're not among > them ;)) I think it is exaggeration. They will see one tiny dot at the beginning and they will be scared? Come on... Besides, you are mixing different things: * not-stripping non-printable characters * visual indication for non-printable chars The first one is a must for being reliable, the second could be solved by providing an option (Kate for example has something similar).
Well, what I see is that you don't see me :) Summary: This menu isn't there to show what _exact_ data klipper holds. It just helps you to remember what you copied previously. And it acts quite well in this role. So i won't argue to you anymore, you just don't listen. Speaking of me, I got your point and I think that it's a valid one, but it will suit only you, not other users. That's why I won't implement it. If you wish, feel free to, it's an opensource :)
> Summary: This menu isn't there to show what _exact_ data klipper > holds. It just helps you to remember what you copied previously. The funny thing the purpose of Klipper changes quite fast -- with each comment :-) Even with the last change -- helper in remembering the data -- it does not serve the purpose. > I got your point > and I think that it's a valid one, Ok. > but it will suit only you, not > other users. Let me guess -- because otherwise somebody would already reported it, right? ;-) Three sesame seeds: http://www.joelonsoftware.com/items/2007/09/11.html > That's why I won't implement it. > If you wish, feel free to, it's an opensource :) Fair enough -- however it would be much simpler from the start if you said it straight without backing up with odd theories what is the purpose of klipper (klipper is multi-item clipboard, not helper in remembering, helper in distinguishing, etc). Cheers,
Hehe. As I said, you don't read carefully. I didn't tell you that was the purpose of klipper. I told you the purpose of the popup menu. And it's purpose is to help you recall what items were previously copied. It does it by showing you start and end of the copied text, so you can distinguish one piece of text from another and remember it. And I didn't tell you "do it yourself" right away, because I tried to argue my thoughts. But you seem to have mindset like "throw away anything, push what I want". So I gave up :) I won't be surprised if your next comment will be just like previous ones: "you're all wrong, I'm all right". Well, ok :) I don't mind.
Putting weird symbols in the menu doesn't solve anything. But I rather think that the problem here is the menu itself. Allow me to park this until the menu is gone.
*** Bug 154347 has been marked as a duplicate of this bug. ***
Git commit 4fdfcded48f222a2aa1f8032142d8191f0624f5e by Kai Uwe Broulik. Committed on 17/05/2015 at 18:16. Pushed by broulik into branch 'master'. [klipper] Highlight leading and trailing whitespace in the plasmoid Leading and trailing spaces, tabs, and line-breaks are now highlighted in the theme's highlight color (blue in Breeze) and replaced by printable characters REVIEW: 123821 FIXED-IN: 5.4.0 M +21 -2 applets/clipboard/contents/ui/ClipboardItemDelegate.qml http://commits.kde.org/plasma-workspace/4fdfcded48f222a2aa1f8032142d8191f0624f5e