I just had to jump in here after listening the discussion on clipboard management in Linux on this weeks show. I wanted to talk over you, but unfortunately, I don't have my own mic.
I believe that the concern is well founded. Clipboard management in Linux is totally botched. The problem is that once the application holding the clipboard contents quits, the content is flushed from the primary buffer. However, if you are running a super-daemon, such as KDE's klipper, which is just brilliant by the way, the clipboard content stays alive even after the death of the application. In fact, it can even keep up to 25 of the most recent selections. If you have never taken advantage of this feature in Klipper, you are really missing out!
Granted, I have read debates on how Klipper is a hack because it is essentially running as a vacuum cleaner to suck up anything and everything copied anywhere to make it available later. I say, "Who fucking cares, as long as I can get my clipboard selection." Now, that being said, while the hack is in place, perhaps a better solution should be developed. But until there is something, you are going to have to pry klipper from my dead body if you want to take it away from me, because Linux is unusable without it. Even now that I run Gnome, I still have Klipper kicking.
Clipboard does work! Klipper
Moderators: mrben, jono, matt, trig
12 posts • Page 1 of 1
- DanielT
- Concerningly committed to LugRadio
- Posts: 632
- Joined: Sun Mar 28, 2004 9:02 pm
- Location: Manchester
-

Lord C - New to the freak show
- Posts: 62
- Joined: Thu Mar 03, 2005 12:44 am
- Location: London, UK
DanielT wrote:BTW for gnome i use this:
http://members.chello.nl/~h.lai/gnome-c ... index.html
works fine.
That's cool.
Thanks
Windows [n.]
A thirty-two bit extension and GUI shell to a sixteen bit patch to an eight bit operating system originally coded for a four bit microprocessor and sold by a two-bit company that can't stand one bit of competition.
A thirty-two bit extension and GUI shell to a sixteen bit patch to an eight bit operating system originally coded for a four bit microprocessor and sold by a two-bit company that can't stand one bit of competition.
-

snecklifter - Knows their stuff
- Posts: 197
- Joined: Mon Feb 28, 2005 2:34 pm
- Location: UK/West Yorks/Huddersfield
- Jack Burton
- New to the freak show
- Posts: 20
- Joined: Tue Feb 15, 2005 4:58 pm
- Location: Middlesbrough
coz its more important to have colour gradiated title bars, stupid eye candy and themeability than it is to have solid functionaility and good foundation....
Now you just listen to the old Pork Chop Express and take his advice on a dark and stormy night when the pillars of heaven are shakin'....
-

Lord C - New to the freak show
- Posts: 62
- Joined: Thu Mar 03, 2005 12:44 am
- Location: London, UK
Jack Burton wrote:coz its more important to have colour gradiated title bars, stupid eye candy and themeability than it is to have solid functionaility and good foundation....
He said Gnome, not KDE
*budum che*
Windows [n.]
A thirty-two bit extension and GUI shell to a sixteen bit patch to an eight bit operating system originally coded for a four bit microprocessor and sold by a two-bit company that can't stand one bit of competition.
A thirty-two bit extension and GUI shell to a sixteen bit patch to an eight bit operating system originally coded for a four bit microprocessor and sold by a two-bit company that can't stand one bit of competition.
-

Aq - LugRadio Presenter
- Posts: 2233
- Joined: Mon Mar 01, 2004 4:38 pm
snecklifter wrote:Can anyone tell an ignoramus like me why this isnt in a stock version of GNOME?
See http://mail.gnome.org/archives/desktop- ... 00193.html and the following thread. It's not necessarily as clear-cut as it might appear.
Aq.
- mojavelinux
- New to the freak show
- Posts: 5
- Joined: Wed Mar 30, 2005 6:12 am
klipper excels
While I have followed the gnome-clipboard-daemon project, I still say that Klipper is a better application, even running under Gnome (which is my current configuration). Here are several reasons why:
1. klipper is simply good at what it does. It can pull from both the xselection and the copy buffer and it does a very good job at keeping the history ordered properly and in sync.
2. klipper left aligns entries, while gcd centers them
3. klipper can retain clipboard contents between logins.
4. klipper can perform actions on the clipboard contents (though I don't really use this feature).
5. klipper is accessible through dcop.
6. klipper can popup anywhere, not just out of the docklet icon.
There are features that klipper is missing, one which would be EXTREMELY helpful and which I have filed numerous feature enhancement requests. That feature would be the ability to "freeze" an entry so that it doesn't fall off the end of the list. For instance, that password that you need to keep handy until you commit it to memory, or something similar.
The best implementation I have seen for this feature is in the wmcliphist project.
If you still aren't convinced as to why we need a clipboard manager, try one for a few days and then attempt to go back. Nothing sucks worse then when you select something into your xselection, then accidently (without knowing) select something else and then are suprised when you go to paste that e-mail you copied and get an endline instead.
Oh, and Eclipse 3.1M5 finally works with the xselection properly, so working with Java and the clipboard just got way better.
1. klipper is simply good at what it does. It can pull from both the xselection and the copy buffer and it does a very good job at keeping the history ordered properly and in sync.
2. klipper left aligns entries, while gcd centers them
3. klipper can retain clipboard contents between logins.
4. klipper can perform actions on the clipboard contents (though I don't really use this feature).
5. klipper is accessible through dcop.
6. klipper can popup anywhere, not just out of the docklet icon.
There are features that klipper is missing, one which would be EXTREMELY helpful and which I have filed numerous feature enhancement requests. That feature would be the ability to "freeze" an entry so that it doesn't fall off the end of the list. For instance, that password that you need to keep handy until you commit it to memory, or something similar.
The best implementation I have seen for this feature is in the wmcliphist project.
If you still aren't convinced as to why we need a clipboard manager, try one for a few days and then attempt to go back. Nothing sucks worse then when you select something into your xselection, then accidently (without knowing) select something else and then are suprised when you go to paste that e-mail you copied and get an endline instead.
Oh, and Eclipse 3.1M5 finally works with the xselection properly, so working with Java and the clipboard just got way better.
-

mrben - Unbelievable LugRadio community master
- Posts: 3236
- Joined: Wed Mar 10, 2004 10:27 am
- Location: Glasgow
- mojavelinux
- New to the freak show
- Posts: 5
- Joined: Wed Mar 30, 2005 6:12 am
interesting that you ask
mrben, it is interesting that you ask about the overhead, because that is exactly why one of my coworkers has held of on using it. In short, I think he is foolish. When a KDE app first starts, it does load up the kdeinit service, but the overhead is remarkably low. Most of the time it sits idle and the dock app is VERY, VERY quick to respond. I believe the reason for this is that KDE distinquishes between a window app and a windowless app (such as klipper).
My opinion is that it is silly to "avoid" kde just to prevent the kdeinit process from starting. At first I worried about it as well, but I assure you that it won't even leave a mark on your available resources. At least, that is my experience. KDE only starts libraries as needed, so running klipper does not automatically start artsd, dcop and other such services.
My feeling is that KDE has too much to offer to ignore it. By no means to you have to run KDE to take advantage of what it has to offer. I use applications that allow me to be productive, some are Gnome/GTK, some are KDE. Some are even Java (but Java eats resources like a fat kid consumes donuts). amaroK is another application that I simply cannot live without, but I digress.
My opinion is that it is silly to "avoid" kde just to prevent the kdeinit process from starting. At first I worried about it as well, but I assure you that it won't even leave a mark on your available resources. At least, that is my experience. KDE only starts libraries as needed, so running klipper does not automatically start artsd, dcop and other such services.
My feeling is that KDE has too much to offer to ignore it. By no means to you have to run KDE to take advantage of what it has to offer. I use applications that allow me to be productive, some are Gnome/GTK, some are KDE. Some are even Java (but Java eats resources like a fat kid consumes donuts). amaroK is another application that I simply cannot live without, but I digress.
-

yonkeltron - Knows their stuff
- Posts: 159
- Joined: Tue Apr 20, 2004 8:08 pm
- Location: Philadelphia LUG
samurai wrote:I don't use clipboard cut and pastes too often so I'm a little less concerned then most, but there is the old standby of Xclipboad. Its pretty kludgy, but provides some of the functionality you want
the main word there is "some"...it provides "some of the functionality you want" and not all of it. as long as we the users settle for some of what we want, linux won't get stronger. if we turn around and fill in wishlists and file bugreports and maybe even add some features ourselves, we will make linux stronger.
i would never settle for some of the functionality that i want when i can get it all. granted i am an evil KDE user and i use MEPIS over ubuntu......but the point is that i know what i want and i know what i need and i make it my business to get it all working.
12 posts • Page 1 of 1
Who is online
Users browsing this forum: Yahoo [Bot] and 0 guests