20

Hy is possible to add to great kde clipboard manager option - mount to point (folder) ? it was by very usefull option - when i copy to clipboard photo i want send it so must save and select from saved place - i think is asy make folder witch clipboard content and then i go - select file -> /clipboard or other place and get photo or text. thanks

Would the pastebin widget work for you? you would just drag the image to the plasmoid and it would be sent to the defined image host (there's only a few sites available, I use simplest-image-hosting.net)

Another option is to open the image in Gwenview and export the image to one of many available sites

Update: I looked and can't find where images are stored, they may be stored in a buffer instead of a folder. From http://userbase.kde.org/Klipper "The item you copied last will still be the default one to be pasted, but others will have been stored in a buffer"

i use pastebin but this is other way, i must paste link to some file and share to world,

select file from mounted clipboad to example attach to mail - i think this is nice,

where clipboard manager store data ?mayby this is folder and aesy is possible to link it to /tmp/clipboard or other place.

thanks for reply

This would probably be best as a kio slave (virtual folder) rather than a real folder.

but i think like in amiga ram disk - is better- clipboard save files/text so why we can use it in browse files.
they have it but dont share realy

but yes it can by exaple in /tmp/clipboard/ so each aplication have acces without problems (i think many virtuals foler can make problems for some aplications, good idea is put in in clasic folder structure)

Hi,
grekpg, that is a great idea you gave.

However, I agree with TheBlackCat that this feature should be implemented as a kio-slave. That system is a genuine feature that deserves to be supported 'cause it is elegant, lightweight and mighty at the same time.
The advantage of using that approach: you dont need additional file operations (storing / copying files), you don't have to decide what types of files to generate and, most important, you don't have to clean up !

Certainly, as mentioned in the last comment by grekpg, using a classical folder in the file system might enable more applications to access the contents using file operations. Actually all non-kde-applications, since every kde application is already able to access content using kio-slaves.
But there might be a way to implement a bridge between those two worlds, the primitive, file system only enabled 'normal' applications and the kde world with its more advanced kio-slave mechanism: a small helper (kde system daemon) that mounts the kio-slave-file-space in the physical file system, maybe using fuse. Most likely an additional control center module makes sense to control which slave urls should be mounted where.

Designing such kio-slave means we can have an additional entry in the places panel in all applications, especially the file operations dialog. And this without leaving stale files in the physical file system.
This is great.

So mayby sombady who know klipper can do it, i think its easy beacose this files exists in some place (mayby default - /home/user/klipper/ witch self destroy like /tmp managed by klipper) - (kliper store witch reboot secure so only share - mount in kio-slaves (i dont know what is it) or other way - effect is important only when user copy file see it in some place in folder structure, when copy text ctrl+c see it as txt file or somethink like that - most important to see copied files so nothink to convert only share it in folder structure.

I doubt that the content of klipper is stored as separate files on disk.
I expect to find a single file holding all entries in klipper, files are probably coded as URIs.

It certainly is a better idea to access clipper via dbus instead of digging around in its internal storage area. I did somehing with dbus and klipper in a small way some two years ago, but only on a script level. Might be interesting to dig deeper, but I am not a kde programmer.

So we are talking about a kio slave that kind of replicates parts of the klipper dbus interface via the file system. Operations would be push, pop, remove, browse and probably something like randaom access, I guess. Not sure if it is possible to keep the order of entries as seen in klipper, since access via a kio slave only allows ordering in those ways offered by the file operations... Although it might be possible to fake modification times.

We'll see

"I expect to find a single file holding all entries in klipper, files are probably coded as URIs."

Not only local files are copied. As we see in usercase "when i copy to clipboard photo [on browser] i want send it so must save and select from saved place"

One more vote for kio-slave.

i dont know if it is the same situation but i'd like to have an option when i open an image in gwenview to be able to share it. Now i can share only things saved localy. So, if it is the case, i vote yes for this feature

****, I just press Ctrl-V

If I understand right you think along the lines of keeping a stash of pictures in the klipper history and copying them all at once to a new location at once?

If so I think this might be already possible with a custom service menu entry in Dolphin althought I don't know too much about this part. You can access the contents of klipper's history with a qdbus command:

qdbus org.kde.klipper /klipper getClipboardHistoryMenu

If you copied a file into clipper, it will display as

file:///path/file.jpg

You could loop through these entries, check whether it matches a regex and is a valid file and maybe check the file ending and paste it at the current folder in dolphin. It will however be limited to the length of klippers history.

Ok,
as mentioned I am a complete newbie to KDE and Qt programming, so this took me a while

[updated 2001-07-26]
Removed the link to the sneak-preview tar ball. See the link to release 0.1 in the next comment.
[/updated]
I develop and test under opensuse-11.4, though other distributions should work as well.
It requires an up-to-date KDE>=4.6, I did not want to bother with version differences right now.
There are very few dependencies, so this requirement might drop to something like KDE>=4.2 in future.
The tar ball holds a short README, but there is mostly no documentation contained.
Standard install instructions apply: create build; cd build; cmake ..
A few RPMs will follow when I come around to setup some simple web page for this stuff to live in.

Once installed you can try a "klipper:/" or "clipboard:/" wherever you can enter URLs in KDE, for example dolphin, konqui, and especially the file open dialogs. There are quite a couple of issues (remember, this is a pre-pre-release), but it might give an idea where I am heading. Opening "files" works in general, URL-based open attempts show a short hang for a couple of secs. Some issue with signals and slots. You can delete entries (like random access) and copy something to a clipboard (drag&drop).
Currently only one single type of clipboard is supported: klipper. It is detected and not started when it does not run. I would like to add more types of clipboards, especially online clipboards. I could imaging that this would actually be good for something then: syncing clipboards

I will setup a few primitive pages about that stuff during the coming days, but I want to keep this small. In the end, this is just a coding experiment for me.

I am happy to receive feedback and I certainly will try to integrate all contributions.

Apart from that:
Have fun !

I just released version 0.1:
http://kde-apps.org/content/show.php?content=143976

It has major improvements over the sneak-preview mentioned in the last comment.
Some things actually work, though issues remain.