[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Klipper
From:       Eike Hein <hein () kde ! org>
Date:       2011-05-17 1:59:17
Message-ID: 4DD1D675.2090200 () kde ! org
[Download RAW message or body]

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.

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
[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic