GNOME.org
 

Re: New clipboard proposal

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)? This would remove the need for a new clipboard type, advertising a new TARGET, a new library, dependance on dbus, fallback to a sub-optimal 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, 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'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.
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? 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.
For massive-data-transfer, both an X extension and some dbus implementation will require transfers of huge amounts of data between processes. 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. 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.
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. 

$0.02

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



On 30 Dec 2004, at 11:21, Philip Van Hoof wrote:




Hi there fellow hackers, programmers and other people involved in the
development of the freedesktop.

There's been many problems with the current implementation of the X11
clipboard. Before I start with my new proposal I'll guide you through
the current implementation so you'll understand some terminology. If you 
already know everything about the clipboard on X11, you can skip all
this, of course.

Very very short . . .

There's three standard clipboards: The PRIMARY, SECONDARY and the
CLIPBOARD. Another name for such a clipboard is "a selection". So you
say "the CLIPBOARD selection".

Only one xclient application can own such a clipboard at a time. All
three work independent from each other.

When an xclient requests the selection, it will typically ask X about
the selection-owner of a specific selection (PRIMARY, CLIPBOARD or
SECONDARY).

Such a selection-owner can advertise the formats it's supporting. Those
formats are called TARGETs. One selection-owner can have multiple
targets. It can advertise the supported ones in a standard target called the TARGETS target. So a typical requester (an application that is going to paste something) 
will first ask for the TARGETS target, then it will pick a format it
knows, then it will ask the selection-owner to start converting data to
the format it had been advertising. Then it will retrieve this data from 
that selection-owner through the xserver.

Lets take an example:

In Mozilla you selected some text. Thats the PRIMARY selection.

In Evolution's E-mail composer you do "paste". Evolution's E-mail
composer will now ask X about the selection-owner. Through X it will ask for the TARGETS target of that selection-owner (Mozilla). Mozilla will say it supports a "text/html"-target. 

Evolution's E-mail composer will request Mozilla to convert it's own
format to that "text/html"-format and Evolution's E-mail composer will,
through X, receive the data in the requested format.

There's many problems with this method:

o. What happens when Mozilla got shut down before Evolution got
 the chance to paste the clipboard?

o. What happens when Mozilla has 400MB of data to deliver? A better
 example might be "copying a large table from
 gnumeric to Mozilla composer"

o. What happens when you shutdown your X session. Is your
 clipboard lost?
To address these issues, I've cooked up a proposal. The proposal aims to 
replace the entire clipboard in the long run. But will provide full
backwards compatibility for older X-clients. The proposal won't depends
on any technology disliked by both KDE or GNOME.

The proposal itself is incomplete. There's still a lot to agree upon.

The proposal

o. We'll still use the current protocol for advertising the fact
 that there's support for the new-type clipboard. There's no problem
 with still using the old-style clipboard.

o. We add a TARGET "x-extension/dbus"

o. The contents of the target explane the available
 services on dbus. The format of the contents isn't
 defined yet.

o. We'll create a library that will do most for the application
 developer

o. That library will initiate dbus in such a way that both
 xclients/processes can enjoy the wonders of inter process
 communication. This will address the "large clipboards" issue.

o. The library will fallback to the oldstyle X11 protocol if the
 dbus connection failed. This way it isn't necessary to let
 dbus serve on tcp/ip or to open ports. If both processes
 aren't on the same host, it will use the current (working)
 implementation.

o. A clipboard manager will, using the new Xfixes extensions,
 catch clipboards that will be lost if the selection-owner
 gets destroyed. That same clipboard manager will persist
the clipboard when the session is about to get shutdown. o. Whether or not to support a clipboard history is an option or a 
 plugin for that clipboard manager.

o. The clipboard manager can also function as a hybride between
 old X11 applications and newer applications. The clipboard
 manager can, for example, add the "x-extension/dbus" target and can
 provide a service that will deliver the data if a newer application
 wants to receive the data using that channel.
I attached two dia diagrams. You can view them using the app "dia" which 
is available here: http://dia.sf.net. They might be incomplete or
inaccurate or whatever. And no there's not really anything done yet
(except a very basic sample application using the new XFixes events
related to clipboard handling).


--

 -
/~\ The ASCII
\ / Ribbon Campaign
 X  Help cure HTML Email
/ \

Attachment: smime.p7s
Description: S/MIME cryptographic signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]