New clipboard proposal

[John Davidorff Pell]

On 30 Dec 2004, at 19:22, Philip Van Hoof wrote:


> On Thu, 2004-12-30 at 18:11 -0800, John Davidorff Pell wrote:
>
>
>> On 30 Dec 2004, at 17:12, Philip Van Hoof wrote:
>>
>>
>>> 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, no?
>>
> A clipboard manager with such a history plugin, yes. The clipboard
> manager I have in mind will only request the clipboard if the current
> clipboard owning xclient is about to get destroyed. The xfixes
> extensions will be used for that.
>
I just read about the Xfixes extension at 
http://freedesktop.org/wiki/Software/FixesExt. This is the perfect 
place to modify clipboard behaviour!

When an application it about to die, and it owns any of the selections, 
then save them! Simple and obvious repair to the core protocol. :-)


> The clipboard manager, however, is an optionally component of the
> proposal. The core of the proposal is to start using an IPC (like
> DBUS). I've understood that the dependency on such an IPC is your main 
> concern.
> Therefor it's important that applications keep backwards compatibility
> in tact.
>
> My plans are to create a lowlevel library that will ease the use of 
> this
> new system. Using this lowlevel library will keep things backwards
> compatible. Luckily it isn't so that all the available targets are to 
> be
> transfered in any case a clipboard-request happens. So we can make them
> available on the old-style clipboard handling while they won't take any
> resources until an old-style client requests one.
>
> New applications, however, can (and will using the lowlevel library) 
> use
> the IPC-method if possible. If not possible (the xclients live on
> different hosts), the old mechanism is still available.
>
> Backwards compatibility stays in tact. It's even important it stays in
> tact.
>
Ok, I think you're selling me on the proposal. If the 
clipboard-salvage-on-quit is added to Xfixes, then this IPC clipboard 
seems like a very cool optional addition, assuming the IPC method is 
exchangeable, as you mentioned below.




>>>> 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.)
>>
> I'm planning to make the IPC-part a plugin. So which IPC you prefer to
> use will be an implementation detail for the platform. I'm planning to
> implement a DBUS plugin and perhaps a CORBA (ORBit) plugin. Maybe later
> also a DCOP one. That all that are just plans at this moment. No
> promises :-).
>
This changes my objections. I don't like being tied into something like 
dbus, which is very cool, but is way overkill if I am installing it 
just so that I can have a less-buggy clipboard in KDE. If the IPC 
method is interchangeable, then this would be neat to have in a DE, 
like KDE or GNOME. It still does not address non-KDE/GNOME xclients 
(that do not use your library, or don't have it available at build 
time).




>>>> 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.
>>>
>>
>> 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.
>>
> So another shortcut between two xclients? Currently, afaik, the only
> connection two xclients can have is through X or using pipes, files,
> shared memory or an IPC-system.
>
> So then xlib would have to be patched and would need to start using
> something like shared memory blocks. And xlib-linked application would
> need to start signalling each-other to let each-other know about
> changes. Stuff like that. IMHO thats stuff an IPC-system should be
> doing, no?
>
Yes, but X does provide a basic IPC mechanism, and actually rolling 
this clipboard library into Xlib (or preferabley XCB/XCL) would make 
every application linked to a recent Xlib use the better behaviour. 
Applications would only signal eachother if you consider the selection 
owner notification in Xfixes to be one app signaling another. Then, 
requests would either send the whole deal over X, slow, or via some 
plugged-in IPC mechanism, much like what you're talking about, but it 
would require no code changes to the apps themselves, only re-linking 
to a newer Xlib. After the auto-tooled X becomes standard, I hope that 
XCL over XCB will become standard, and then with such a clean 
framework, such a plugin and change would be easy.




>>> 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?
>>
> yes
>
Why not improve X and Xlib so that all distros that use Xorg's X 
(which, by extension, should (eventually) be everybody since X.org is 
the X Consortium, no? Maybe I'm dreaming...)


>>>> 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 
>> necessary. :-)
>>
> yes, however. At this moment are applications like Klipper (gcm) using
> hacks and tricks to do the task for which they are designed. I'd be
> better if they didn't have to perform hacks and tricks to get the job
> done.
>
Why do these apps need hacks? Shouldn't the selection owner 
notification in Xfixes be all that is needed to catch and keep track of 
anything of interest? The problem is that the manager still needs to 
copy huge amounts of data, every time the selection changes.


> I've e-mailed with the author of Klipper (Aaron Seigo). A short version
> of his reply is that he's interested. He questioned the need for a
> manager daemon. And insisted that a library-approach would be used and
> the need for the manager to be reduced. So I started thinking about a
> "more library"-version of my initial thought. I can't for every problem
> remove the need for a daemon. For example the rescuing of a clipboard
> owned by an xclient that is to be destroyed.
I think that this would be a less-used feature and that integrating it 
with X would be easiest, fastest, and otherwise best. I've not said 
that X should keep a history itself, so really this rescued clipboard 
would only need to be maintained until a new selection owner appears 
(for that selection).


> I really do fear that it wont ever get solved as another x-extension.
> Mainly because people dislike touching X (except Keith, it seems) and
> because most developers feel that X shouldn't grow nor should get any
> more tasks than it already has.
>
Is Keith listening? :-D Catching a dying apps clipboard is only a minor 
addition, and rolling some IPC into the client library for the 
clipboard would actually make the X server do less work.

I've not been able to find a good (any) explanation of what ICE is. 
Isn't that some form of X-based IPC? Couldn't that be used?


>>>> 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.
>>>
>>
>> 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.
>>
> Which is what the clipboard manager would do (in my proposal) and would
> make available to Klipper using an IPC (like DBUS). The author of
> Klipper expressed his interests in this (private E-mail). Simply 
> because
> it's better when both GNOME and KDE can share it, than when both 
> desktop
> environments have to re-implement the exact same thing.
>
I also don't like the idea of a whole slew of little daemons providing 
different parts of a puzzle, that all need to be there for any part to 
work. If we assume that xclient-that-is-about-to-die owns all three 
clipboards, then the clipboard manager copies all targets for all 
clipboards. If these are big, then that's a bunch of data transfered, 
maybe over the network (depending on where the dbus daemon lives, and 
where the clipboard daemon lives, in relation to where the client 
lives). As soon as PRIMARY changes, the manager drops its cache. 
SECONDARY is usually empty, I would even say almost-always, so it is 
likely already empty. CLIPBOARD may be the longest lived, but will 
likely either be used or replaced in a reasonable amount of time. I 
think that the X server should do this saving-of-dead-app's-clipboards. 
It means no-extra-dependancies, at all, and no code changes, no new 
libraries, etc. This would be easy to do in Xfixes.
>>> 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.
>>>
>>
>> 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.
>>
> Well no. The current X11 protocol isn't designed to do transfers of
> large datasets from one process to another. When they designed X11 then
> didn't think about the desktop usage of today. Today everybody copies
> and pastes huge amounts of data from one application to another. It 
> used
> to be only very small pieces of plaintext. An IPC is (or can be)
> designed for transferring data between processes. Some can even do this
> assynchrony.
>
I, for example, use one system at work and forward my KDE apps over ssh 
from home. My X server, and any dbus/clipboard-manager daemon I used, 
would be at work, where Kwrite is at home, but Konqueror is at work. 
Lots of data over the network. Using the normal CLIPBOARD, the IPC from 
Konqueror to X would be fast, then the IPC to Kwrite would be slow. 
Using your dbus clipboard, Konqueror to clipboard-daemon would be fast, 
then to Kwrite would be slow, or without the daemon Konqueror to Kwrite 
would be slow, but slightly faster than with a daemon.

What's worse is that I have a linux box and a bsd box at home, and at 
times I've been known to forward both to me at work, so the assumption 
that most xclients are on the same host is a bad one.

I don't know about most people out there, but I rarely forward an 
entire session, so any clipboard daemon would be on the same machine as 
my X server. It might be interesting to explore using dbus 
daemon-to-daemon, basically having a clipboard daemon on every host 
that has an xclient (or more than one, but then who starts it?). I 
would assert that, in actuality, the clipboard daemonwill usually be on 
the same host as X.

Even if X is not designed for large amounts of data between clients, it 
can easily be extended to do so. I mentioned ICE above, but I'm not 
sure if that's relevant. I think writing something similar to your 
library into Xlib/XCB and implementing the daemon functions in X itself 
is the best idea, and it allows for older apps to reap the benefits 
with no changes. Apps running with an old Xlib would not get the IPC 
clipboard transfers, but few apps *today* send more than text, so it 
shouldn't be a problem. Thanx for listening :-)

JP
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2545 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20041231/f2d16453/attachment.bin