New clipboard proposal

[John Davidorff Pell]

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
/ \



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2545 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20041230/41f8664c/attachment.bin>