marcs@SLC.COM (Marc San Soucie) (03/07/91)
Kee Hinckley writes: > Also, does anyone have any suggestions on the correct behavior of > Paste when there exists both an item in the clipboard and a primary > selection? It's all very fine to say that Paste pastes from the clipboard, > but that's not going to be obvious to the user trying to copy something > from an xterm. I'm going to take the liberty of re-posting something Ellis Cohen sent to motif-talk in May last year, in reply to some questions of mine that were similar. My questions are the indented bits. Ellis' replies are unindented. I have additional comments after... -------- From: uunet!osf.org!ellis To: motif-talk@osf.org Subject: Re: The MOTIF Clipboard Date: Mon, 21 May 90 11:18:53 -0400 > We have been reading through documentation, source code, and archives of > old motif-talk and have not seen much discussion of recommended policy with > regard to the MOTIF clipboard. We may have missed something along the way, > so we'd be happy to be educated. > > . Does OSF have any currently published description of what clients should > be doing with the clipboard? The Motif clipboard is more general than the standard ICCCM model (though it is ICCCM-compliant) in two way. It allows an item to placed on it in more than one format, and it allows the placement of one or more of the formats to be deferred until there is a request to retrieve the format (for the purpose of pasting it). If a client can only retrieve data in one format, it simply asks for that format; but if it can accept data in more than one format; it should use the XmClipboard rotines to find out what formats are availaable on the clipboard, and choose an available one. If more than one available format is acceptable, it should choose the first one listed. This implies that if a client places more than format on the clipboard as deferred, it should place the easier to generate ones first. How many formats should a client provide? That needs to be considered on a case by case basis. In the case of a spreadsheet, I'd think of storing in it in some commonly used spreadsheet interchange format. I'd also use a text format, concatenating the data together with spaces separating columns, with each row on a separate line, for people who want to paste the spreadsheet into a text editor. Finally, I'd store it as a bitmap, for people who want to paste the spreadsheet into a desktop publishing client that does not understand the spreadsheet interchange format. The next question is which of the formats should be stored immediately, and which should be deferred. The advantage of storing data immediately is that the data remains available on the clipboard even if the client that placed it there crashes or exits. The disadvantage of storing data immediately is that it takes up space unnecessarily (and in the current implementation, for crash recovery, it takes up server space). In addition, generating a data in a particular format may take substantial time, which may be silly if it is to generate a format that may not subsequently be retrieved. The application writer needs to consider these tradeoffs carefully in making a decision, and may even wish to pass the decision on to the end user as a resource. For the one Motif widget that does clipboard operations -- the text widget, we decided in favor of robusteness; when it cuts or copies selected text to the clipboard, it does so immediately. > . Is there a pending publication of some policy guidelines? Not until the next revision of the Motif Programmer's Guide, which will be some time in the future. > . Are other clients out there making use of the clipboard? In what fashion? I don't know for sure; but I'd expect that developers are building a large number of new widegts that support selection. Whenever selection is supported; these issues need to be faced. > If I select some text in a client application, and, leaving it highlit, move > to a MOTIF text widget and Paste, will the text widget yank the currently > selected text (the XA_PRIMARY selection), or the next-paste item on the > clipboard? Doing a PASTE will yank the contents of the clipboard. There is also a PRIMARY_PASTE operation (Btn2 Click) which will paste the current selection (the thing that is highlighted). > . How is use of the clipboard expected to interact with use of X/Xt > selections? The Motif clipboard is ICCCM-compliant, so it uses the CLIPBOARD selection. However, Motif clients should not use X and Xt routines directly to deal with this selection; they should use the XmClipboard routines. As the ICCCM notes, a clipboard can either be implemented by either having a separate clipboard client which holds onto the selection contents, or by having the CLIPBOARD ownership and contents held by the client who last placed their selection on the clipboard. The implementation of these models is different (as indicated in the ICCCM), though they can interoperate with one another. Motif is likely to move from the client ownership implementation to a separate clipboard process. Using the XmClipboard routines will make such a change transparent to your code. > . Is there a MOTIF clipboard client for viewing and manipulating the contents > of the clipboard once things are stuck there? Not at present. When we move to a separate clipboard process, it is possible that it will include code for viewing and manipulating the clipbaord contents. -- Ellis -------- Marc again. I find this more than a bit unsatisfactory, since use of both the clipboard and the primary selection requires some configuration work for the user, as things like PASTE are not always bound by default to keys or clicks. Plus, it requires forethought on the part of the user as to where the pastable data is stored. Our solution, at least for a while, was to create an interface layer which, in response to a call to the paste routine, would attempt to paste the primary selection first, and failing that, look for something on the Motif clipboard. While it worked in principle, it was ungainly and subject to failure whenever Motif conventions changed. Even so, it's probably the best compromise. Marc San Soucie Servio Corporation Beaverton, Oregon marcs@slc.com