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 ;-)
rnv@motsj1.UUCP (Ron Voss) (08/11/88)
R.J.Faichney (rjf@ford.UUCP) writes: > >So I say 'Cut cut buffers out of X -- and the rest'. Who would argue? > Ok, I'll bite. Doesn't making the applications worry about all this complicate them, make them all larger? As for the transformations, I don't care, I think. It's not a performance issue, since the CPU is faster than the hand. I am used to the way the Mac works; it seems intuitive. I don't hear you stating an advantage of getting the cut buffer out of X, I just hear your preference. -- Ron Voss, Senior Systems Engineer, Motorola Microcomputer Division UUCP: {hplabs,mot,oakhill}!motsj1!rnv CIS: 73647,752 Tel: 408-991-7390 Snail: 1150 Kifer Road, Sunnyvale, CA 94086 Opinions: Mine, not necessarily employer's.
david@geac.UUCP (David Haynes) (08/12/88)
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 ;-)dwiggins@ashtate (Don Dwiggins) (08/14/88)
In article <5450@eagle.ukc.ac.uk> rjf@ford.UUCP (R.J.Faichney) writes: >PS Maybe I should make what I'm suggesting a little clearer: the major >distinction between the current X way and my way is that in the latter, >the comms channel is between functionalities, instead of >functionality-interface-Xserver-interface-functionality. So >functionality retains full control over it's data, and interface does >only what it was designed for - channelling information between >application and user (plus, incidentally, arranging the sharing of >interface facilities through the windowing system). Protocols for doing that sort of thing are beginning to appear, e.g. Sun's XDR, Microsoft's (or is it IBM's?) DDE, etc. The basic idea is machine-independent representation and transmission of complex data, controlled by a cooperating producer and consumer. Nothing in this requires or precludes UI involvement. Given that such a facility exists, however, it's useful for the UI at some level (window system, UIMS, or what have you) to know about it, so that it can use it to support the Cut-and-paste metaphor and perhaps offer other visual ways to coordinate data transfer across applications. -- Don Dwiggins {scgvaxd,crash}!ashtate!dwiggins
rjf@eagle.ukc.ac.uk (R.J.Faichney) (08/18/88)
In article <3154@geac.UUCP> david@geac.UUCP (David Haynes) writes: >In article <5442@eagle.ukc.ac.uk: rjf@ford.UUCP (R.J.Faichney) writes: >: >: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. Going by what follows, you seem to have worked it out. >: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? There may be no great difference as far as the functionality is concerned, but there is certainly a difference for the interface. >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. Just what degree of complexity are we discussing? How efficient does this have to be, given modern machine capacities? 'Special relationship'? You seem to be trying to make this seem more difficult than it is. You say it is apparently unwise, but I've done it. Admittedly it has not yet been tested under a very heavy load, but it seems OK so far. And it does lots of other things besides cut-and-paste: connections and discrete messaging, transparent networking, find details of other applications, 'wild cards' in addressing, etc. (Incidentally, networking for inter-functionality comms is particularly difficult to do via a system where the server is tied to a display which is quite irrelevant. I know -- I've tried it.) >[About increasing 'connectivity' for increasing numbers of applications] > >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). There is very simple answer to this: instead of a fully interconnected net of applications, have a communications server, with just one connection to each application -- like a telephone exchange. Which is how I've done it. Both discrete messaging and direct connections are easily simulated using server-mediated connections. In article <532@ashton.UUCP> dwiggins@atsun.UUCP (Don Dwiggins) writes: > >Protocols for doing that sort of thing are beginning to appear, e.g. Sun's XDR, >Microsoft's (or is it IBM's?) DDE, etc. It's Microsoft's. Though protocols are at least as important as what I've been doing, possibly more so, and highly relevant, we're actually talking apples and oranges here. I don't know much about DDE, but XDR is all about communicating structured data. I've been concentrating on a mechanism for communicating unstructured data which could have more sophisticated facilities built on top, but which made addressing in particular easy for the application programmer, and had the other facilities mentioned above. Aside from data structure, dp is higher level and of much wider functionality than XDR, and more flexible, more portable and of wider functionality than DDE (I believe). And the structured data facilities can be easily added. Though I should add that dp is aimed more towards applications which have been cooperatively designed (or, I would say, cooperatively had minor modifications made) than either DDE or XDR. You pays your money.. >The basic idea is machine-independent >representation and transmission of complex data, controlled by a cooperating >producer and consumer. Nothing in this requires or precludes UI involvement. Agreed. It is at a lower level than the interface/functionality distinction. >Given that such a facility exists, however, it's useful for the UI at some >level (window system, UIMS, or what have you) to know about it, so that it >can use it to support the Cut-and-paste metaphor and perhaps offer other >visual ways to coordinate data transfer across applications. If the UI/window system wants to use it 'internally', why not? But it shouldn't encroach on what is, in principle, application functionality stuff. See above and elsewhere ad nauseum. Also remember the ;-) in the original posting. I'm not seriously suggesting that cut buffers should be removed from X -- just that to use them is to compromise (however slightly) a generally accepted principle of software engineering: that of maximal separation of user-interface from application functionality. Some I/O is user I/O, some is like user I/O, some is nothing like user I/O. I have something which handles the latter two equally easily, therefore, with the window system, covering all inter-program comms requirements. If you insist the the former two belong together, I won't argue anymore -- it's just a little less work for my system to do. Robin Faichney
janssen@titan.sw.mcc.com (Bill Janssen) (08/19/88)
I doubt that the window system has to know about the actual format, though
it might know that the data stored in a "cut-buffer" is stored in some one
of various available formats, and be able to say which format that is
to another application that asks. `Andrew' data-objects have a nice
protocol for this; you can cut data from the editor running under one
UNIX process and paste it, including all styles and imbedded objects,
into a different incarnation of the editor in different UNIX process.
It would be nice to support some standard semantics for different kinds
of cuts. For example, it would be nifty to be able to `pick up' an object
in one application and `drop' it into another application. Presumably
this would involve a pointer-grab, changing the pointer cursor EVERYWHERE,
and sending an event to the application under the pointer when the button
is released, saying something like "An object of type FOO has been passed
to you from application BAR, here's the data: ..." or "data is in
cut-buffer 3" or some such.
Bill
--
Bill Janssen, MCC Software Technology Program
ARPA: janssen@mcc.com
UUCP: {seismo,harvard,gatech,pyramid}!ut-sally!im4u!milano!janssen