New clipboard proposal

[John Davidorff Pell]

On 30 Dec 2004, at 17:12, Philip Van Hoof wrote:
> On Thu, 2004-12-30 at 16:03 -0800, John Davidorff Pell wrote:
>
>> 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)?
>>
> There's several reasons for it. One might be that X11 already is
> designed and tends to keep backwards compatibility a high priority. For
> such a solution it would be difficult to maintain that backwards
> compatibility.
This wouldn't break backward compatibility at all. Clients would still 
only advertise the way they currently do, and clients would still 
request the selection the way they do now. The only change would be 
that the advertiser receives one request immediately after advertising 
and no more.

> Another reason with such a solution might be that for 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?

>
>> This would remove the need for a new clipboard type, advertising a new
>> TARGET,
> Advertising a new target isn't anything special. I'll take
> openoffice.org as an example. It advertises many new targets probably
> only used internally by openoffice.org.
I'm not saying that advertising new targets are bad, just that it is a 
trick that I don't think is necessary. OOo advertises TARGETS that are 
probably only used internally, but they don't need to be. Also, some 
time in the future OOo will be splitting back into separate apps, so 
they will actually use the clipboard between them just like any other 
app might.

>
>> 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.)

>> 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.

>
>> 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,
> 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?

>
>> 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. :-)

>
>> 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.
>>
> The xclient isn't altering the list of targets between advertisement of
> it's targets and providing (converting) one such target to a requester.
> Nothing about the current clipboard-handling protocol is different from
> now. Only one target is added (which is something any xclient who's
> owning the selection is allowed to do -- take a look at 
> openoffice.org's
> list of targets --). There's noting "strange" about it.
It seems like what you are proposing is to do nothing for existing 
applications, but provide a better clipboard for applications that link 
to your library in the future. I don't think that's a good idea as it 
creates a dependancy that many smaller apps will just choose not to 
include, or that many users won't install when building smaller apps. 
It also does not solve the existing problems, such as losing the 
clipboard when clients quit.

>
>> 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.
I've not read that spec, I will if someone sends me a link. :-)

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.


>
>> 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.
>>
> The most user-visible problem is the fact that many applications aren't
> providing useful targets. It's only since very recently you can copy 
> and
> paste formatted text from mozilla to evolution's e-mail composer.
That won't be solved by either solution. It can't be.

> At this moment copy/pasting between openoffice.org's calc and gnumeric
> is very buggy and won't always work.
And I hope they're working on this, but either solution doesn't do a 
thing about this.

> That problem, however, can't be tackled by any "tool" or "daemon" or
> whatever. It can be, however, tackled by creating standards and 
> agreeing
> on MIME-types.
Agreed! Ok, so an app should advertise appropriate MIME types... which 
can then be requested via the X selection routines.

>
>> For massive-data-transfer, both an X extension and some dbus  
>> implementation will require transfers of huge amounts of data between 
>>  processes.
>>
> Yes. The difference is, however, that 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.

> And another difference is that dbus is
> or can be designed to transfer huge amounts of data between processes,
> and X11 can't nor isn't designed to do that. And when the xserver is
> running on a different host, you'll need gigabit network adaptors to 
> get
> it transfer a clipboard from one xclient, running on host a, to another
> xclient also running on host a. Using host b, where the xserver is
> running. Wouldn't it be better if both xclients could send it to each
> other while not needing host b for transferring the data itself?
How easy is it for these apps to talk directly? I know that the dbus 
messages can be sent from one app directly to another, but how much 
interaction with the dbus daemon is need to do this? How easily can an 
app be written to support this?

> Some people might think there's no such thing as a huge selection. I
> think one of the reasons you still cannot copy/paste from The GIMP is
> because the protocol itself is limited in terms of scalability. I often
> do large copy/pastes. It'd be nice if I copied from mozilla a webpage
> with images, the images could be retrieved by a requester using an IPC.
> As far as I know is the current solution to let the requester parse the
> HTML and retrieve the images over http all by itself. While mozilla
> probably has them already. It can deliver those, if only some inter
> process communication between mozilla and the application requesting 
> the
> clipboard would be possible.
This is cool, and is definitely something that we all want, but a 
clipboard manger won't do this. Transferring images embedded in 
formatted text is something that must be solves by both sides of the 
transaction supporting a specified format for doing just that. D-Bus 
may make it faster in some cases, but it does not solve the problem.

>
>> 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.
>>
> I'm guessing Microsoft uses a similar technique. Probably using their
> COM+/DCOM technologies. I haven't studied it, however. So I'm not sure.
>
>
>> 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.
>>
> How does it solve the problem? It makes the user the guilty entity by
> asking him a stupid question. Of course does the user want that
> clipboard saved. Well. Perhaps he or she doesn't want it saved, but he
> or she sure doesn't want to get bothered with such a question. It's a
> computer! It should know all by itself whats best.
Should it?

> Have you ever seen
> your grandmother using a computer? Do you really think she would
> understand that question? You do you really think she knows what the
> impact would be if she would answer "No"? Perhaps you have a very smart
> grandmother. Mine sure wouldn't even read the question and would most
> likely just answer the default answer right away.
Most users just click the closest non-destructive button, which usually 
means the one that looks like the default. In this case, the app would 
do what it thinks is the best trade off: supply the information to the 
X server (or D-Bus-based clipboard manager) at the possible expense of 
time and bandwidth, or not. You still have to deal with this in your 
implementation.

> And the only difference might be the fact that the Microsoft solution
> isn't using a process. So it's more monolithic. Being monolithic,
> however, isn't the preferred design pattern for UNIX softwares. X11 is
> huge all by itself. It doesn't need yet another task (like persisting
> the clipboard of xclients that are to be shut down).
Windoze also doesn't have to worry about sending the clipboard to 
another host.

>
>> 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.
>>
> And what do you think a clipboard manager would have to do? Exactly, be
> that small watcher application that just loads its initial history from
> file before it starts watching for X selection changes.
Like klipper, but what it sounds like you are talking about is much 
much larger and requires a number of changes for a client to use it. 
That's the part I don't like. It doesn't help those of us who do not 
run a KDE or GNOME session, or who don't run entirely KDE or GNOME 
apps. That is where all my objections come from. Your clipboard manager 
via dbus doesn't address the problems that currently exist, though I do 
give you credit for trying to prevent them in future apps (that happen 
to use your library/clipboard, that happen to be on hosts where it is 
available).


If I understand you correctly, then an app that supports your 
clipboard-over-dbus that is asked to paste would check the available 
TARGETS, notice the dbus one, then ask dbus for another list of 
available formats, then choose among those? What's to stop an 
application from just ignoring the X server and going directly to 
d-bus, destroying interoperability with other apps?




Thanks for listening,
JP


P.S. I'm not on the xdg list, so I think my messages are awaiting 
moderator approval.







--
John Davidorff Pell
johnpell at mac.com



-------------- 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/20041230/306158b2/attachment.bin