On 2011-05-16 18:35, todd rme wrote:

> Would that make klipper a potential target for the upcoming
> modularization efforts, then?

As a pseudo-sometime maintainer of Klipper, I have thought about this 
extensively. So this is my take on it.

Klipper should be modularized like this:

1. The core bit:
1.a. This bit should listen to clipboard changes, and notify interested 
clients about changes as they occur.
1.b. It should also handle at least basic clipboard retention (that is, 
plain text, html, and QT-supported image formats).

2. The history bit.
This should be a client. It should be able to store the history. It 
would be best if the selection is only recorded if it is plain text, 
with the option of being completely ignored. It could also handle the 
edit clipboard feature.

3. The action bit. This feature is surprisingly popular, but I still 
find it a bit bells-and-whistles sort of thing. For those who don't know 
what it is, it is a listener that looks at the clipboard contents and if 
it matches certain patterns (e.g., looks like an URL, matches a file on 
disk etc), pops up a passive popup with some options for handling it, 
say opening the file in okular or whatever).


Now, since we are discussing this, I can put my question to the crowd: 
Does this sound like a dataengine with two plasmoids to you? Or should 
it be a service that communicates over dbus? Or is it just a bad idea.

Note that if it is converted to a dataengine/plasmoid, the Gnome users 
we have will hate us.

-- 
kind regards,
Esben Mose Hansen