Klipper

[Lubos Lunak]

On Tuesday 31 of May 2011, Esben Mose Hansen wrote:
> 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.

 Why would they need it instead of QClipboard::changed() ?

> 1.b. It should also handle at least basic clipboard retention (that is,
> plain text, html, and QT-supported image formats).

 Note that it doesn't really depend on whether Qt supports the format or not, 
QClipboard::mimeData() can provide the complete clipboard contents in all 
formats, whether known or not. The problem is rather the question what 
formats to store (more than one usually means duplication of the underlying 
data and there's no generic way to tell which format is the best, 
additionally actually creating the data in any format may possibly take some 
time).

> 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.

 This could be
- a race condition (depending on how the retrieving of content for history 
saving is done)
- slow (keep in mind that people occassionally put huge data into clipboard)

> It could also handle the edit clipboard feature.

 I can see the reason why this could be outside of the core, or why the 
history showing could be, but the saving itself IMO fits much better in core.

> 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?

 It sounds a bit like over-engineering to me.

> Or should it be a service that communicates over dbus? Or is it just a bad
> idea. 

 Given what's said above, I myself would try to keep all the data handling to 
the core, as much as possible. The UI, if separate, could just forward 
commands to the core or ask only for contents it actually needs to show.

 That said, history has shown that having clipboard polling in an important 
process can occassionally break things in ugly ways, so trying to move the 
core to KDED (or Plasma, if somebody really thinks that's a good idea) should 
be something to think about twice. And if it already needs a separate 
process, what is the gain of the UI separation (this is not a rhetoric 
question)?

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

 The only UI from Klipper I care to see are the history and action popups, so 
if this meant I'd need to have a plasmoid somewhere just to remind me that a 
a functionality I consider core exists, then count me in.

-- 
 Lubos Lunak
 l.lunak at suse.cz