New clipboard proposal

[Philip Van Hoof]

On Thu, 2004-12-30 at 16:03 -0800, John Davidorff Pell wrote:
> I'm not an X developer, but I am a user, and I thought I'd comment. :-)

> I don't like the dependance on dbus. Why can't the X server itself  
> maintain the contents of the various clipboards? (assuming they're  
> under some size-limit, which will also have to be addressed by this  
> clipboard-manager/dbus thing)?

There's several reasons for it. One might be that X11 already is
designed and tends to keep backwards compatibility a high priority. For
such a solution it would be difficult to maintain that backwards
compatibility.

Another reason with such a solution might be that for every selection
you'd set, the selected data would have to be copied to the
xserver-process. While most of the selections you do, won't be used for
pasting at all.

> This would remove the need for a new clipboard type, advertising a new
> TARGET, 

Advertising a new target isn't anything special. I'll take
openoffice.org as an example. It advertises many new targets probably
only used internally by openoffice.org.


> a new library, dependance on  dbus,

DBUS is actually ment for the purpose of inter process communication
between desktop applications. X11 is typically deployed for desktop
usage. Copying and pasting is a typical communication between two
processes. Since DBUS is being developed by freedesktop.org it sure
looks like the most ideal candidate IPC available.

>  fallback to a sub-optimal protocol, 

The current protocol is actually sub-optimal. For clipboard data to get
transfered from one xclient to another, it needs to go all the way to
the xserver (which might be located on another host) and from the
xserver to that other xclient. While in most cases both xclients live on
the same host. So they'd better use a shortcut-path. And if that ain't
possible, there's still the current protocol.

> the clipboard manager itself, and needing for new-clipboard-using-
> applications-talking-to-old-clipboard-using-applications to do something
> special.


> That's all of your proposal,  
> except the history, persistence, and the massive-clipboard management, 

What massive clipboard management? By default (without the history
plugin as explained below) the only situation a clipboard manager would
need to catch the current clipboard and store it, is when the current
clipboard-owner application is going to die. 

> btw. History could be added by having some application catch all  
> changes to whichever clipboard it is listening to and storing it, which  
> is what your clipboard manager would do anyway.

I mentioned keeping histories. My exact words where that it could be an
option in the form of a plugin for that clipboard manager. As a matter
of fact there are a few applications today doing this for you. One
example is Klipper. Many people use Klipper. Others don't. Therefor
keeping clipboard history isn't going to be the main purpose.

Making it easy for applications like Klipper to pop/push and query this
history would be delegated to such a plugin.

> I'm not sure if an X client (Owner of PRIMARY, for example) is allowed  
> to change the information that it would provide between when it  
> advertises and when it actually is asked to provide. If it is, then  
> both our solutions break.

The xclient isn't altering the list of targets between advertisement of
it's targets and providing (converting) one such target to a requester.
Nothing about the current clipboard-handling protocol is different from
now. Only one target is added (which is something any xclient who's
owning the selection is allowed to do -- take a look at openoffice.org's
list of targets --). There's noting "strange" about it.

> I think you're looking for over-kill. Why can't we write a (very) small  
> extension to the X server that just keeps track of the contents of the  
> various selections?

Because storing that selection isn't the task of the xserver. It's the
task of the xclient. And it's the task of an application following the
CLIPBOARD_MANAGER specification to take-over the selection if a
clipboard-owner is about the die. There's documentation about this
subject.

> This really would solve almost all of the problems.  
> This solves selection loss because of an application quitting, which I  
> think is the most user-visible problem.

The most user-visible problem is the fact that many applications aren't
providing useful targets. It's only since very recently you can copy and
paste formatted text from mozilla to evolution's e-mail composer. 

At this moment copy/pasting between openoffice.org's calc and gnumeric
is very buggy and won't always work.

That problem, however, can't be tackled by any "tool" or "daemon" or
whatever. It can be, however, tackled by creating standards and agreeing
on MIME-types.

> For massive-data-transfer, both an X extension and some dbus  
> implementation will require transfers of huge amounts of data between  
> processes.

Yes. The difference is, however, that the xserver might be located on a
different location than most of the xclients. While most of the xclients
will be located on the same host. And another difference is that dbus is
or can be designed to transfer huge amounts of data between processes,
and X11 can't nor isn't designed to do that. And when the xserver is
running on a different host, you'll need gigabit network adaptors to get
it transfer a clipboard from one xclient, running on host a, to another
xclient also running on host a. Using host b, where the xserver is
running. Wouldn't it be better if both xclients could send it to each
other while not needing host b for transferring the data itself?

Some people might think there's no such thing as a huge selection. I
think one of the reasons you still cannot copy/paste from The GIMP is
because the protocol itself is limited in terms of scalability. I often
do large copy/pastes. It'd be nice if I copied from mozilla a webpage
with images, the images could be retrieved by a requester using an IPC.
As far as I know is the current solution to let the requester parse the
HTML and retrieve the images over http all by itself. While mozilla
probably has them already. It can deliver those, if only some inter
process communication between mozilla and the application requesting the
clipboard would be possible.


> On Winblows (M$ does get *some* things right), in M$ Word  
> when you quit word with a large clipboard it asks if you want that  
> clipboard to continue to be available after Word quits. This is just  
> what the X server should do.

I'm guessing Microsoft uses a similar technique. Probably using their
COM+/DCOM technologies. I haven't studied it, however. So I'm not sure.

> If an application provides a clipboard  
> that is larger than the predefined-max-for-storage-in-X-server-memory  
> then the user should be asked (by either the X server, or the  
> Application) if he or she wants the selection to last. This means that  
> the server is not bogged down with huge clipboards (which your  
> clipboard manager would also have to deal with), and if the user wants  
> to keep the clipboard available, he or she will have the option to.  
> This solves the massive-transfer problem.

How does it solve the problem? It makes the user the guilty entity by
asking him a stupid question. Of course does the user want that
clipboard saved. Well. Perhaps he or she doesn't want it saved, but he
or she sure doesn't want to get bothered with such a question. It's a
computer! It should know all by itself whats best. Have you ever seen
your grandmother using a computer? Do you really think she would
understand that question? You do you really think she knows what the
impact would be if she would answer "No"? Perhaps you have a very smart
grandmother. Mine sure wouldn't even read the question and would most
likely just answer the default answer right away.

And the only difference might be the fact that the Microsoft solution
isn't using a process. So it's more monolithic. Being monolithic,
however, isn't the preferred design pattern for UNIX softwares. X11 is
huge all by itself. It doesn't need yet another task (like persisting
the clipboard of xclients that are to be shut down).

> As for clipboard persistence between invocations of the X server, I  
> personally don't see that as useful in any but corner cases. It can,  
> however, be addressed in the same way that history is provided: by a  
> very small watcher application that just loads its initial history from  
> file before it starts watching for X selection changes.

And what do you think a clipboard manager would have to do? Exactly, be
that small watcher application that just loads its initial history from
file before it starts watching for X selection changes.


> P.S. I don't think anyone appreciates this super-cross posting that  
> you've done...

Thats why both me and Andrew Sobala suggested using only the
xdg-mailinglist on freedesktop.org. You just did the exact same
thing :-)



-- 
Philip Van Hoof, Software Developer @ Cronos
home: me at freax dot org
gnome: pvanhoof at gnome dot org
work: philip dot vanhoof at cronos dot be
junk: philip dot vanhoof at gmail dot com
http://www.freax.be, http://www.freax.eu.org