rjf@eagle.ukc.ac.uk (R.J.Faichney) (08/08/88)
In article <5411@eagle.ukc.ac.uk> I (rjf@ukc.ac.uk - Robin Faichney) wrote: >[About how remote conferencing had nothing to do with sharedx as the >former is application functionality and X is part of the user-interface.] In order to complete the picture I'd like to add just a little to what I said before. (Also because of a certain lack of response so far!) If we try to strictly separate user-interface from the (rest of the) application functionality we come across certain problems in deciding just what goes where. One of the most difficult is cut-and-paste. My view is that this is part of the functionality, not the interface. OK, if you merely copy something from one application, that application need not know, nor do anything about it - but the one at the other end certainly should. And if you are doing a move rather than a copy, both ends need to be fully aware of what is going on. It seems to me that these operations are generally part of the functionality, and in principle no more closely associated with the interface than any other part of the functionality of an interactive application. So why does X, like other windowing systems, provide 'cut buffers' and such stuff? I think that it's purely historical: because cut-and-paste was originally a functional accretion, designed to automate what a user had formerly done manually, it was convenient to bung it into the user-interface and fool the application into believing that it was still a simple user-action. Instead of having applications talk directly to each other in a language both understand, the stuff is piped through two user-interfaces, resulting in at least two redundant transformations. So I say 'Cut cut buffers out of X -- and the rest'. Who would argue? Robin Faichney ;-)
Kimbrough@dsg.csc.ti.COM (Kerry Kimbrough) (08/10/88)
> So I say 'Cut cut buffers out of X -- and the rest'. Who would argue?
I'll pick up the gauntlet. Actually, I agree with you -- the semantics of
cut'n'paste is a client function. In fact, it's not really accurate to say that
cut buffers are "in" X. The most you can say along this line is that the X
protocol predefines the atoms PRIMARY, SECONDARY, CUT_BUFFER_0, ...
CUT_BUFFER_7. However, the meaning and use of these atoms are left completely
undefined.
Certainly, cut'n'paste, as it is commonly known, is a user-initiated operation.
That is, it must have *some* user interface. Specifically, the clients
participanting in the operation (the cuttee and the pastee) are addressed by the
user via their user interfaces: "Cut from here and paste to there". Since the
participant clients are sharing an X server and since X provides a client
channel that is independent of the communications hw/sw layers, it's eminently
practical to use the server as the intermediary in cut'n'paste. That is, cuttee
sends a message to the server to store the cut info, pastee sends a message to
the server to retrieve the cut info. That is how the PRIMARY, SECONDARY,
CUT_BUFFER_0, ... CUT_BUFFER_7 property atoms are intended to be used (although
even this is merely a well-known inter-client convention and not a "feature" of
X). But clients are responsible for defining the user gesture to perform the
cut/paste, for figuring out exactly what info is to be cut, and for figuring out
exactly what is to be done with the cut info when it is retrieved.bala@mozart.att.COM (08/10/88)
rjf@bloom-beacon.mit.edu writes: > It seems to me that these operations are generally part of the >functionality, and in principle no more closely associated with the >interface than any other part of the functionality of an interactive >application. >So why does X, like other windowing systems, provide 'cut buffers' and >such stuff? apart from historical reasons it is a useful short cut (used heavily). it is a pure editing operation - not too dissimilar to yanking region between emacs windows. cut-and-paste stands on the fine line between functionality and interface. in some sense it is interface as everyone understands it without having to be taught :-) it is functionality as both applications become aware of it (though, both may not know about it right away). some operations (like c-a-p) are very natural and have thus ended up in interfaces. you will notice the trend that as operations become generic they migrate to the interface level (what happens underneath may vary with application). if you have a specification for a language that random applications can use to talk to each other in the interactive sense i would like to hear about it. cheers, bala
rjf@eagle.ukc.ac.uk (R.J.Faichney) (08/12/88)
In article <8808092002.AA05085@ATHENA.MIT.EDU> bala@mozart.att.COM writes: >rjf@bloom-beacon.mit.edu writes: > >So why does X, like other windowing systems, provide 'cut buffers' and > >such stuff? > >[about short cuts (!), fine lines, natural operations and migration] Please see my latest article in comp.windows.misc - which is where I directed followups to the one you quote, as well as this! >if you have a specification for a language that random applications >can use to talk to each other in the interactive sense i would like to >hear about it. Wouldn't we all? You won't find the word 'random' in either of my original articles. In fact I'm fairly sure that such a thing is impossible. I'm into the medium more than the message at the moment. (And they are *NOT* the same!) (Though I'll admit you could call a language a medium - by the same analogy I'm talking about prefering one telephone network over another.) By the way, I suggest you see your news person about that strange address you've given me. Robin