Description: Overview: kio-clipboard implements kio-slaves, protocols for KDEs io system. It makes the content of clipboards available inside file management. That means you can access the clipboards entries using standard file dialogs like 'File open' or 'Save File', you even can use a file browser and access entries. In general you can use the slaves wherever you can use an URL inside KDE to get access to the clipboards content. There are no temporary file generated.
Motivation: Now we all agree that this appears more like a proof of concept. At first glance a real value in daily use seems hard to spot. After all why not simply use ctrl-c & ctrl-v ? Or even just left and middle click with something mouse like, when working under Linux and alike ? Actually this project is just an experiment for myself to learn a little about kde programming, Qt features and to get back into c++ basics after a long period of using other environments. However on second glance one might spot situations where this becomes interesting: - Imagine surfing the web, you copy the URLs of say 10 images to your clipboard. Now instead of downloading them all in advance or opening one by one using "file open">paste URL>open you could fire dolphin, select klipper amongst the predefined 'places' in the left panel, select the 10 URLs at once and chose "open with KolourPaint". - This is just a first glimpse that implements support for only one single clipboard application: klipper. Preparations are done and it would be fun to support additional clipboards. Things get interesting when we talk about remote clipboards, online services or even the clipboard on your colleagues system who works on the same project with you. This would make data exchange really easy... - Following this thought it turns out that this could easily act as a simple and general API to several clipboards (paste bins). Sharing information from within an application ? Just "Save to clipboard", select one and that's it ! Not API to implement, nothing. - Who spots the next situation where this might come in handy ?
Download: There are a number of packages provided below, these links are easiest to use. You can browse the source repository online: http://svn.christian-reiner.info/web/wsvn/kio-clipboard
Usage: Just enter "clipboard:/" or "klipper:/" in the location bar of for example dolphin or a "File open" dialog. * "klipper:/": This slave implements access to the standard clipboard utility under KDE4, called 'klipper'. Communication with klipper is done via its DBus interface, this makes it (relatively) future safe. * "clipboard:/": This protocol offers something like a "meta slave". It shows a kind of virtual folder where all available clipboards are offered. Each clipboard appears as a classical folder, standard file operations are supported as far as they make sense. The specific operations that might be available depend on the clipboard accessed.
State: This is an early and definitely buggy release. There are some issues with actions offered in file managers. A refresh of listings in file managers does not work automatically. You have to refresh manually after most actions that change the clipboards content, for example after deleting an item. There are currently no clipboards supported besides 'klipper' :-( Since this is my very first KDE implementation please don't bash me for this stuff :-)
Roadmap: Future versions might add further clipboard types. Future versions might also be able to access remote (non-local) clipboards, the current version is limited to the local (current) desktop session.
News: The current version 0.2.5 is (hopefully) the last one before 0.3 which will bring support to the first online clipboard.
Feedback: I am more than happy to receive feedback or even get assistance in a number of issues. Please do not hesitate ! Also, someone experienced with Fedora and Mandriva would be a great help, I fail to generate packages for those distributions in OBS.Last changelog:
* Sat Aug 20 2011 Christian Reiner: version 0.2.5 - explicit specification of (virtual) file access rights and datetimes in nodes and clipboard folders - - that does not really control or restrict anything, it is (at least for local clipboards) an optical aspect only * Fri Aug 19 2011 Christian Reiner: version 0.2.4 - a number of internal reorganizations as preparation for version 0.3 integrating further clipboard applications/services - removed caching of entry payloads in memory out of scalability interests - dropped 'delete' action, this did not really make sense for clipboards - first introduction of a shared memory cache between separate slave processes - serialization feature for node wrapper objects, required for later persistent storage of clipboard entries between sessions - convenience improvements by higher abstraction of node lists * Wed Aug 10 2011 Christian Reiner: version 0.2.3 - enhanced mimetype detection for text based clipboard entries - detection of a few special types of text entries declared as "code" - simplified setup up of internal DBus clients - fixed cardinality of numeric index in displayed entry names to honor the clipboards size * Sun Aug 07 2011 Christian Reiner: version 0.2.2 - new structure for source file collection - slightly optimized icons by usage of overlays (for KDE>=4.5) - fixed 'delete item' action not to delete the target file pointed to (!) - preparations for translation (i18n) - implementation of the 'copyToFile' feature for protocols - implementation of the 'copyFromFile' feature for protocols - -for human readable files the content will copied to the clipboard instead of the URL or path - - for all other files or files that exceed the clipboard entries size limit a linking of the URL/path is offered instead - - the user can chose to accept or cancel * Sat Jul 30 2011 Christian Reiner: version 0.2.1 - changed technical names of virtual nodes from a numeric index to a check sum - - this fixes addressing the wrong node after changes to the clipboard that were not reflected in an embedding application - additional content semantics 'Empty', since such content is not really 'Text' * Fri Jul 29 2011 Christian Reiner: version 0.2.0 - complete rewrite of the internal storage structure - fixed display name of clipboard folders not to vanish when being clicked * Tue Jul 27 2011 Christian Reiner: version 0.1 - initial (and buggy) release - publication on kde-apps.org
I wrote the original version for 3.x and the benefits where being able to upload a file directly to the internet from the clipboard and being able to pick the mime type of the file you wished to save from the clipboard
In Dolphin I get a listing of what looks like long hex strings. If I hover over the entry I either see an actual text string or I see what you show in your images ([2]URL://..............)
http://simplest-image-hosting.net/png-0-screen-20111204-064726
running KDE 4.8 beta1
Thanks for the feedback.
As you probably guesed I currently dont follow this experiment any more, though extensions as described might be useful and interesting. Anyway, since I started this as a learning case I am curious myself what the problem is. So let's see...
Quote:
running KDE 4.8 beta1
I don't (yet) use KDE-4.8 myself and have no such system around. So I have to ask for a little help from your side.
Quote:
In Dolphin I get a listing of what looks like long hex strings. If I hover over the entry I either see an actual text string or I see what you show in your images ([2]URL://..............)
http://simplest-image-hosting.net/png-0-screen-20111204-064726
Hm, from what I can see we have this situation:
The plugin works, extracts and publishes the klipper entries as expected, except for one single details: the 'DisplayName'. This is the token inside the UDSEntry that entries are actually named as for example in dolphin. It appears as if other tokens are fine, since you appear to see different, well defined file types and apparently the 'Comment' tokens are correct too. If you can open entries as expected then it seems the problem is only in the DisplayName token.
Since the DisplayName is constructed from the same data as other tokens I suggest there is no general problem in retrieving or storing the data, but in the way kio-clipboard constructs the UDSEntry.
My guess is, that there is an incompatibility between the implementation of the UDSEntry class between KDE-4.8 and earlier versions. The class keeps the tokens in a data structure, single tokens are addressed using bitfields. So most likely those bitfields have changed with KDE-4.8.
Question: are you using a precompiled binary from my repository or did you compile it yourself ?
In case of a precompiled binary please have a try with the packages you find in this repository I just set up. It builds the application directly against the unstable KDE-4.8 as available in OBS:
http://download.opensuse.org/repositories/home:/arkascha:/KDE-4.8/
If this does not solve the issue or you use a self compiled version we need to dig a little deeper. The attempt above was only a long shot from my side :-)
Please follow these instructions and post a link to the resulting debug output file posted to a pastbin:
1.) close all instances of dolphin and other applications that might currently use the slave (kio-clipboard).
2.) re-check with a ps aux|grep kio-clipboard, there must be no instances left.
3.) start 'kdebugdialog', deselect all check marks first, after that check the two marks before "kio_clipboard" and "kio_klipper", you can use the 'Search' field at the top for this
4.) in a terminal ("konsole") follow these steps:
4.a) enter: export KDE_FORK_SLAVES=true (and press return)
4.b) enter: dolphin > kio-clipboard.debug 2>&1 (dolphin opens with this)
4.c) in 'dolphin' open the clipboard url and enter the 'klipper' folder, open a random item and close it again
4.d) close dolphin again
4.e) upload the generated debug dump file 'kio-clipboard.debug' to a pastbin
4.f) publish the pastebin url here along with any additional information you might want to give
Thanks for the assistance !
According to your signature you are using openSUE 12.1 on an 64 bit system.
Question: which source package did you use for the build ? tag 0.2.5, branch 0.2 or the trunk ?
Sorry for the empty KDE-4.8 repository.
The packages were build successfully, but apparently before publishing 'em OBS decided to rebuild KDE-4.8beta1 and this currently blocks my packages. Takes a little while, I guess.
Thanks for the debug output you generated.
From this I learn that the 'DisplayName' is set correctly. The hashes ("hex strings") you see as item names are indeed used internally to identify an item when selected, for example by a double click. I cannot use the displayed name since that one must not be unique neccessarily.
Whyever, your dolphin appears to show the technical names of items instead of the specified (and correct) display names.
I will ask upstream if there is a current regression in KDE-4.8beta, otherwise I have to build a virtual appliance running that kde version to be able to track down that issue. Will take a little while, sorry.
=> I will come back to you.
Ok, just as I suspected this is indeed a regression in KDE-4.8beta1 and not a bug in kio-clipboard.
KDE bugzilla:
http://bugs.kde.org/287472
http://bugs.kde.org/287139
So sorry for the inconvenience, but all we can do is wait. The issue will fix itself.
Sebatian pushed a fix to this on 25.11.2011, I hope this is part of beta2 scheduled to be published on 07.12.2011.
much better in 4.8rc2 (http://simplest-image-hosting.net/png-0-screen-20111211-062238)
2 issues (?)
- does file names have to have "%20" used for spaces
- in my minimal testing the klipper folder need to be reloaded for the new items to be displayed, and changing folders then going back to the klipp folder does not display new entries either only a reload will
thanks,
Glad that bug got corrected.
I guess you are using KDE-4.8beta2 now ? KDE-4.8rc2 is announced for Jan 2012 AFAIK.
> - does file names have to have "%20" used for spaces
Hm, didn't think about that before...
Fast reply would be "yes", this has to be like this 'cause the entry holds a url, and a space in an url is not valid. There are technical limitations as to what chars can be contained in a valid url, everything else has to be encoded. Without such encoding many protocols would choke out errors upon such url and/or lead to unwanted results. The "percent encoding" you see is just one way of encoding, there are others (but none preserves a blank/space). However in certain situations it makes sense to show the unencoded url, especially when visualizing a url to humans. But there is an aspect we have to consider here:
The encoding is NOT done by kio-clipboard. The encoding is done by whatever component that copied the url to klipper in the first place. Open klipper, you will see that it holds the encoded url as entry. All that kio-clipboard does is to cite the entries of klipper, it does not alter their content. It might be technical possible to "unencode" such entry, but I am currently not sure if this is desireable.
Let me think about it !
Or, give me a reason why you think this should be changed.
> - [...] the klipper folder need to be reloaded for the new items to be displayed
Unfortunately that is true. The fact is already documented in the contained TODO file. I have not yet found a way to ge around this.
The reason is simple: the kio system provides absolutely no mean to react on changes and trigger a refresh of a view for "remote protocols". That is for protocols not considered local. So whatever kio-clipboard tries, however loud and often it shouts: refresh the view!, the embedding application simply will not see that. So a manual refresh is currently the only way, sadly.
As long as I dont know a way around this general limitation I see no way to change that behaviour. Sorry for the inconvenience. Maybe someone has a suggestion...
sorry I meant beta2
"%20" used for spaces - I have no valid argument other than esthetics's (not a very valid argument), not understanding url coding standards I was not aware of the need
reload - apologies, did not read todo but did read "road map" and "state", and in "state" it reads to me that refresh is only an issue after deleting an item
thanks,
Hello,
> "%20" used for spaces - I have no valid argument other than esthetics's (not a very
> valid argument), not understanding url coding standards I was not aware of the need
I think the way how things are visualized by software is a very important issue.
But I want to clearify that is is not that I prefer a technical presentation over a visually more appealing one. Certainly not.
My problem is that this would mean I have to manipulate the content of the entries. That is not a good thing. if you copy a "url" into your clipboard that contains special characters then kio-clipboard will certainly accept that as is. Have a try:
http://web.someserver.gaga/folder/some place in time.##§@:
Copy that into your clipboard and visualize it in kio-clipboard. No changes done. it is not kio-clipboard doing the technical encoding. You put an already encoded url into your clipboard and kio-clipboard only cites that content without changing it.
> reload - apologies, did not read todo but did read "road map" and "state",
> and in "state" it reads to me that refresh is only an issue after deleting an item
I see where that missunderstanding comes from, so I changed the text. Sorry for that !
But I am impressed that you take interest into that little experiment. May I ask where your interest comes from ?
And, out of curiosity, since you dont happen to be a developer: why do you use a beta version of KDE ?
arkascha
i have error in install:
grek@grek-dv7-laptop:~/Pobrane/0.2.5.r112/build$ cmake -DCMAKE_INSTALL_PREFIX=`kde4-config --prefix` ..
CMake Error at /usr/share/cmake-2.8/Modules/FindKDE4.cmake:98 (MESSAGE):
ERROR: cmake/modules/FindKDE4Internal.cmake not found in
/home/grek/.kde/share/apps;/usr/share/kubuntu-default-settings/kde4-profile/default/share/apps;/usr/share/kde4/apps
Call Stack (most recent call first):
src/CMakeLists.txt:1 (find_package)
-- Configuring incomplete, errors occurred!
grek@grek-dv7-laptop:~/Pobrane/0.2.5.r112/build$ cmake -DCMAKE_INSTALL_PREFIX=`kde4-config --prefix` ..
CMake Error at /usr/share/cmake-2.8/Modules/FindKDE4.cmake:98 (MESSAGE):
ERROR: cmake/modules/FindKDE4Internal.cmake not found in
/home/grek/.kde/share/apps;/usr/share/kubuntu-default-settings/kde4-profile/default/share/apps;/usr/share/kde4/apps
Call Stack (most recent call first):
src/CMakeLists.txt:1 (find_package)
-- Configuring incomplete, errors occurred!
grek@grek-dv7-laptop:~/Pobrane/0.2.5.r112/build$
mayby ther is .deb version (ubuntu 11.10 x64)
or how to fix install ?
Hey,
thanks for taking interest in this experiment :-)
The error you mention looks like a setup problem in your distributions cmake setup. It is (as far as I can tell by the hints) not caused by kio-clipboard itself.
It appears your cmake loads '/usr/share/cmake/Modules/FindKDE4.cmake' and executes it. In line 98 and before there are references to further macro definitions in a file called FindKDE4Internal.cmake. It appears your cmake cannot find that file.
My systems suggest '/usr/share/kde4/apps/cmake/modules/FindKDE4Internal.cmake' which looks logical to me. But my development laptops all run openSUSE since I have very good experiences with that distribution, as opposed to other distros I tried now and then. It is certainly possible that kubuntu uses some other path, but then again the kubuntu cmake setup should be aware of its own file system structure.
You might want to check (using 'locate' or your package management system) for this file or something similar. It might be that kubuntu does not use the path '/usr/share/kde4/', but '/usr/share/kde/' instead ? Or, more likely, you just have to install some additional development package for something like kdelibs.
Sorry, but I am not really familiar with any of the ubuntu distributions.
Google suggests to take a look at these pages:
http://www.linuxquestions.org/questions/linux-software-2/findkde4internal-cmake-not-found-fixed-783544/
http://forum.kde.org/viewtopic.php?f=69&t=92333
There is currently no .deb package provided by me, since I use OBS for package creation. OBS is generally able to generate packages for many many distributions, including debian varieties. But I did not invest time into sorting out the details required in the spec file to get this working.
I am happy to give it some effort if someone drops me a few notes about what has to be done to get this running. Especially if that one is interesting in taking this little experiement to the next version which I was working on before I had to switch to something else for the mean time :-).
Thanks, great you like the idea.
Though at first that really was just an experiment for myself I realize: there is potential in that. With the implementation of classes integrating public clipboards (paste bins) the result is a unified and more than easy to use general API to share information. Every application could offer such "sharing service" without real effort. Just "save to clipboard", select which one, and here you go :-)
Anyway, there are still a few steps to take before that !
You ask for access to the source repository. Hmm.
I currently use an internal subversion repository I cannot make available in public.
I guess easiest is to create a new one and grant access to that. Why not ? " I'll be back " :-)
Ok,
I made a quick setup of a separate repository I can grant access to.
Note that this is only temporary, I may withdraw this offer without further notice in case I see any requests I don't like (sorry!)
WebSVN:
http://svn.christian-reiner.info/web/
=====
There is anonymous read access to the repository itself (this is what you probably asked for...):
https://svn.christian-reiner.info/svn/
The layout is package specific with classical structure underneath:
/app/kde/kio-clipboard/...
.../trunk
.../branches/0.1
.../branches/0.2
...tags/0.1
...tags/0.2.0
[...]
I apologize for the warning you will get because of an invalid ssl certificate. I do not want to spend money for this private server of mine. Right now it is only important for me to offer encryption.
I would definitely appreciate some help getting a certificate free of charge, one that actually works in consumer browsers :-).
Please note that active development is done in the current branch (not in trunk) !
I merge changes from the branches to trunk manually every now and then.
Thanks for the link.
Sad, that there is just a screenshot. Would have been interesting to look into the source code.
I did not know that one. There is some old slave of the same name I found in the internet (after having started this). But it does not appear to be the same thing, though.
Ratings & Comments
20 Comments
I wrote the original version for 3.x and the benefits where being able to upload a file directly to the internet from the clipboard and being able to pick the mime type of the file you wished to save from the clipboard
In Dolphin I get a listing of what looks like long hex strings. If I hover over the entry I either see an actual text string or I see what you show in your images ([2]URL://..............) http://simplest-image-hosting.net/png-0-screen-20111204-064726 running KDE 4.8 beta1
Thanks for the feedback. As you probably guesed I currently dont follow this experiment any more, though extensions as described might be useful and interesting. Anyway, since I started this as a learning case I am curious myself what the problem is. So let's see... Quote: running KDE 4.8 beta1
I don't (yet) use KDE-4.8 myself and have no such system around. So I have to ask for a little help from your side.
Quote: In Dolphin I get a listing of what looks like long hex strings. If I hover over the entry I either see an actual text string or I see what you show in your images ([2]URL://..............)
http://simplest-image-hosting.net/png-0-screen-20111204-064726
Hm, from what I can see we have this situation:
The plugin works, extracts and publishes the klipper entries as expected, except for one single details: the 'DisplayName'. This is the token inside the UDSEntry that entries are actually named as for example in dolphin. It appears as if other tokens are fine, since you appear to see different, well defined file types and apparently the 'Comment' tokens are correct too. If you can open entries as expected then it seems the problem is only in the DisplayName token.
Since the DisplayName is constructed from the same data as other tokens I suggest there is no general problem in retrieving or storing the data, but in the way kio-clipboard constructs the UDSEntry.
My guess is, that there is an incompatibility between the implementation of the UDSEntry class between KDE-4.8 and earlier versions. The class keeps the tokens in a data structure, single tokens are addressed using bitfields. So most likely those bitfields have changed with KDE-4.8.
Question: are you using a precompiled binary from my repository or did you compile it yourself ?
In case of a precompiled binary please have a try with the packages you find in this repository I just set up. It builds the application directly against the unstable KDE-4.8 as available in OBS:
http://download.opensuse.org/repositories/home:/arkascha:/KDE-4.8/
If this does not solve the issue or you use a self compiled version we need to dig a little deeper. The attempt above was only a long shot from my side :-)
Please follow these instructions and post a link to the resulting debug output file posted to a pastbin:
1.) close all instances of dolphin and other applications that might currently use the slave (kio-clipboard).
2.) re-check with a ps aux|grep kio-clipboard, there must be no instances left.
3.) start 'kdebugdialog', deselect all check marks first, after that check the two marks before "kio_clipboard" and "kio_klipper", you can use the 'Search' field at the top for this
4.) in a terminal ("konsole") follow these steps:
4.a) enter: export KDE_FORK_SLAVES=true (and press return)
4.b) enter: dolphin > kio-clipboard.debug 2>&1 (dolphin opens with this)
4.c) in 'dolphin' open the clipboard url and enter the 'klipper' folder, open a random item and close it again
4.d) close dolphin again
4.e) upload the generated debug dump file 'kio-clipboard.debug' to a pastbin
4.f) publish the pastebin url here along with any additional information you might want to give
Thanks for the assistance !
http://pastebin.com/ZexNgSHM self compiled as the repo link is not populated thanks,
According to your signature you are using openSUE 12.1 on an 64 bit system. Question: which source package did you use for the build ? tag 0.2.5, branch 0.2 or the trunk ? Sorry for the empty KDE-4.8 repository. The packages were build successfully, but apparently before publishing 'em OBS decided to rebuild KDE-4.8beta1 and this currently blocks my packages. Takes a little while, I guess.
0.2.5
Thanks for the debug output you generated. From this I learn that the 'DisplayName' is set correctly. The hashes ("hex strings") you see as item names are indeed used internally to identify an item when selected, for example by a double click. I cannot use the displayed name since that one must not be unique neccessarily. Whyever, your dolphin appears to show the technical names of items instead of the specified (and correct) display names. I will ask upstream if there is a current regression in KDE-4.8beta, otherwise I have to build a virtual appliance running that kde version to be able to track down that issue. Will take a little while, sorry. => I will come back to you.
Ok, just as I suspected this is indeed a regression in KDE-4.8beta1 and not a bug in kio-clipboard. KDE bugzilla: http://bugs.kde.org/287472 http://bugs.kde.org/287139 So sorry for the inconvenience, but all we can do is wait. The issue will fix itself. Sebatian pushed a fix to this on 25.11.2011, I hope this is part of beta2 scheduled to be published on 07.12.2011.
much better in 4.8rc2 (http://simplest-image-hosting.net/png-0-screen-20111211-062238) 2 issues (?) - does file names have to have "%20" used for spaces - in my minimal testing the klipper folder need to be reloaded for the new items to be displayed, and changing folders then going back to the klipp folder does not display new entries either only a reload will thanks,
Glad that bug got corrected. I guess you are using KDE-4.8beta2 now ? KDE-4.8rc2 is announced for Jan 2012 AFAIK. > - does file names have to have "%20" used for spaces Hm, didn't think about that before... Fast reply would be "yes", this has to be like this 'cause the entry holds a url, and a space in an url is not valid. There are technical limitations as to what chars can be contained in a valid url, everything else has to be encoded. Without such encoding many protocols would choke out errors upon such url and/or lead to unwanted results. The "percent encoding" you see is just one way of encoding, there are others (but none preserves a blank/space). However in certain situations it makes sense to show the unencoded url, especially when visualizing a url to humans. But there is an aspect we have to consider here: The encoding is NOT done by kio-clipboard. The encoding is done by whatever component that copied the url to klipper in the first place. Open klipper, you will see that it holds the encoded url as entry. All that kio-clipboard does is to cite the entries of klipper, it does not alter their content. It might be technical possible to "unencode" such entry, but I am currently not sure if this is desireable. Let me think about it ! Or, give me a reason why you think this should be changed. > - [...] the klipper folder need to be reloaded for the new items to be displayed Unfortunately that is true. The fact is already documented in the contained TODO file. I have not yet found a way to ge around this. The reason is simple: the kio system provides absolutely no mean to react on changes and trigger a refresh of a view for "remote protocols". That is for protocols not considered local. So whatever kio-clipboard tries, however loud and often it shouts: refresh the view!, the embedding application simply will not see that. So a manual refresh is currently the only way, sadly. As long as I dont know a way around this general limitation I see no way to change that behaviour. Sorry for the inconvenience. Maybe someone has a suggestion...
sorry I meant beta2 "%20" used for spaces - I have no valid argument other than esthetics's (not a very valid argument), not understanding url coding standards I was not aware of the need reload - apologies, did not read todo but did read "road map" and "state", and in "state" it reads to me that refresh is only an issue after deleting an item thanks,
Hello, > "%20" used for spaces - I have no valid argument other than esthetics's (not a very > valid argument), not understanding url coding standards I was not aware of the need I think the way how things are visualized by software is a very important issue. But I want to clearify that is is not that I prefer a technical presentation over a visually more appealing one. Certainly not. My problem is that this would mean I have to manipulate the content of the entries. That is not a good thing. if you copy a "url" into your clipboard that contains special characters then kio-clipboard will certainly accept that as is. Have a try: http://web.someserver.gaga/folder/some place in time.##§@: Copy that into your clipboard and visualize it in kio-clipboard. No changes done. it is not kio-clipboard doing the technical encoding. You put an already encoded url into your clipboard and kio-clipboard only cites that content without changing it. > reload - apologies, did not read todo but did read "road map" and "state", > and in "state" it reads to me that refresh is only an issue after deleting an item I see where that missunderstanding comes from, so I changed the text. Sorry for that ! But I am impressed that you take interest into that little experiment. May I ask where your interest comes from ? And, out of curiosity, since you dont happen to be a developer: why do you use a beta version of KDE ? arkascha
sent message
i have error in install: grek@grek-dv7-laptop:~/Pobrane/0.2.5.r112/build$ cmake -DCMAKE_INSTALL_PREFIX=`kde4-config --prefix` .. CMake Error at /usr/share/cmake-2.8/Modules/FindKDE4.cmake:98 (MESSAGE): ERROR: cmake/modules/FindKDE4Internal.cmake not found in /home/grek/.kde/share/apps;/usr/share/kubuntu-default-settings/kde4-profile/default/share/apps;/usr/share/kde4/apps Call Stack (most recent call first): src/CMakeLists.txt:1 (find_package) -- Configuring incomplete, errors occurred! grek@grek-dv7-laptop:~/Pobrane/0.2.5.r112/build$ cmake -DCMAKE_INSTALL_PREFIX=`kde4-config --prefix` .. CMake Error at /usr/share/cmake-2.8/Modules/FindKDE4.cmake:98 (MESSAGE): ERROR: cmake/modules/FindKDE4Internal.cmake not found in /home/grek/.kde/share/apps;/usr/share/kubuntu-default-settings/kde4-profile/default/share/apps;/usr/share/kde4/apps Call Stack (most recent call first): src/CMakeLists.txt:1 (find_package) -- Configuring incomplete, errors occurred! grek@grek-dv7-laptop:~/Pobrane/0.2.5.r112/build$ mayby ther is .deb version (ubuntu 11.10 x64) or how to fix install ?
Hey, thanks for taking interest in this experiment :-) The error you mention looks like a setup problem in your distributions cmake setup. It is (as far as I can tell by the hints) not caused by kio-clipboard itself. It appears your cmake loads '/usr/share/cmake/Modules/FindKDE4.cmake' and executes it. In line 98 and before there are references to further macro definitions in a file called FindKDE4Internal.cmake. It appears your cmake cannot find that file. My systems suggest '/usr/share/kde4/apps/cmake/modules/FindKDE4Internal.cmake' which looks logical to me. But my development laptops all run openSUSE since I have very good experiences with that distribution, as opposed to other distros I tried now and then. It is certainly possible that kubuntu uses some other path, but then again the kubuntu cmake setup should be aware of its own file system structure. You might want to check (using 'locate' or your package management system) for this file or something similar. It might be that kubuntu does not use the path '/usr/share/kde4/', but '/usr/share/kde/' instead ? Or, more likely, you just have to install some additional development package for something like kdelibs. Sorry, but I am not really familiar with any of the ubuntu distributions. Google suggests to take a look at these pages: http://www.linuxquestions.org/questions/linux-software-2/findkde4internal-cmake-not-found-fixed-783544/ http://forum.kde.org/viewtopic.php?f=69&t=92333 There is currently no .deb package provided by me, since I use OBS for package creation. OBS is generally able to generate packages for many many distributions, including debian varieties. But I did not invest time into sorting out the details required in the spec file to get this working. I am happy to give it some effort if someone drops me a few notes about what has to be done to get this running. Especially if that one is interesting in taking this little experiement to the next version which I was working on before I had to switch to something else for the mean time :-).
Any source repo or just archives?
Thanks, great you like the idea. Though at first that really was just an experiment for myself I realize: there is potential in that. With the implementation of classes integrating public clipboards (paste bins) the result is a unified and more than easy to use general API to share information. Every application could offer such "sharing service" without real effort. Just "save to clipboard", select which one, and here you go :-) Anyway, there are still a few steps to take before that ! You ask for access to the source repository. Hmm. I currently use an internal subversion repository I cannot make available in public. I guess easiest is to create a new one and grant access to that. Why not ? " I'll be back " :-)
Ok, I made a quick setup of a separate repository I can grant access to. Note that this is only temporary, I may withdraw this offer without further notice in case I see any requests I don't like (sorry!) WebSVN: http://svn.christian-reiner.info/web/ ===== There is anonymous read access to the repository itself (this is what you probably asked for...): https://svn.christian-reiner.info/svn/ The layout is package specific with classical structure underneath: /app/kde/kio-clipboard/... .../trunk .../branches/0.1 .../branches/0.2 ...tags/0.1 ...tags/0.2.0 [...] I apologize for the warning you will get because of an invalid ssl certificate. I do not want to spend money for this private server of mine. Right now it is only important for me to offer encryption. I would definitely appreciate some help getting a certificate free of charge, one that actually works in consumer browsers :-). Please note that active development is done in the current branch (not in trunk) ! I merge changes from the branches to trunk manually every now and then.
their is a 7 years old wish @ kde bugs for this https://bugs.kde.org/show_bug.cgi?id=83870
Thanks for the link. Sad, that there is just a screenshot. Would have been interesting to look into the source code. I did not know that one. There is some old slave of the same name I found in the internet (after having started this). But it does not appear to be the same thing, though.