New clipboard proposal
John Davidorff Pell
johnpell at mac.com
Fri Dec 31 04:11:19 EET 2004
On 30 Dec 2004, at 17:12, Philip Van Hoof wrote:
> 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
This wouldn't break backward compatibility at all. Clients would still
only advertise the way they currently do, and clients would still
request the selection the way they do now. The only change would be
that the advertiser receives one request immediately after advertising
and no more.
> 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.
Good point, but a clipboard manager using dbus would do the same thing,
>> This would remove the need for a new clipboard type, advertising a new
> 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.
I'm not saying that advertising new targets are bad, just that it is a
trick that I don't think is necessary. OOo advertises TARGETS that are
probably only used internally, but they don't need to be. Also, some
time in the future OOo will be splitting back into separate apps, so
they will actually use the clipboard between them just like any other
>> 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.
D-Bus may become common on GNU/Linux distros, but I'm not sure if it
will in other places, especially commercial UNIX flavours. I would much
prefer if the clipboard system could be improved, rather than providing
a replacement that is platform specific. (When I say platform specific,
I don't meant hat it doesn't run on many platforms, but rather that it
is only commonly available on certain platforms.)
>> 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
> the same host. So they'd better use a shortcut-path. And if that ain't
> possible, there's still the current protocol.
That's what I mean. What I'm trying to say is that the sub-optimal
protocol should be improved, while still providing 100% backward
compatibility... actually, the interface would not change at all.
>> the clipboard manager itself, and needing for new-clipboard-using-
>> applications-talking-to-old-clipboard-using-applications to do
>> 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.
I did not understand that from your proposal, so my comments may have
seemed a bit odd. Ok, so really this is just a replacement for the
clipboard that is limited to distributions that choose to support it?
>> 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.
If the X server kept track of the contents of the clipboard, then
klipper would continue to work exactly as it does today, no changes
>> 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
> list of targets --). There's noting "strange" about it.
It seems like what you are proposing is to do nothing for existing
applications, but provide a better clipboard for applications that link
to your library in the future. I don't think that's a good idea as it
creates a dependancy that many smaller apps will just choose not to
include, or that many users won't install when building smaller apps.
It also does not solve the existing problems, such as losing the
clipboard when clients quit.
>> 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
I've not read that spec, I will if someone sends me a link. :-)
If X implements this spec, or if KDE/GNOME do, then the tiny X ext
would not need to copy the selection every time, only when an app
announces that its about to quit. Better yet, screw the extention and
just make klipper do this. If an app announces its about to die, then
klipper should request all TARGETS provided by that app. I get the
feeling that this is not how most apps work, though.
>> 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
> paste formatted text from mozilla to evolution's e-mail composer.
That won't be solved by either solution. It can't be.
> At this moment copy/pasting between openoffice.org's calc and gnumeric
> is very buggy and won't always work.
And I hope they're working on this, but either solution doesn't do a
thing about this.
> That problem, however, can't be tackled by any "tool" or "daemon" or
> whatever. It can be, however, tackled by creating standards and
> on MIME-types.
Agreed! Ok, so an app should advertise appropriate MIME types... which
can then be requested via the X selection routines.
>> For massive-data-transfer, both an X extension and some dbus
>> implementation will require transfers of huge amounts of data between
> Yes. The difference is, however, that the xserver might be located on a
> different location than most of the xclients. While most of the
> will be located on the same host.
I think that this is not a good assumption, but I do understand your
concern. I would guess, however, that in many cases the
dbus/clipboard-manager daemon might be running on the same host as the
X server, creating the exact same issue, just with a different daemon.
> 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
> 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?
How easy is it for these apps to talk directly? I know that the dbus
messages can be sent from one app directly to another, but how much
interaction with the dbus daemon is need to do this? How easily can an
app be written to support this?
> 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
> clipboard would be possible.
This is cool, and is definitely something that we all want, but a
clipboard manger won't do this. Transferring images embedded in
formatted text is something that must be solves by both sides of the
transaction supporting a specified format for doing just that. D-Bus
may make it faster in some cases, but it does not solve the problem.
>> 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.
Most users just click the closest non-destructive button, which usually
means the one that looks like the default. In this case, the app would
do what it thinks is the best trade off: supply the information to the
X server (or D-Bus-based clipboard manager) at the possible expense of
time and bandwidth, or not. You still have to deal with this in your
> 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).
Windoze also doesn't have to worry about sending the clipboard to
>> 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.
Like klipper, but what it sounds like you are talking about is much
much larger and requires a number of changes for a client to use it.
That's the part I don't like. It doesn't help those of us who do not
run a KDE or GNOME session, or who don't run entirely KDE or GNOME
apps. That is where all my objections come from. Your clipboard manager
via dbus doesn't address the problems that currently exist, though I do
give you credit for trying to prevent them in future apps (that happen
to use your library/clipboard, that happen to be on hosts where it is
If I understand you correctly, then an app that supports your
clipboard-over-dbus that is asked to paste would check the available
TARGETS, notice the dbus one, then ask dbus for another list of
available formats, then choose among those? What's to stop an
application from just ignoring the X server and going directly to
d-bus, destroying interoperability with other apps?
Thanks for listening,
P.S. I'm not on the xdg list, so I think my messages are awaiting
John Davidorff Pell
johnpell at mac.com
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2545 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20041230/306158b2/attachment.bin
More information about the xdg