Around 21 o'clock on Dec 3, Juliusz Chroboczek wrote: > Why can't klipper take the ownership of the selection, as xclipboard > does ?
PRIMARY semantics don't really permit that, and it's a large performance problem for some selection types (ever done cut&paste in the gimp?); to fully support selection content, you'd have to fetch every possible representation of the data and store it in a separate agent. Also, 'klipper' doesn't generally advertise PRIMARY; one of it's many uses is as a passive "assistant" where it monitors the contents of PRIMARY and suggestions actions based on them -- select 'http://...' and klipper offers to launch mozilla for you. For that operation, it just wants the contents in text form, but prefers to leave the actual selection resident in the original application. Remember that one of the chief benefits of selections is that the data doesn't actually get transfered through the X server until it's requested, so applications are free to advertise selections for things which will probably not ever be copied to another client. > (I'm not arguing against this extension, as I think that making > client-visible state changes observable is a Good Thing. Just idle > curiosity.) I've struggled with the current protocol for 15 years without this notification; there's no doubt in my mind that it's a good idea. I'm not the originator here either, although I'm a bit fuzzy as to whether it was Havoc Pennington or Owen Talyor that suggested it a couple of weeks ago. One of the problems of doing design meetings via IRC is that you don't automatically get a permanent record. Keith Packard XFree86 Core Team HP Cambridge Research Lab _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
