[Spam] Re: Some idea's for "clipboard-manager" (xfixes)
spam at micropp.se
Mon Apr 4 00:39:01 EEST 2005
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
>>> 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
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
>Cool idea. But that can be implemented using the current X clipboard,
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
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.
More information about the xdg