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