[Spam] Re: Some idea's for "clipboard-manager" (xfixes)

[Lars Hallberg]

Axel Liljencrantz wrote:

>On Sun, 2005-04-03 at 21:54 +0200, Lars Hallberg wrote:
>  
>
>>Philip Van Hoof wrote:
>>
>>    
>>
>>>My idea for this "clipman" thing was/is to allow applications to share 
>>>their clipboards using DBUS rather than letting them use X11.
>>>
>>>Why I'd like to use a direct peer to peer connection (using DBUS) 
>>>between twee clipboard-capable applications?
>>>
>>>    o. This way applications who are clipboard capable don't have to 
>>>link with xlib
>>>        (console applications)
>>>
>>>    o. On a networked x11 deployment (xserver remote, xclients on the 
>>>same host, XDMCP)
>>>        this improves performance by eliminating the need to go over 
>>>the X11 socket with that
>>>        data
>>>
>>>Why DBUS?
>>>
>>>    o. Everybody (including KDE developers) loves/likes DBUS.
>>>    o. And perhaps not everybody loves it. Still, nobody "hates" it.
>>>      
>>>
>
>Are the reasons outlined above strong enough reason to abandon the X
>clipboard?
>  
>
I'm not talking about *abandon* it. Rather improve it.

>Applications don't have to link with xlib. I've written a shell that
>uses the X clipboard to perform copy and paste without including any X
>specific code in the shell itself.
>
But You still need a xserver runing?

>>Intresting, but I like to expand the idé beond clipboard. A D-Bus based 
>>'typed' data transfer and converting mekanism can have broader use, that 
>>in the end will solve problems for the clipboard to.
>>
>>Think D-Data, A D-Bus service that know about other D-Bus services that 
>>can convert data from type foo to type bar. A set of 'Data conversion 
>>services' (DCS for short) that can loaded on demand and be combined much 
>>like g-streamer works (but not so latancy/real time critical). The DCS 
>>could also be able to write data of some types to files of some types, 
>>and to read files of some types turning it to data of some types.
>>
>>Apps provide one or several DCS for the datatypes it use. The app it 
>>self *can* be the DCS but it make sens to make them separate. Makes for 
>>leaner and cleaner apps that only works with its own native format. 
>>Further, a DCS need not depend on X, and D-Data might be usefull outside 
>>the desktop (stuff like a CMS). An app might ask D-Data to preload its 
>>most common DCS on startup, or leve them to be loaded on demand.
>>
>>If one DCS suport a given data or file format, an that or other DCS can 
>>convertit to 'plain text', any text processing app can suport that file 
>>and data type. More functionality everyvere, more integration, more code 
>>reuse, less duplication of effort.
>>
>>Complex DCS, like ocr might be writen. Then a scanner app can save ocr 
>>transformed scans to any wordprocessing fomat  having an DCS on the 
>>system, or directly to the clippboard, or possably directly to a runing app!
>>
>>It's a lot of featails to think thru... but I think it would be realy 
>>usefull, and the 'right' way to get rich datatype integration to work 
>>between apps.
>>
>>    
>>
>
>Cool idea. But that can be implemented using the current X clipboard,
>couldn't it?
>  
>
But it's usefull for so much more. Like a webbased dokument handling 
system wher you probably dont have an xserver on the server that need to 
convert dokuments. Or fore stuff like import and export functionality in 
applikations. Having nothing to do with clippboard.

>Maybe I'm missing something, but it sounds like you both have a lot of
>good ideas how to improve the clipboard, but I don't see why you would
>have to defenestrate the old X clipboard to implement them.
>  
>
My idé is to:

1) Create this new functionality for generall purpus data conversion, 
transfer, save and read (D-Data).

2) Make it's relevant functonality avalible thru old x clipboard 
protocoll thru a D-Data avare clipboard manager.

3) As a side effect, the clipboard only need to save the 'richest' data 
target, and the original app need not run to be able to convert to other 
targets.

However, *if* both applications in a cliboard interaction is D-Data 
avare, it *might* make sens to copy the data directly over D-Data. 
Depends on how sane that are to implement. It would be a big win when 
copying big data using a remote x-session.

/LaH