Path: utzoo!yunexus!geac!david From: david@geac.UUCP (David Haynes) Newsgroups: comp.windows.misc Subject: Re: Cut-and-paste (was Re: sharedx and remote conferencing) Message-ID: <3154@geac.UUCP> Date: 12 Aug 88 14:18:18 GMT Article-I.D.: geac.3154 References: <5411@eagle.ukc.ac.uk: <5442@eagle.ukc.ac.uk> Reply-To: david@geac.UUCP (David Haynes) Organization: Kaos - Total and Utter Kaos Lines: 81 In article <5442@eagle.ukc.ac.uk: rjf@ford.UUCP (R.J.Faichney) writes: :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. This is very confusing since you use the terms "interface" and "functionality" without defining what you mean by those terms. However, if I take your implied definition of each as "interface" being that component handled by a UIM (User Interface Mechanism) and "functionality" as that component representing the application logic of the program, then I disagree with you quite strongly. 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. In what sense? Yes, it should be in a state to accept input into a given area, but how is this different from accepting input from a keyboard? If your assertion is that the pasting of, say, a piece of a spreadsheet is, in itself, more complex than that of a keyboard, then yes, the logic in the "functionality" must encompass this eventuality. However, there would be effectively no difference between this manner of data acceptance and the traditional byte stream from the interface approach. (Basically, one program send data, one program listens attentively) : 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. Yes, the addition of cut and paste capabilites requires more functionality to be added to the application - I doubt that anyone disagrees with that, but to the level of proposing a separate communications path? For the most part, this is absurd! If you stop to consider all the applications for which you might want to communicate and the resulting complexity of setting up distinct (efficient) communication between them all, it should become quickly apparent why this approach is unwise unless there is another factor (bandwidth, data complexity, etc) to justify the special relationship between the applications. :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, instead we couple these programs together via a specialized communication link (let's say they are a word processor and a spreadsheet) And I acheive good communications between them. (I now have one communications link) Now I introduce a Rolodex database to the system. (my communications connectivity is now 3) Now I add a diary/tickler component, (now my connectivity is 6!) now I add electronic mail (connectivity is 10!) and so on. The point is: For a generalized cut and paste facility, the only intelligent way to achieve this is via a byte streams from the user interface. Any other mechanism soon grows to be unwieldly. Remember, as each new component is added, the complexity of each program increases (an ugly thought). :So I say 'Cut cut buffers out of X -- and the rest'. Who would argue? Looks like I would. -david- :Robin Faichney ;-)