Klipper

[Steven Sroka]

On 16 May 2011 21:59, Eike Hein <hein at kde.org> wrote:
> On 5/17/2011 12:12 AM, Steven Sroka wrote:
>>
>> This is why I think Klipper should be separate from kdebase-workspace.
>> It adds functionality but not exactly _core_ functionality.
>
> Let's recap:
>
> * X11 has three clipboard buffers by default, called
>  PRIMARY, SECONDARY and CLIPBOARD.
>
> * In practice, modern toolkits only use PRIMARY and
>  CLIPBOARD. PRIMARY is set by selecting things with
>  the mouse, and pasted by middle-mouse. CLIPBOARD is
>  operated on by keyboard shortcuts and GUI actions.
>
> * In the X11 clipboard model, the client that you copy
>  from is responsible for handing over the data when
>  you paste. That means that when you quit the client
>  you copied from before pasting, you can't paste any-
>  more.

This I like. Too bad I read this after I sent off my last email.

>
> Now, the main features of Klipper are:
>
> * It papers over the app you copied from needing to
>  still be running when you paste by taking over the
>  data when you copy, thus becoming the app responsi-
>  ble for handing over the data on paste, allowing
>  you to quit the original app.
>
> * It allows the synchronization of PRIMARY and CLIP-
>  BOARD.
>
> The first thing is vital, because the X11 clipboard
> interaction model without Klipper running is brain-
> dead and the sort of implementation detail that users
> don't want to have to think about. It's also different
> from any other platform (Windows, OS X, and Gnome
> which has an equivalent to Klipper running in some
> session daemon somewhere).
>
> All other features of Klipper - i.e. basically the
> entire user interface - are just icing.
>
> However, they're nice icing, and what's more, it's
> icing that's directly workspace-related, because the
> clipboard is an element of the workspace. Having a
> nice manager UI around the clipboard and having it
> by default adds an extra value and benefit for users
> over workspaces that don't.
>
> That's why I think Klipper should definitely stay
> in workspace.
>
> However, if the decision to remove Klipper is made,
> it's completely unacceptable to alter the clipboard
> behavior in the default workspace so radically, so
> the part of the Klipper code responsible for paper-
> ing over the deficiencies in the X11 clipboard model
> would have to move elsewhere. The first instinct
> would probably be a kded4 module, but imho it's a
> task that's too fraught with complications and com-
> plexities for what should be host to only relatively
> light-weight modules. So a separate daemon might be
> in order.
>
> The people who want to remove Klipper from workspace
> should expect to be asked to do the development work
> on a solution.
>
>
> --
> Best regards,
> Eike Hein
>