Please implement an "export all" option.

Sorry for the late reply to this feature request.

Could you please elaborate on the use case. I fail to see why one would want to export the clipboard history. And even if: what format should be used? What to do with binary data (e.g. images)? If we export using a specialized format I doubt it's of any use for anybody. If we don't introduce a format it would be rather useless content as it would even miss the meta data on where one entry ends and the next one starts.

As a matter of fact: klipper saves it's history to a file in a custom format.

*** Bug 439143 has been marked as a duplicate of this bug. ***

For simple backup usecases, you can already make a copy of ~/.local/share/klipper/history2.lst
Did you want something more than that? If so, what feature do you want and what is a usecase for it?

(In reply to Martin Flöser from comment #2)
> Sorry for the late reply to this feature request.
> 
> Could you please elaborate on the use case. I fail to see why one would want
> to export the clipboard history. And even if: what format should be used?
> What to do with binary data (e.g. images)? If we export using a specialized
> format I doubt it's of any use for anybody. If we don't introduce a format
> it would be rather useless content as it would even miss the meta data on
> where one entry ends and the next one starts.
> 
> As a matter of fact: klipper saves it's history to a file in a custom format.

In my case the idea is to be able to get all of the text at once, so that I can use all of the text at once. For example importing a bunch of links into a separate program. As things stands you have to go through each entry one by one. My current workaround is this simple bash script to call klipper from the command line using qdbus and print each entry to stdout, so that I can redirect it to a file or wherever else.

#!/bin/bash
# Author: koffeinfriedhof
# From forum.kde.org
# Modified by me

# the list postition counter (messages counter)
n=0

# must not be "" !
f="I am the placeholder for each line in klipper"

# loop through all entries using dbus
while [ 1 ]; do
f="$(qdbus org.kde.klipper /klipper getClipboardHistoryItem $n)"

# if "$f" has zero length (empty), stop
if [ -z "$f" ]; then break; fi

# print each entry
echo "$f"

# increase counter
n=$((++n))
done

(In reply to Noah Davis from comment #4)
> For simple backup usecases, you can already make a copy of
> ~/.local/share/klipper/history2.lst
> Did you want something more than that? If so, what feature do you want and
> what is a usecase for it?

I meant to respond to you, but accidentally replied to the wrong person, please read my above reply to Martin Flöser

While we can back up the file, it is saved in a custom format, so it is hard to do much with it. The goal is to access the contents of the clipboard outside of klipper. I have posted a work around, but the request is for there to be a button for it.

It's still not exactly clear how to handle the export all feature when things like raw images and file urls (what happens when you copy a file) are mixed in. I suppose file urls could simply be processed the same as any other URLs into a line of text. The raw images might just have to be ignored or saved and then converted to file URLs. Raw images are normally stored as binary data in the clipboard, which take up a lot of space and are not human readable.

> In my case the idea is to be able to get all of the text at once, so that I can use all of the text at once. For example importing a bunch of links into a separate program. As things stands you have to go through each entry one by one. My current workaround is this simple bash script to call klipper from the command line using qdbus and print each entry to stdout, so that I can redirect it to a file or wherever else.

How do you want to use this data? Do you simply want to process it with other terminal commands? Copy and paste it all at once to different documents? Share a file containing the text?

Do you need it in the GUI or would a `klipper --export-text` command that sends the text (excluding raw images) to stdout suffice?

It's also worth considering that what kind of output is useful for users may depend on the usecase. Do you need each entry in the clipboard to be distinct in the output or is it OK if it's all mixed together in one plain text output? The former might require a data format like XML or JSON so you can see where an entry starts and ends. The latter is more human readable, but since entries can be multi-line text, you won't always know whether a new line is part of the same entry.

I suppose if someone needed a more specialized output with distinct entries, we could have an `--export-xml` or `--export-json` option.

Looks like commit a5e40fe5d81040e0a2297d878cd887d5a2d49702 in plasma-workspace removed the `klipper` executable, so we'd need to either reintroduce it, use DBus commands, have something in the GUI or some other alternative.

(In reply to Noah Davis from comment #11)
> Looks like commit a5e40fe5d81040e0a2297d878cd887d5a2d49702 in
> plasma-workspace removed the `klipper` executable, so we'd need to either
> reintroduce it, use DBus commands, have something in the GUI or some other
> alternative.

I'm already using dbus as I posted in the script. This does what I want, so far, but I am only using it for text and had not considered images or file urls. In my case I do not need images or file urls, only text. I don't explicitly need it in the gui because I have already come up with my own solution. Having a gui option to export only the text would be a nice to have. Assuming that my solution continues to work in the future. As for distinct or mixed up. I'm not exactly sure what you mean. What I was thinking was you click a button and all text entries are saved to a file in a location you choose and each text entry in the clipboard becomes a newline in the file.

(In reply to Dashon from comment #12)
> As for distinct or mixed up. I'm not exactly sure what you mean. What I was thinking was you click a button and all text entries are saved to a file in a location you choose and each text entry in the clipboard becomes a newline in the file.

A single clipboard entry can contain multi-line text. If you wanted to just share a human readable file or a clipboard that only contains one kind of text per line, no matter how many entries, that doesn't necessarily matter. If you wanted to process the data, each entry having its own line wouldn't necessarily make each entry distinct in the file. You wouldn't know if an entry containing 3 lines would be 3 entries or 1.

(In reply to Noah Davis from comment #13)
> (In reply to Dashon from comment #12)
> > As for distinct or mixed up. I'm not exactly sure what you mean. What I was thinking was you click a button and all text entries are saved to a file in a location you choose and each text entry in the clipboard becomes a newline in the file.
> 
> A single clipboard entry can contain multi-line text. If you wanted to just
> share a human readable file or a clipboard that only contains one kind of
> text per line, no matter how many entries, that doesn't necessarily matter.
> If you wanted to process the data, each entry having its own line wouldn't
> necessarily make each entry distinct in the file. You wouldn't know if an
> entry containing 3 lines would be 3 entries or 1.

Ok, I understand. For me, it does not need to be distinct as long as each entry is a newline and multiline entries stay in tact. It does not matter if I know that multiple lines were 1 entry or three. It just needs to be readable.