From: strobl@gmd.de (Wolfgang Strobl)
Subject: Re: Why Macs are better (and the others aren't)
Organization: GMD, Sankt Augustin, Germany
Date: Wed, 30 Sep 1992 14:58:31 GMT

In <qdkzdx#@rpi.edu> johnsd2@lib106.its.rpi.edu (Daniel Norman Johnson) writes:

>In article <strobl.717780436@gmd.de>, strobl@gmd.de (Wolfgang Strobl) writes:
>|> In <+!kz16n@rpi.edu> johnsd2@jec306.its.rpi.edu (Daniel Norman Johnson) writes:
>[deletia- Cut&Paste]

>|> >Nonetheless, it should (as I understand it) behave like you were
>|> >copying something to a clipboard, and pasting it out again. That
>|> >you can paste the same data in different formats matters not at all
>|> >to this. Frequently, as you mention, the format is determined by the
>|> >application being pasted to. The difference between the Macnitosh
>|> >"copy all formats to the clipboard, paste whichever is appropraite"
>|> >and teh Windows "don't copy anything to the clipboard until it is needed
>|> >or the clipboard-owning app exits" is internal. (and has nothing to do
>|> >with the Excel cut+paste problem I was complaining about)
>|> 
>|> I disagree. Excel is both a good and a bad example. It is a good example
>|> because it illustrates something which can only be done using the
>|> Windows model of the clipboard. It is a bad example, because it doesn't
>|> get it right.
>|> 
>|> Excels "nonstandard" implementation of the clipboard you complain about
>|> is probable caused by the fact that it delays the actuall cutting
>|> (i.e. removing) of the source cells until you actually paste the cells
>|> to another part of the sheet. This is indeed a bit different from how
>|> it works for example in edit fields. But it has one  advantage:
>|> there is no inconsistent, intermediate state of the sheet during
>|> the time the cutout is parked in the clipboard.

>There is nothing inconsistent about this state. Its a perfectly
>good state. :) Nothing strange about it at all. If you do
>a cut, it is part of what you want (ie, the selected stuff
>goes away)

:-)

But you don't *want* it to go away. Most of the time, you just
want to move it to another place. 

>|> Its all done in one,
>|> single, atomic operation: the source cells become empty, and at the
>|> same time their contents appear at the destination.

>This is SPECIFICALLY what Cut+Paste was origionally devised
>to avoid. After you "cut", the worksheet is in a special mode.

If Excel would implement it the way you suggest, the mode that it
would be in,  between cut and paste,  would be much more special, 
because all cells which point into the cut out area would
be dangling during that time. 

>If you aren't in that mode, you can't paste. If the mode
>was completely invisible (ie it was strictly an implementation
>thing) this would be fine. But the user CAN see it in Excel;
>if you try to do anything after a cut or copy, the cut-selection
>gets foozled, and you cant paste.

The alternative, that you loose your data or the structure of 
your sheets (because the references get mangled), seems much
worse to me.

>|> This is how it
>|> works if you cut & paste within a single sheet. Windows implementation
>|> of the clipboard would make it possible to extend this very behaviour
>|> to the interapplication case. Unfortunately, they didn't do that,
>|> perhaps in order to get an uniform behaviour on both platforms.

>Well, they didn't get uniform behavior. And as far as I know,
>Excel spreadsheet data is the only thing trhat gets treated
>this wya- if you are cut&pasting text in an edit text box or
>word processor, Cut&Paste works like on the mac. Is this incorrect?

No. I don't know any word processor which implements direct references
within the data, which have to be adjusted, so this isn't a very
good example, though.

Btw, drag&drop within Word for Windows 2 works quite similar:
you select something, then drag it to another place. When you
drop it, the selected range of characters disappears at its
original place and appears on the drop point. 

> 
>|> Another point is, that "copy all formats, paste whichever is appropriate"
>|> is only feasible if the number of different formats is quite small, and
>|> if the amount of data in each format is so small that it doesn't matter
>|> much, and - more important - if the actual rendering of all these
>|> different formats doesn't cost much time. In practice, this means that
>|> in the case of the simple clipboard model, you have to choose between
>|> disadvantages - ask the user which format he wants to cut, don't 
>|> use more than a few formats, or let the user buy a new computer be-
>|> cause the cut operation takes so long.

>You don't use Macs much, I guess. This easily got around by using
>a few, standard formats. Apps generally write their own private
>format, and either Text (+ styl, if styl info is included) or
>PICT.

They easily go around by using a few, standard formats, because they
have to, so this doesn't prove much. What if applications not 
only write a private format, but a documented exchange format with
full content, in addition? This greatly enhances interapplication
communication. But suddenly, you have n formats for n applications
(Excel does BIff3, Lotus Wk1, and so on..). Surely one could cut
this down a bit, when similar applications aggree about a common 
data format, but there still remain a lot of them.  

>This conversion, incidentally, is only done when the app is switched
>into the background.

This proves that the Mac OS wasn't designed for running multiple
applications concurrently, from the very beginning, but for 
application swapping, with only one visible, running application.

I have nothing against simplicity, but it's my impression that
the simple minded clipboard implementation on the Mac is a 
bug (a short-sighted design) sold as a feature. Same for the
single menu bar at the top of the screen. 

>If this one conversion is very slow, thats a problem but the Windows
>technique wont help; You still have to do the conversion. Its just
>a question of WHEN.

No, it's a question of whether you have to do it at all. This is
the big advantage of the clipboard rendering driven by the
receiving application (in fact a communication protocol between
two running applications): the sending app can offer a seldomly
used and slowly to generate format on the clipboard for free.

As long as it isn't used (i.e. as long as the user doesn't
paste into an application which actually requests that format),
the user isn't hampered by that. In fact, he doesn't notice
it at all, it's completely invisible.

>The clipboard data will also be shuffled to disk as necessary, and
>the recieving app will only reload what it wants to use. (I _think_;
>not entirely sure about that point)

In a way, Windows handling of the clipboard is like Unix handles
pipes, while the Mac OS seems to do it like MSDOS implements pipes.

>This means that (a) you dont have rediculous amounts of data,
>(b) cut/copy is fast (not much rendering- usually only 1 render, from
>the internal format to TEXT/styl or PICT) and (c) Apps only have
>2 formats they must support (actually, they are not requried to support
>the styl part of TEXT/styl.. just ascii text); So they DO support it.

As I said, you CANT have huge amounts of data, given that implementation.

>I have heard that Windows does not have a standard image or formatted-text
>format, so Apps just have to wing it. And that means lotsa formats, if
>you want to have it work. (unless, of course, I am wrong about that)

There are two standard image formats (metafile and bitmap), two
unformatted text formats (Windows has to support the old IBM PC
codepage in addition to its Ansi coding - the clipboard can convert
between the two), at one standard formatted-text format (rich text).
The only fault I see is that the rtf format is a quite late addition
to the format repertoire. Write, for example, still doesn't support
it (even in version 3.1), so anything you cut out in Write and
paste into Word gets pasted as unformatted text, so one has to go
through the insert file conversion process, which is an unnecessary
complication if one only wants to copy a few words.

Most applications supports these formats, and there are a lot of 
other formats understood by one or a few applications. Excel, for
example understands and writes many foreign spreadsheet formats
via the clipboard. This is nice - if I happen to have some
utility which only understands Lotus format, this doesn't prevent
me from cutting and pasting between Excel and that utility.

Wolfgang Strobl
#include <std.disclaimer.hpp>
Newsgroups: comp.sys.mac.advocacy