The difficult art of explaning
Posted by Esben Mose Hansen
Sometimes, explaining abstract concepts concisely in an easy-to-understand language is everything but simple. Consider Klipper's config dialog as I recently adjusted it to look
Now, if you already know the difference between selection and primary when talking about the X clipboard, the radio button and the check box are both pretty clear, at least in my opinion. If not, I hope that the verbose what-is text might bridge the confusion, but I am not so sure. So, dear readers, do any of you understand what I'm trying to say? Can some of it be clearer? If you do not understand what I'm going on about, see below, where I'll try to explain at length what selection and primary is all about.
X does not have one clipboard but several clipboards, of which 2 are actually commonly used. They are often named after their XAtoms, "SELECTION" and "PRIMARY". Traditionally, X has supported highlightning an area with the mouse and then middle-clicking to paste this selection elsewhere. This is done via the SELECTION clipboard. Practically speaking, that means that if an area is selected in well-behaved X program XAPP, it will notify X that that XAPP now has the SELECTION. Thus, when the middle mouse button is clicked somewhere, the clicked application can ask X "give me the contents of SELECTION", and X can send the request on to XAPP, which can then send back the answer. Reasonable simple, even if I did leave out all the details about formats. Completely independent of this, X also has a clipboard like known in most other desktop environments, in which the user, usually by a keystroke like ctrl-C or a menu selection makes the application tell X "I now have the PRIMARY", and when the user selects paste somewhere, the content of the PRIMARY is pasted via. the same mechanism as the SELECTION above.
Now, many people find this to be confusing and/or annoying in practice. Keeping track of 2 different clipboards requires the user to remember "Did I just select it or did I copy it to the clipboard? If I selected it, I have to grab my mouse and use the middle button, otherwise I will have to press ctrl-V to paste." Thus, Klipper provide the ability to synchronize the PRIMARY and the SELECTION, ensuring that whatever method the user used to copy to the clipboard(s), all methods works for pasting. For the traditionalists, the option to keep the clipboards separate is also provided.
So what is this "ignore selection" all about? Well, if you use the separate option above, the clipboard history will still be populated from the mouse selection, and Klipper's actions will still be triggered. Some people do not want this: they wish Klipper to keep its endearing hands off SELECTION and only act on PRIMARY. So that is the last option. This will make the clipboard be almost completely like the Windows clipboard, except that you can still accidentally paste the mouse selection by pressing the middle mouse button, which is an X thing through and through.
Again, I'd value people's comments, and I do believe the comment system is actually working now. Otherwise, please direct comments to me by email.
PS: Now at 98 bugs. They seem to come in as quickly as I can fix them.
I would thank you for you work in the Klipper :)
and I want thank you one more for putting a sane defaults. Frankly I never open the configure dialog !
I agree that the “ignore” behavior is the best default (and possibly best all-around choice) here.
I also can’t imagine how anybody thought the previous configuration screen was acceptable. What does it mean to ignore the selection, but synchronize it with the clipboard? The new layout, with “ignore” as a radio button, is much better.
Thank you for this. I have been aware for some time that I didn’t understand the implications of those options. This post has made it very clear. Now all I have to do is decide how to get it into userbase - link to this blog, or reproducing the text. Please let me know if you have any preference
I think I still don’t understand completely what these options do.
Wouldn’t this explanation be easier?
Option 1 - Have one clipboard. To copy select something. To paste press Ctrl-V or use middle mouse.
Option 2 - Like option 3 (read below) but actions are also triggered from clipboard one.
Option 3 - Have 2 clipboards. To copy to clipboard one just select something. To paste from clipboard one press middle mouse. To copy to clipboard two press Ctrl-C. To paste from clipboard two press Ctrl-V. Actions are only triggered on clipboard two.
Maybe you can put two sections, “configure clipboard one”, “configure clipboard two” and populate each section with options. Then make sure the user knows how to copy/paste into/from each clipboard… To me, as a user, I only care of how many clipboards are and how I copy/paste in each one.
But I’m not an usability expert, so all this could be rubbish.
Looking great. I think the only way to simplify the config dialog even more is separating all the unrelated options onto separate pages. Or grouping them, putting more important options higher. For example:
–General Config– [] prevent empty clipboard history size [__] [] save clipboard HISTORY on exit timeout for active popups [__] [] replay action selected from history [] popup history menu at mouse cusor
–Clipboard Content– [] remove whitespaces [] do not copy images [] copy only text selected
–Selection Handling– () merge clipboard and selection in one single history () keep clipboard and selection separate () ignore selection completely
Thanks alot for working on klipper!
I can understand it, although I am curious what the difference is between “Ignore Images” and “Text Selection Only”.
One suggestion, though. Personally I think of “synchronize” as a two-way action, with object a being made the same as object b and object b being made the same as object a. As best as I can tell, that is not what is happening here. The selection is being put in the clipboard, but the clipboard is not being put in the selection. I would re-label the first radio button as “store selection to clipboard” or “put collection in clipboard” or something along those lines. Besides being, in my opinion, a better description, it is also shorter, less verbose, and easier to read. For me at least, even though I know what the selection is, I wouldn’t know what “synchronize contents of the clipboard and the selection” means. I could probably figure out based on the other two options, but it would not be immediately clear primarily because of the word “synchronize”.
I would also change “clipboard/selection behavior” to just “selection behavior”. This is the klipper configuration, people should know they are dealing with the clipboard already so spelling it out there is redundant in my opinion.
eww, looks like single line breaks got removed in my previous post. Hope you can still see how I intended to reorganize and group the config dialog.
Is there any way to just disable the selection completely? No middle-click paste at all? I know this is what I really wanted when I first migrated from Windows – I had acquired a habit of just selecting things and randomly middle clicking everywhere out of, I guess, boredom, a kind of virtual fidgeting, and it was annoying as hell when it randomly ended up pasting and triggering various things (when you “paste” into something that isn’t a text box).
Of course, now that I’ve been forced to adjust to it I appreciate the efficiency and wouldn’t give it up, but it can really be jarring at first.
Hmm, well, the whole goal of klipper still isn’t immediately clear. The config-dialogue still assumes the user knows what klipper is all about. It manages a clipboard-history, can add actions to selections, and can configure how to handle the primary clipboard and the selection. Making that clear somewhere should help.
Perhaps some text like: “There are two clipboards: the primary one, to which you can copy and paste with CTRL-C, CTRL-v (or the context-menu), and the selection, which allows you to paste that what you have selected with the mouse, with the middle mouse button.”
Perhaps it’ll be best to split it up in 2 parts: one for the selection, and one for the primary clipboard You could also maintain 2 separate histories…
I’d move “Remove whitespace…” and “Replay actions…” to the actions-section.
I’d also rename some stuff:
“Save clipboard contents on exit” > “Save history on exit” “Prevent empty clipboard” > “Don’t clear clipboard when an application exits (or the other way around)”
“Synchronize contents…” > “Add selections to the primary clipboard” “Separate clipboard…” > “Keep the primary clipboard and the selection separate, but add selections to Klipper’s history” “Ignore selection” > “Don’t add selections to history”
I agree that renaming some of the other options would also be in order, as well as moving them around. I will save that for another post, though.
@TheBlackCat: Klipper really does synchronize primary and selection. What made you think otherwise? I’d like to clear that up, at least. The selection/clipboard was an attempt to write “selection and primary” in an understandable way, obviously I will have to rethink that. Perhaps I really should just write selection.
A lot of you have suggested changing the clipboard handling itself (e.g, only have one clipboard). That is really not possibly for Klipper, you would have to change X. All Klipper can do is force the 2 main clipboards to be the same at all times by copying between them.
@laurencevde I see what you are saying, but I don’t really think the config dialog is the right place to explain what Klipper is about. Indeed, most applications don’t explain what they themselves do, except in the manual.
@David: Maybe, except that I don’t want to bring actions into this. Maybe I could substitute history for actions, though.
By the way, I use the option of synchronizing the contents of clipboard and selection, and in KDE 4 (at least in recent releases) it’s not so reliable. I was going to submit a bug report for months, but I still can’t figure out when does it work and when it doesn’t.
Those 3 options (“synchronized”, “separate” and “ignore”) are variations on “Synchronize to clipboard” and “Save in clipboards history”, so why not just change the “Clipboard/selection Behavior” to “Selection Behavior”, put in there 2 check boxes and your done.
[ Selection Behavior ]
(x) Synchronize to clipboard (x) Save in clipboards history
Same thing, but more understandable?
Hey that looks really great. Would it be possible to handle this “except that you can still accidentally paste the mouse selection by pressing the middle mouse button, which is an X thing through and through.” also via Klipper? Meaning, I do not like the extra clipboard at all. Could there be an option in Klipper to turn this off too?
@djape: What would it mean if “save in clipboard history” was off but “synchronize” was on? It would be weird if clipboard contents were not available in the history because they had been automatically copied. But I like your “save in clipboard’s history. So maybe we
I have inverted the options to sort of “build up”, so that only one concept is introduced at the time.
@Mark Unfortunately, there is nothing Klipper can do to achieve this. It would have to be implemented in both X and the toolkits.
“Unfortunately, there is nothing Klipper can do to achieve this. It would have to be implemented in both X and the toolkits.”
Couldn’t it be hacked by proactively setting the selection to nothing whenever anything got added to it? (Not saying it’s necessarily a good idea – theoretical question.)
“Klipper really does synchronize primary and selection. What made you think otherwise? I’d like to clear that up, at least. ”
If you select something, the contents of the selection will go into the clipboard, but the contents of the clipboard will never go into the selection (because the very act of selecting it overwrites the clipboard). When I think of synchronizing, I think of, say, synchronizing your cell phone’s address book with your computer. Changes in the cell phone address book go into the computer, and changes in the computer address book will go into the cell phone. Pretty much every synchronization program I can think of does this sort of two-way activity. You can force it to go one way, but I just don’t think of something that always goes one way as being synchronization. That may just be me, though.
@TheBlackCat: uh? when I copy text using ctrl-c or pick a history item from klipper I’m perfectly able to paste it using both ctrl-v and middle click. It’s already being synchronized in both ways.
@illissius: I don’t know if this actually happens, but since the selection is an actual selection emptying it may cause losing the selection itself as well in some apps. So if this guess is correct your suggestion may lead to some curious behavior where the user tries to select some text and that selection instantly disappears again, causing an endless loop when the user tries to select it again. Esben may be able to shed some light and correct me.
“What would it mean if “save in clipboard history” was off but “synchronize” was on?”
Didn’t realize before that this would add 4th case scenario. Now that I do, it could be really useful. It would avoid clutter in history when synchronized and editing lots of text files (developers, writers).
“It would be weird if clipboard contents were not available in the history because they had been automatically copied.”
You could make current selection appear in clipboards history as firsts and selected, but it is not saved for later use (lost on another selection or copy).
Like your “build up” solution, much better than before. However, I still believe that check boxes are a better solution and will be more understandable.
[ example radio buttons ] o don’t do first option o do first option o do first option and also do second option
[ example check boxes ] x do first option x do second option
@djape If I go that route, I think I will disable the 4th option. It is simply too strange, and Klipper’s buglist would get overrun with bug reports about dataloss. Still, perhaps 2 checkboxes really are better. Thank you for your input, you’ve certainly made me think.
@illissius If Klipper did that, every time you select something the selection would disappear (meaning the highlight would be gone). I know this because Klipper once did this due to a bug…
That config section has been bugging me for a long time. Happy to see it improve ;)
“when I copy text using ctrl-c or pick a history item from klipper I’m perfectly able to paste it using both ctrl-v and middle click. It’s already being synchronized in both ways.”
The selection still isn’t being changed. And you are capable of pasting into a selection whether synchronization is on or off.
@TheBlackCat The clipboard really is copied to the selection (and vica versa). I admit not many programs in practice put text in the clipboard before they put it in the selection, but it is true nonetheless. If it doesn’t work, it is a bug.