From: johnsd2@jec322.its.rpi.edu (Daniel Norman Johnson)
Subject: Re: Why Macs are better (and the others aren't)
Reply-To: johnsd2@rpi.edu
Organization: Rensselaer Polytechnic Institute, Troy, NY.
Date: Wed, 30 Sep 1992 18:00:07 GMT

In article <strobl.717865111@gmd.de>, strobl@gmd.de (Wolfgang Strobl) writes:
|> 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]
|> 
[deletia- Pooh on Excel]
|> >|> 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. 

Yes, you DO want it to go away; you also want to to appear
somewhere else. The cut+paste thing does it in to separate
actions.

|> >|> 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. 

Which would happen anyway, if you just move the block. To fix
this, you need a mechanism to re-point the dependant cells;
There is no reason that this could not be implemented with
normal cut and paste (it just means remembering where
teh cells came from)

|> >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.

You dont loose data (its in the clipboard; If you disturb the clipboard
u can use Undo to get it back); The reference problem also happens
to one-step moves.

|> >|> 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.

You dont need direct moves to handle reference updating.

|> 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. 

Drag&Drop is implemented in addition to the cut&paste thing, and
doesn't interfere with normal cutting and pasting. Ive no problem
with that.

[deletia- cliboard formats]
|> 
|> >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.  

There are 2 of them. (3, if you count quicktime); What's wrong with this?

|> >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.

It was not even designed for that. It origionally could only
run ONE app at a time- no switcher!

|> 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. 

Well, you haven't convinced me. (I agree the single menu bar isn't
a good idea on a multitasking system; to confusing. But its
too late now)

|> >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.

Certainly, this is nice but its not a big deal, as long as your
standard formats are good enough. Incidentally, its not completely
free. When an app which owns the clipboard exits, it must generate
all of its formats.
 
|> >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.

That doens't help me much; care to elaborate?

|> >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.

Sure ya can. Why not?

|> >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.

No wonder you need the clever rendering technique. So many format!
But you dont have an object based image format (PICT can do that, too)

|> 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.

Agreed.

-- 
			- Dan Johnson
And God said "Jeeze, this is dull"... and it *WAS* dull. Genesis 0:0

These opinions have had all identifiying marks removed, and are untraceable.
You'll never know whose they are.
Organization: Sophomore, Physics, Carnegie Mellon, Pittsburgh, PA