Re: CMSDA
Re: CMSDA
- Subject: Re: CMSDA
- From: Charles Srstka <email@hidden>
- Date: Mon, 25 Mar 2002 12:55:37 -0600
On Monday, March 25, 2002, at 05:29 AM, Ondra Cada wrote:
>
On Monday, March 25, 2002, at 09:31 , Charles Srstka wrote:
>
>
> However, why must people have this attitude that the old Mac OS was
>
> therefore garbage and didn't have any nice features at all that we
>
> might want to keep? Where does this animosity come from, anyway?
>
>
Well, it is of course not true (in both ways: people -- save perhaps a
>
very small number of exceptions -- have not that attitude, and the
>
Classic was not *entirely* garbage).
>
>
The point of many of us who knew NeXTStep well though is that
>
- there are almost no cases when a solution of NeXTStep was used in Mac
>
OS X although there was a better solution in Classic (*);
>
- alas, there is a VAST list of cases where NeXTStep was very far
>
better, but the Classic solution was used anyway.
>
>
That is what might lead sometimes to bitter speak which migth give an
>
impression of the quoted attitude indeed.
The interesting thing about this is that if you asked many long-time Mac
users, they would tell you just the opposite - they will complain that
NeXT has taken over Apple, that Steve Jobs really wants to advance his
NeXT vision at the expense of all the features that made the Mac
special. You will hear about many Mac behaviors that they consider to be
superior which were replaced by NeXTisms/UNIXisms. Some examples are
Finder issues, as you mentioned (spring-loaded folders replaced by a
stripped-down version of the NeXT shelf and Windows copy-and-paste), but
there are other non-Finder-related points as well, such as using
filename extensions for determining file types and hiding them from the
user so that two files in one directory can appear to have the same
name, using hard-coded paths instead of FSRefs and aliases in many
places, things breaking left and right if you move apps, as well as
other, smaller things, like the behavior that Cocoa apps exhibit when
selecting the end of a line, flavorTypePromiseHFS, etc. Of course, the
NeXTStep veterans will probably have different opinions about these
issues (as I am already aware from many posts in macosx-dev on the
omnigroup lists - so please don't flame me about this - it's only an
example), and the thing we need to remember is that not everyone has the
same ideas about what is better and what is not. For example:
>
Let me introduce as a nice example one GUI element which Apple
>
seriously messed up: object drag and drop into text. It always used to
>
work so that if an object was dropped over the text window, it was
>
always placed *at the insertion point*. Now, the insertion point moves
>
to the place the mouse cursor is over.
>
>
I don't know whether those people who are responsible for this nonsense
>
actually thought that NeXT programmers were not able to move the
>
insertion point as mouse moved, and so they thought they are improving
>
the thing?!?!?!? Gosh.
>
>
Pity they instead did not consider *WHY* the behaviour was such: how do
>
you normally d&d an object into a text? Of course, you write the text
>
up to something like "...and here is the nice movie for you:", then
>
select the source window for the object (usually Finder, though not
>
necessarily), and then want to d&d it into text. You can't though,
>
since the place the object belongs to is almost surely obscured by the
>
Finder window now! You can't activate the text window before drag
>
either, since it is just as probable _it_ would obscure the object in
>
Finder instead. So, due to this,
>
ahem, not thought through, decision any d&d-ing means perpetual, and
>
in a decent GUI as NeXTStep had quite unnecessary, moving of windows --
>
read it a serious, very serious time loss :(((((((((((
From the standpoint of a Classic MacOS user, the reasoning behind this
is simple. What happens when you drag text around in a window? It goes
where you drop it. If it went to the insertion point, it would not move,
since the insertion point is going to be at the chunk of text you are
dragging. Therefore, dragging files into a text block works the same
way, because there is something to be said for consistency of the
interface. We are dealing with new users using the OS now, which may not
have been the case as often with NeXTStep, and new users are going to
expect that if something works one way one time, then it should work
that way all the time. It's difficult to explain "Well, if you drag this
here, it will go here, but if you drag this here, it will go somewhere
else." to someone who's still working on getting the hang on the concept
of d&d in the first place...
>
Well, that's just one example of many, many, many similar ones, and
>
that's why sometimes people who knew NeXTStep well might in their
>
natural angst caused by this serious crippling sometimes sound as
>
"whole Mac OS Classic was a crap", although it is of course not true
>
and they know quite well that it is not true.
This is understandable, and on the other side it also sometimes causes
old MacOS users to have some ill will toward NeXTStep for the same
reasons. We're really sort of in the same boat here... perhaps we need
to look objectively at each other's OS, realize the things from the
other side we'd like to have back, and then all get together and ask
Apple for the features in *both* OS's that we want in Mac OS X. In my
idealistic little world, I'd like to see Mac and NeXT users come to
compromises on the points on which we disagree instead of going off on
our respective sides of the holy wars (I'm referring to the old "Great
Schism" thread on macosx-dev, among other things), but I'm not sure how
that is going to be achieved. One good example of a compromise (imho) is
the new Cocoa NSDocument behavior - it keeps track of the currently open
file, and if the file is moved or renamed, it still knows where it is,
probably through the use of an FSRef or an alias, since the . If the
file is moved, a dialog box comes up asking the user whether they would
like to save the document to the new location or create a new file
somewhere else, thereby allowing both the old-school Mac behavior of
being able to move and rename an open document without breaking things
as well as making it impossible to accidentally overwrite a different
file than the one you expected to write to. But I'm rambling...
>
To return more on topic: the Classic API, today -- after some
>
extensions, improvements, and changes for better portability -- named
>
Carbon, *IS* a very ugly garbage entirely, compared with the beauty and
>
effectivity of Cocoa. I can (*very* reluctantly) accept the need of
>
Carbon as a transition tool so as Office was quickly portable, but it
>
is extremely bad for us all that the vast majority of new APIs are
>
"carbon" (ie. they perfectly fit its non-OO concept and ugliness).
>
>
That is what surely leads to extremely bitter speak, and rightly at
>
that.
Carbon is necessary for some things. For example, in order to do
anything with FSRefs, aliases, any HFS metadata, or resource forks, I
have to resort to Carbon. I agree with you that it would be very nice if
there were Objective-C wrappers around all of these things, and I also
definitely agree that there should be OO interfaces to the new API's...
>
(*) exceptions are almost solely Finder issues -- but Finder is a
>
Carbon thing! I am *pretty* sure that had it be based on the Cocoa
>
Workspace Manager (which of course would be the sensible solution), it
>
would now *very easily* accomodated all those great NeXT things /like
>
shelf/ PLUS all those great Classic Finder ones /like popup folders/.
Can't argue with you here, either. The Finder should have been based on
the existing Cocoa code - it would have saved time and money, and
probably would have resulted in a better Finder. It's true that they
needed to use Carbon for various HFS-related things, but those Carbon
functions can be called from a Cocoa app easily enough.
Charles
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
| References: | |
| | >Re: CMSDA (From: Ondra Cada <email@hidden>) |