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