TextEdit vs SimpleText: keeping track of open files

[Mason Mark]

On OS X, is there a preferred way to keep track of open documents?

TextEdit keeps track of its open document files by path. SimpleText
uses some more traditionally "Mac-like" mechanism (I am guessing an
FSRef, or some older version of the same thing).

If you open a document in TextEdit, switch to the Finder and move
or rename it, TextEdit knows nothing about it, and when you save,
it just writes out a new file at the path location the document was
at when TextEdit opened it. Now you have two files.

If you open a document in SimpleText, and switch to the Finder and
move and rename it, when you switch back to SimpleText, SimpleText
has noticed the change, updated the name of the window to match
what you renamed the file to, and when you save, it saves it to the
file that you moved. You still only have the one file you started
with (though it has been renamed and moved).

Now, to me, SimpleText's way seems much smarter, and is certainly
what Mac users will expect, so my app currently grabs an FSRef to
the files it opens, and uses that to keep track of them.

But a mismash, where some apps just use a path and don't keep track
of the file, and other apps do keep track of the file, seems worse
than either way.

(I also do not believe this is an uncommon case, where a document
is open with unsaved changes, and the user moves or renames it. For
many users, both editing and renaming/filing are part of the
overall task of "working on" a document.)

Is there a consensus here on how to deal with this? Unless there is
some third way that I don't know about, I am guessing that probably
some people think using paths way is better, and others will insist
the traditional Mac way is better.

What to do? Getting and keeping an FSRef from Cocoa is easy, and
it seems a pretty good way to do it to me...

--Mason

[Mike Shields]

One word: Alias.

Many words: What ST does is it keeps and polls a alias to the file.
On an activate event it'll call ResolveAlias. If the alias has changed,
it does some more snooping to see if it's moved to the trash. If its in
the trash, it closes the document, else, it updates the name/path, etc
and then goes along its merry way. At least that's the Apple documented
way to do it. I think this is in the appearance documentation with the
proxy icon info.

A Cocoa app could also do this the exact same way. Just not using Cocoa.
You'd have to use Carbon to do the alias resolution.

Mike

[Brian Hill]

Post by Mason Mark
On OS X, is there a preferred way to keep track of open documents?
TextEdit keeps track of its open document files by path. SimpleText
uses some more traditionally "Mac-like" mechanism (I am guessing an
FSRef, or some older version of the same thing).
If you open a document in TextEdit, switch to the Finder and move or
rename it, TextEdit knows nothing about it, and when you save, it just
writes out a new file at the path location the document was at when
TextEdit opened it. Now you have two files.
If you open a document in SimpleText, and switch to the Finder and move
and rename it, when you switch back to SimpleText, SimpleText has
noticed the change, updated the name of the window to match what you
renamed the file to, and when you save, it saves it to the file that
you moved. You still only have the one file you started with (though it
has been renamed and moved).
Now, to me, SimpleText's way seems much smarter, and is certainly what
Mac users will expect, so my app currently grabs an FSRef to the files
it opens, and uses that to keep track of them.
But a mismash, where some apps just use a path and don't keep track of
the file, and other apps do keep track of the file, seems worse than
either way.
(I also do not believe this is an uncommon case, where a document is
open with unsaved changes, and the user moves or renames it. For many
users, both editing and renaming/filing are part of the overall task of
"working on" a document.)

I've been thinking about this, and I think that this should be filed as
a bug in the NSDocument class. Okay, maybe a feature request...8-)

The way the Cocoa API would like to have you implement an NSDocument
subclass, you never really even need to know the actual path to the
document file. In the easiest case, you just implement these:

- (NSData *)dataRepresentationOfType:(NSString *)type;
- (BOOL)loadDataRepresentation:(NSData *)data ofType:(NSString *)type;

or these:

- (NSFileWrapper *)fileWrapperRepresentationOfType:(NSString *)type;
- (BOOL)loadFileWrapperRepresentation:(NSFileWrapper *)wrapper
ofType:(NSString *)type;

and the document is saved wherever the user puts it. The actual writing
to disk happens up in NSDocument.

In fact, even if you decide to take over writing the data to disk, you
are given the path (or URL) by NSDocument -- you aren't expected to keep

Post by Mason Mark
Is there a consensus here on how to deal with this? Unless there is
some third way that I don't know about, I am guessing that probably
some people think using paths way is better, and others will insist the
traditional Mac way is better.
What to do? Getting and keeping an FSRef from Cocoa is easy, and it
seems a pretty good way to do it to me...

I'd say use the FSRef yourself from Cocoa. I just went poking around in
the headers, and I don't see any easy place where an FSRef could be put
in the NSDocument class without adding an instance variable (and
therefore breaking most document-based apps).

I suppose that you could keep an external hash map of documents and
FSRefs.
Or, we could all just do it ourselves in our own document classes...

I suppose that's the most likely possibility at this point.

Brian


***@mac.com http://personalpages.tds.net/~brian_hill
––––––––––––––––––––––––––––––––––––––––––––––––––––––
"Why? I came into this game for adventure - go anywhere, travel
light, get in, get out, wherever there's trouble, a man alone.
Now they've got the whole country sectioned off and you can't
move without a form. I'm the last of a breed."
-- Archibald "Harry" Tuttle, Rogue HVAC Repairman
––––––––––––––––––––––––––––––––––––––––––––––––––––––

[strobe anarkhos]

I'd say use the FSRef yourself from Cocoa. I just went poking around in the headers, and I don't see any easy place where an FSRef could be put in the NSDocument class without adding an instance variable (and therefore breaking most document-based apps).
I suppose that you could keep an external hash map of documents and FSRefs.
Or, we could all just do it ourselves in our own document classes...
I suppose that's the most likely possibility at this point.

Every time I learn more about Cocoa, the more I feel I'm retrogressing. No aliases, no FSRefs, no file types, no word from Apple when/how/if such things will be fixed.

As a mac user I expect to be able to move my files even if they are open. I've been doing that for decades, and now I have to make special exceptions for Cocoa apps? I think my customers and I expect more out of "Mac OS X"

[Mason Mark]

Post by Brian Hill

Post by Mason Mark
On OS X, is there a preferred way to keep track of open documents?
[snipped path vs FSRef stuff]

I've been thinking about this, and I think that this should be
filed as a bug in the NSDocument class. Okay, maybe a feature
request...8-)

Hmm, I hadn't even thought about how the NSDocument architecture
relates to this problem (since I am not using NSDocument). I
presume since you want NSDocument to be fixed/improved, it doesn't
handle the dirty-file-moved-or-renamed issue intelligently? Does it
currently just use the path to track open documents?

Even so, if NSDocument handles tracking the file for you, it would
provide a single place where improvement could really help the user
experience for a lot of apps...

--
Mason

[Brian Hill]

Post by Mason Mark
Hmm, I hadn't even thought about how the NSDocument architecture
relates to this problem (since I am not using NSDocument). I presume
since you want NSDocument to be fixed/improved, it doesn't handle the
dirty-file-moved-or-renamed issue intelligently? Does it currently just
use the path to track open documents?

It appears to just use the path right now.

Post by Mason Mark
Even so, if NSDocument handles tracking the file for you, it would
provide a single place where improvement could really help the user
experience for a lot of apps...

Hey, that's what the Cocoa frameworks are all about...8-)

Brian


***@mac.com http://personalpages.tds.net/~brian_hill
––––––––––––––––––––––––––––––––––––––––––––––––––––––
"Why? I came into this game for adventure - go anywhere, travel
light, get in, get out, wherever there's trouble, a man alone.
Now they've got the whole country sectioned off and you can't
move without a form. I'm the last of a breed."
-- Archibald "Harry" Tuttle, Rogue HVAC Repairman
––––––––––––––––––––––––––––––––––––––––––––––––––––––

[David E. Weekly]

Hey, have any of you had *serious* issues with debugging multithreaded
programs under OS/X using GDB? GDB's been crapping out on be badly whenever
i try any threaded debugging at all....

-david

[Michael Trent]

Post by strobe anarkhos
Every time I learn more about Cocoa, the more I feel I'm retrogressing. No aliases, no FSRefs, no file types, no word from Apple when/how/if such things will be fixed.

One man's prison is another man's palace.

MDT

[Rob Rix]

Post by strobe anarkhos
Every time I learn more about Cocoa, the more I feel I'm retrogressing.
No aliases, no FSRefs, no file types, no word from Apple when/how/if such
things will be fixed.

I don't quite agree with that. It's three (or more) steps forward, one
step back for me. I did not enjoy the experiences I had while programming
on OS 9, but things like aliases are indeed powerful, and add to the user'
s experience.
My code tends to work now. This is a new experience for me :)

Post by strobe anarkhos
As a mac user I expect to be able to move my files even if they are open.
I've been doing that for decades, and now I have to make special
exceptions for Cocoa apps? I think my customers and I expect more out of
"Mac OS X"

I agree with that, definitely. If Apple doesn't get on the ball and add
alias, et cetera, support to Cocoa, then perhaps one of us should submit a
Cocoa solution to the MiscKit?
That is, if Omni hasn't done this already in their released source
code...it's full of nice things that I haven't explored yet :)

-- Rob

This has been a recording.

[Mason Mark]

Post by strobe anarkhos
Every time I learn more about Cocoa, the more I feel I'm
retrogressing. No aliases, no FSRefs, no file types, no word from
Apple when/how/if such things will be fixed.

Well, I don't know about that. Cocoa brings with it quite a bit
that the Mac has never had. I've never seen an app mature as
quickly as the Cocoa app we're working on now. The thing that blows
me away is the ease and speed of development--all that hype we were
hearing really is true, at least in my experience.

But, that is only one side of the coin; the other is the resulting
product, and how good it is for the user. There are certainly a lot
of hallmark Mac features that Cocoa doesn't support. This is a good
example.

Post by strobe anarkhos
As a mac user I expect to be able to move my files even if they
are open. I've been doing that for decades, and now I have to make
special exceptions for Cocoa apps? I think my customers and I
expect more out of "Mac OS X"

But you don't necessarily have to make special exceptions; that was
the point of my question, to see how other people--who, like
myself, want to support these hallmark Mac features--are going
about doing so.

I found it easy to implement the behavior I want--the ability to
keep track of open files in the "Mac way", using Carbon and
CoreFoundation. The app is not "pure Cocoa", but it is 99.9% Cocoa,
and it doesn't really matter if I have to use some of the non-Cocoa
APIs; they are all Mac OS X APIs, at any rate.

There are certainly historical--and, I think,
philosophical--differences in where Cocoa is coming from and
long-standing Mac conventions. But for the most part, it is another
one of those things that is "up to the developers". Cocoa
developers can make their apps have types and creators (in one easy
line of code, thanks to Omni) so that they work whatever the
filename is, and they can make their apps intelligently track moved
open documents. Or not. They question is whether they will. (I
think being able to follow your open files will be a less
controversial Mac-ism than storing metadata in the resource fork
was...)

I do agree that not being able to move open files and save them
would be a huge step backwards, but it is an avoidable step.

--
Mason

[Scott Anguish]

Post by strobe anarkhos
Every time I learn more about Cocoa, the more I feel I'm retrogressing.
No aliases, no FSRefs, no file types, no word from Apple when/how/if
such things will be fixed.

Yes, some of us think this is progression.. even those of us who
did Mac development.

And Apple has said that aliases are something that will be
integrated into the Cocoa classes at some point.

The last thing we need are a bunch of stupid fsrefs, fspecs,
volspecs and the other arcane relics from the Carbon days.

Post by strobe anarkhos
As a mac user I expect to be able to move my files even if they are
open. I've been doing that for decades, and now I have to make special
exceptions for Cocoa apps?

Nice to see that you're not blowing your claim to ridiculous
proportions. Decades huh? I think it was System 7 that first
introduced them. So that would have been MAYBE 10 years ago.. MAYBE...

[Mason Mark]

Post by Scott Anguish

Post by strobe anarkhos
Every time I learn more about Cocoa, the more I feel I'm
retrogressing. No aliases, no FSRefs, no file types, no word from
Apple when/how/if such things will be fixed.

Yes, some of us think this is progression.. even those of us
who did Mac development.
And Apple has said that aliases are something that will be
integrated into the Cocoa classes at some point.
The last thing we need are a bunch of stupid fsrefs, fspecs,
volspecs and the other arcane relics from the Carbon days.

A ha! Here's a little bit of that "controversy" I was expecting. ;-)

That was the other half of my question--to the
don't-like-creator-codes, don't-like-carbon crowd:

What do YOU guys suggest to solve this particular problem? How do
you do it without these arcane relics? Tell the user not to move
their files while they're open??

--
Mason

[Michael Trent]

Post by Mason Mark
That was the other half of my question--to the
What do YOU guys suggest to solve this particular problem? How do
you do it without these arcane relics? Tell the user not to move
their files while they're open??

Give me an API that solves this problem w/o exposing me to the Carbon file
manager and I will use it. Make sure the API automatically dereferences
all aliases w/o any intervention on my part. Make the API as path-centric
as possible. Make sure the API doesn't require me to pass in parameter
blocks.

As a first pass, go ahead and use Carbon's file manager to implement some
or all of this. Just don't expose any of its calling semantics to me,
the programmer. As a second pass, move off of CarbonCore completely
(link no higher in the food-chain than CF) so I don't have to bring in all
of the Carbon dylibs I don't need just to write a system daemon that moves
files around.

Really ... that's all I want.

MDT

[Max Horn]

Post by Michael Trent

Post by Mason Mark
That was the other half of my question--to the
What do YOU guys suggest to solve this particular problem? How do
you do it without these arcane relics? Tell the user not to move
their files while they're open??

Give me an API that solves this problem w/o exposing me to the Carbon file
manager and I will use it. Make sure the API automatically dereferences
all aliases w/o any intervention on my part. Make the API as path-centric
as possible. Make sure the API doesn't require me to pass in parameter
blocks.
As a first pass, go ahead and use Carbon's file manager to implement some
or all of this. Just don't expose any of its calling semantics to me,
the programmer. As a second pass, move off of CarbonCore completely
(link no higher in the food-chain than CF) so I don't have to bring in all
of the Carbon dylibs I don't need just to write a system daemon that moves
files around.

That's something I'd want, too. I just wonder why Apple hasn't done
it yet. Currently, it is up to the developer to implement all this,
and I think most people don't want to do get into this big hassle. I
certainly don't like it, and I have been programming MacOS for many
years now.

But it sounds as if it should be really simple to write some neat
wrappers around it. Maybe not all-powerful wrappers, but wrappers for
the most common cases. And IMHO it is bad that these don't exist yet.


Apple has promised us a lot of new feature for future versions of OS
X, but we live in the here and now - sure, maybe I can do all this
with !0.1, but then I need to wait till it is released and I can
adopt my apps to it... hrm


Max

[Stéphane Sudre]

And Apple has said that aliases are something that will be integrated
into the Cocoa classes at some point.

Apple has said a lot of things. But some of us only believe what they
see.

As a side note, I was reading old slides from an Apple presentation on
Mac OS X. One of the cool features promised with Mac OS X was faster
application launch time. :-)

--
St Thomas

[Glen Simmons]

Post by Scott Anguish

Post by strobe anarkhos
Every time I learn more about Cocoa, the more I feel I'm
retrogressing. No aliases, no FSRefs, no file types, no word from
Apple when/how/if such things will be fixed.

Yes, some of us think this is progression.. even those of us who
did Mac development.
And Apple has said that aliases are something that will be
integrated into the Cocoa classes at some point.
The last thing we need are a bunch of stupid fsrefs, fspecs,
volspecs and the other arcane relics from the Carbon days.

Right, we don't need anything arcane ... we've got path names! Who needs
a reference to a file that just works. I'd rather use a reference that I
have to manipulate manually and that could break because of an extra
space. Please.

Glen

[Erik M. Buck]

The statement was made that SimpleText file handling behavior is better than
TexTEdit's file handling behavior for the following reason:

With simple text, the user can rename or move an open file. When the open
file is saved from SimpleText, the renamed and moved file is overwritten.
This behavior is presumably the result of using FSRefs. If the user renames
or moves a file that is open in TextEdit, when the open file is saved, it is
saved with the original name at the original location. This behavior is
presumably the result of using file paths rather than FSRefs.


Personally, I would hate the SimpleText behavior. If I move or rename an
open file, I may be trying to save a backup copy so that I can revert from
the changes I am making in TextEdit days later if necessary. With the
SimpleText behavior, my effort is wasted because by backup will be clobbered
anyway. Suppose I open a read-only file in TextEdit with no intention of
editing it. Then I notice something that I must change. I might rename the
read-only file on disk so that I can save my changes and also preserve the
original version. Yes, I know I could use save-as, but then I would have to
rename two files later...

People grow accustomed to a certain behavior. I do not think that my
expectations of behavior and the Mac OS 9 expectations are better or worse
than each other. I just want to point out that the TextEdit behavior is
perfectly reasonable and matches the expectations of 95% of computer users.
The SimpleText behavior is also reasonable, but IMHO no more likely to be
expected by a new computer users. Only long time Mac users who grew
accustomed to the SimpleText behavior would ever expect it.

I don't mind if Apple changes the NSDocument class to use FSRef, but it
better be very well documented. When a new user account is installed, OS X
will need to have a check box indicating if the user has ever used any of
the other 95% of computers. If so, the first hundred times the user tries
to move or rename an open file, the operating system will have to show an
alert reminding them that the file will be clobbered in spite of their best
efforts to avoid that.

Furthermore, If Apple ever makes good on the cross-platform YellowBox
promise, the same frameworks will end up with very different behavior on
different platforms.

[strobe anarkhos]

Post by Erik M. Buck
Personally, I would hate the SimpleText behavior. If I move or rename an
open file, I may be trying to save a backup copy so that I can revert from
the changes I am making in TextEdit days later if necessary. With the
SimpleText behavior, my effort is wasted because by backup will be clobbered
anyway. Suppose I open a read-only file in TextEdit with no intention of
editing it. Then I notice something that I must change. I might rename the
read-only file on disk so that I can save my changes and also preserve the
original version. Yes, I know I could use save-as, but then I would have to
rename two files later...

Oh great, "would hate". Nothing like the realm of theory to make a case.

I'm sorry but this is a ludicrous case. You can make a backup of opened mac files very easily by using the 'save as' command or by copying the file in the finder.

This is not just a different way of doing things, it's a superior way. The reason is the user doesn't have to be conscious about which files are open when using the Finder OR conscious about where a file is located when editing it in an application. Thus I won't ever make inadvertent backups using your so-called preferred method, I will only make backups when I want to by selecting hte 'save as' command. Clearly the mac method is by far superior to the NeXT one, the user has to keep track of less stuff and there are far fewer chances for mistakes.

As for the 95% of other computers, who gives a damn? Better to make an interface for the 99% of non-computer users.

[Tom Waters]

I've got two comments (and zero snide remarks)

1. I've used computers for decades, but never a Mac. I have, on several
platforms, always relied on the fact that I can move a file that I am
editing so that it WON'T get over-written when i save. I make several
changes to some file, then realize I want to save a copy of the
original, so i go to a shell or file manager and MOVE the original out
of the way, and hit save thus I've safely got both versions of the
file. Apple is going to have a hard time pleasing the old-school mac
users who expect tight coupling between open files and the finder at the
same time as old unix/windows people like me who expect no coupling.

2. Aliases sound cool. However, every time I read some Mac user mocking
paths as if they are some abomination from the stone age, I think about
the several billion URL's in use in a given day and wonder if I'm
missing something. Paths clearly work just fine for the 95% of the
world's computer users who don't use OS9. As an aside, it sure would be
cool if Aliases were in Windows and Unix, and even cooler if URL's were
self-healing like Aliases...

Post by Glen Simmons

Post by Scott Anguish

Post by strobe anarkhos
Every time I learn more about Cocoa, the more I feel I'm
retrogressing. No aliases, no FSRefs, no file types, no word from
Apple when/how/if such things will be fixed.

Yes, some of us think this is progression.. even those of us who
did Mac development.
And Apple has said that aliases are something that will be
integrated into the Cocoa classes at some point.
The last thing we need are a bunch of stupid fsrefs, fspecs,
volspecs and the other arcane relics from the Carbon days.

Right, we don't need anything arcane ... we've got path names! Who
needs a reference to a file that just works. I'd rather use a reference
that I have to manipulate manually and that could break because of an
extra space. Please.

[Fritz Anderson]

Post by Tom Waters
1. I've used computers for decades, but never a Mac. I have, on
several platforms, always relied on the fact that I can move a file
that I am editing so that it WON'T get over-written when i save. I
make several changes to some file, then realize I want to save a
copy of the original, so i go to a shell or file manager and MOVE
the original out of the way, and hit save thus I've safely got both
versions of the file. Apple is going to have a hard time pleasing
the old-school mac users who expect tight coupling between open
files and the finder at the same time as old unix/windows people
like me who expect no coupling.

I understand how that could be the custom. It makes sense to me: I
know that open() and fopen() take pathnames that are either absolute
or relative to a working directory. I know enough about the common
way applications are written, that a pointer-to-buffer-to-inode chain
between what the program will write and where it will write it is
unlikely to be kept open between saves; that the application and the
operating system, though linked in thousands of ways, are not linked
in the particular matter of what happens to a file between close()
and open(); that an open() or fopen() with the original path name
must therefore occur; that these calls will create what they do not
immediately find; and long experience has taught me which directory
references inside the program will change the working directory, and
which won't, and when that information is relevant.

I learned these principles over the course of a year or two in my
mid-twenties, with one- or two-month refreshers for each application
to which the principles apply. It all makes sense to me. When I
make mistakes and lose data, I can clearly explain where I went wrong.

I learned object persistence in the cradle: My father did not, in
fact, disappear when he hid his face. Never needed to refresh it,
because it's always true. I don't have to explain where I go wrong
with it, because I never go wrong. When apparent violations occur
(as with moving the file I'm editing), a few weeks' effort persuades
me that what I thought was a single object was not a single object at
all, so the principle is never violated.

Most people don't want to parse out exceptions to peek-a-boo. A good
many of them, though intelligent, may find it unacceptably difficult
to do so: Being strongly hard-wired for object persistence is, if
anything, an evolutionary advantage. They think that everything you
do to the same visible object -- open the icon, move the icon, save
what you opened -- is done to the same object.

I write for the Mac because I believe the world would be better for
having a computer that serves more people well without demanding the
psychedelic tricks that come easily to people who are already
well-served by UNIX. I am therefore skeptical of designs that,
though customary, work against a plausible simulation of real things.

Post by Tom Waters
2. Aliases sound cool. However, every time I read some Mac user
mocking paths as if they are some abomination from the stone age, I
think about the several billion URL's in use in a given day and
wonder if I'm missing something. Paths clearly work just fine for
the 95% of the world's computer users who don't use OS9. As an
aside, it sure would be cool if Aliases were in Windows and Unix,
and even cooler if URL's were self-healing like Aliases...

In fact, on the big-volume sites, aren't most URLs self-healing, in
the sense that they do not identify actual files, but keys for
generating pages out of underlying data? In any event, the issue of
how to publish access to a particular dataset may be a different
issue from whether a computer is smart enough to keep track of what
it tells the user is a single entity that it alone creates, moves,
reads, and fills. The objection to pathnames is not that they are
inexpressive (when certain operating assumptions are carefully
preserved), but that they are dumb, and therefore fragile.

And again: If you want to write only for people to whom Windows and
UNIX are accessible and error-free, you know what platforms to use.
My hope is not for today's 95%, but for tomorrow's.

-- F

[Robert Lee Dotson]

Personally, I think Apple's current way is the only way to make this
whole thing work. Keeping track of a file via an alias would only work
if one is moving a file around on the same volume, AND that volume is
HFS(+) or AFP. What if I've created (or opened) the file on an NFS
volume? Or created a file on an HFS volume and dragged it to a directory
which actually resides on an NFS union (or UFS, or AFS) mount? The alias
is broken, the file is gone, and I end up saving into the ether. Plus if
I do a 'revert to saved' on a file that I've moved, I'll get a 'file not
found' or more likely, a crash. Folks working in OSX now have a plethora
of file systems to work from, all at the same time. As developers, we
must concede that our users might have systems that are very different
from our own.

IHMO, the only way I can see this being fixed, is to change the file
descriptor/inode/whatever at the darwin-vfs level for all file systems,
and fixing the alias technology to work across multiple volumes. Since
the Classic Mac OS had these problems (aliases breaking across multiple
volumes) for years, I won't hold my breath.

I think it would also be good to remember that 'this ain't yo momma's
OS' and start thinking of it as something new and not a re-hash of
something else.

-- Robert Lee Dotson

"Ad Astra per Apera" Translation: "To the stars through difficulties"

[strobe anarkhos]

Personally, I think Apple's current way is the only way to make this whole thing work. Keeping track of a file via an alias would only work if one is moving a file around on the same volume, AND that volume is HFS(+) or AFP. What if I've created (or opened) the file on an NFS volume? Or created a file on an HFS volume and dragged it to a directory which actually resides on an NFS union (or UFS, or AFS) mount? The alias is broken, the file is gone, and I end up saving into the ether. Plus if I do a 'revert to saved' on a file that I've moved, I'll get a 'file not found' or more likely, a crash. Folks working in OSX now have a plethora of file systems to work from, all at the same time. As developers, we must concede that our users might have systems that are very different from our own.
IHMO, the only way I can see this being fixed, is to change the file descriptor/inode/whatever at the darwin-vfs level for all file systems, and fixing the alias technology to work across multiple volumes. Since the Classic Mac OS had these problems (aliases breaking across multiple volumes) for years, I won't hold my breath.
I think it would also be good to remember that 'this ain't yo momma's OS' and start thinking of it as something new and not a re-hash of something else.

aliases are always used via the alias manager or something using the alias manager thus if you want aliases to represent inodes on UFS volumes, it can be done! An alias has data which tells the alias manager where the file is. Apple could create a new category (VFS volume or whatever) and store the inode for the alias manager to resolve.

If Apple moved the alias functionality to CoreFoundation, Darwin developers could extend aliases when they develop new file systems for OS X.

I'm not going to say aliases are superior to symlinks, they are a useful addition to symlinks. symlinks are more appropriate than aliases in many cases including bundles and web directories.

[Graeme Hiebert]

Post by Tom Waters
1. I've used computers for decades, but never a Mac. I have, on
several platforms, always relied on the fact that I can move a file
that I am editing so that it WON'T get over-written when i save. I
make several changes to some file, then realize I want to save a copy
of the original, so i go to a shell or file manager and MOVE the
original out of the way, and hit save thus I've safely got both
versions of the file. Apple is going to have a hard time pleasing the
old-school mac users who expect tight coupling between open files and
the finder at the same time as old unix/windows people like me who
expect no coupling.

On a Mac you'd normally just pick the file and then "Command-D" to
duplicate. It has the same effect.

You could just tie the file renaming functionality into the Finder: if
the file was renamed in the Finder, save it to the new name. If it was
renamed from Terminal, safe it to the old name. (In other words, just
observe file rename notifications from the Finder to figure out what to
do.)

-g

[strobe anarkhos]

On a Mac you'd normally just pick the file and then "Command-D" to duplicate. It has the same effect.

Better yet select 'save as' in your application, thus you don't have to know where the file is when you're in the Finder. Command-D is relatively new in comparison and in a way has the same problem as the NeXT method in that you have to know where the file is.

[Guillaume Lessard]

Post by strobe anarkhos
Better yet select 'save as' in your application, thus you don't have to
know where the file is when you're in the Finder. Command-D is relatively
new in comparison and in a way has the same problem as the NeXT method in
that you have to know where the file is.

The "Duplicate" finder command (command-D) was present in Finder 1.0 in
1984.

--
Guillaume Lessard
***@caltech.edu
Graduate Student
Caltech Applied Physics/Electrical Engineering

[s***@execpc.com]

Personally, I do not know how many times I have had a file open in
SimpleText and moved the
thing to the trash, saved my file, and then emptied my trash. AND THE
DANG THING ATE MY FILE!!!

I have always considered the SimpleText behavior a fundamental oversight
in design.

Steven Noyes

Post by Mason Mark
On OS X, is there a preferred way to keep track of open documents?
TextEdit keeps track of its open document files by path. SimpleText
uses some more traditionally "Mac-like" mechanism (I am guessing an
FSRef, or some older version of the same thing).
If you open a document in TextEdit, switch to the Finder and move or
rename it, TextEdit knows nothing about it, and when you save, it just
writes out a new file at the path location the document was at when
TextEdit opened it. Now you have two files.
If you open a document in SimpleText, and switch to the Finder and move
and rename it, when you switch back to SimpleText, SimpleText has
noticed the change, updated the name of the window to match what you
renamed the file to, and when you save, it saves it to the file that
you moved. You still only have the one file you started with (though it
has been renamed and moved).
Now, to me, SimpleText's way seems much smarter, and is certainly what
Mac users will expect, so my app currently grabs an FSRef to the files
it opens, and uses that to keep track of them.
But a mismash, where some apps just use a path and don't keep track of
the file, and other apps do keep track of the file, seems worse than
either way.
(I also do not believe this is an uncommon case, where a document is
open with unsaved changes, and the user moves or renames it. For many
users, both editing and renaming/filing are part of the overall task of
"working on" a document.)
Is there a consensus here on how to deal with this? Unless there is
some third way that I don't know about, I am guessing that probably
some people think using paths way is better, and others will insist the
traditional Mac way is better.
What to do? Getting and keeping an FSRef from Cocoa is easy, and it
seems a pretty good way to do it to me...
--Mason
_______________________________________________
MacOSX-dev mailing list
http://www.omnigroup.com/mailman/listinfo/macosx-dev

[strobe anarkhos]

Personally, I do not know how many times I have had a file open in SimpleText and moved the
thing to the trash, saved my file, and then emptied my trash. AND THE DANG THING ATE MY FILE!!!
I have always considered the SimpleText behavior a fundamental oversight in design.

Good grief, what a stretch.

I've been using macs every day since 1986 and have never done that. You see, you can't delete a file that's actually in use in MacOS. Compare that to other systems where any file can be deleted, open or not.

Now which system looks more foolproof?

[Mason Mark]

Post by Robert Lee Dotson
Personally, I think Apple's current way is the only way to make
this whole thing work. Keeping track of a file via an alias would
only work if one is moving a file around on the same volume, AND
that volume is HFS(+) or AFP. What if I've created (or opened) the
file on an NFS volume? Or created a file on an HFS volume and
dragged it to a directory which actually resides on an NFS union
(or UFS, or AFS) mount? The alias is broken, the file is gone, and
I end up saving into the ether. Plus if I do a 'revert to saved'
on a file that I've moved, I'll get a 'file not found' or more
likely, a crash. Folks working in OSX now have a plethora of file
systems to work from, all at the same time. As developers, we must
concede that our users might have systems that are very different
from our own.

No.

When you move a file across file systems, you are making a copy of
the file. This is explicit in both OS 9 and OS X. (You get a copy
progress dialog, you end up with two files. The original is still
there.) So, the copy you made on the new disk is not the same file
in any sense.

And there is no reason you would end up "saving into the ether" or
getting a crash, unless the app you're using absolutely sucks.
Using an alias or FSRef to track where a file has been moved to
will just as easily tell you that it no longer exists (deleted or
whatever). Why would the behavior in this case be any different
from when a path-based app can no longer find a document at the
path? It's the same scenario--original file can no longer be found.
A good app will certainly handle that without crashing or barfing.

The UFS/NFS scenario is a valid concern. (I should format one of my
partitions UFS just to be able to test these things.)

But I think *if* one agrees that Mac-style "follow the file"
behavior is better in general, then falling back on path-based
"file-disappeared-so-save-new-file-to-original-path" in the rare
case of UFS/NFS is an okay trade-off. Most Mac users do not know or
want to know about the differences between HFS and UFS, etc. But
those users almost certainly will use HFS+ anyway.

Of course, if you *don't* think follow-the-file is better, then you
wouldn't want to bother with all this...

--
Mason

[Mason Mark]

Post by Erik M. Buck
The statement was made that SimpleText file handling behavior is
better than
[FSRef vs path stuff snipped]
Personally, I would hate the SimpleText behavior. If I move or
rename an
open file, I may be trying to save a backup copy so that I can
revert from
the changes I am making in TextEdit days later if necessary. With the
SimpleText behavior, my effort is wasted because by backup will be
clobbered
anyway. Suppose I open a read-only file in TextEdit with no
intention of
editing it. Then I notice something that I must change. I might
rename the
read-only file on disk so that I can save my changes and also
preserve the
original version. Yes, I know I could use save-as, but then I
would have to
rename two files later...

This is so interesting to me, the real (and total) differences of
opinion on these things...

Post by Erik M. Buck
People grow accustomed to a certain behavior. I do not think that my
expectations of behavior and the Mac OS 9 expectations are better
or worse
than each other. I just want to point out that the TextEdit
behavior is
perfectly reasonable and matches the expectations of 95% of
computer users.
The SimpleText behavior is also reasonable, but IMHO no more
likely to be
expected by a new computer users. Only long time Mac users who grew
accustomed to the SimpleText behavior would ever expect it.

Well, what you say is true. Sometimes it is nice to be able to just
move something out of the way. On the other hand, I would venture
to say that the TextEdit behavior does NOT match the expectations
of 95% of Mac users. You don't need to be a long-time Mac user to
expect the computer to know where you moved a file. But then we're
back to "OS X should please Mac users, no it should please the rest
of the world" debate.

I also feel pretty strongly that the SimpleText way is better,
especially for new or inexperienced users, based on my observations
of my parents using the iMacs I bought them. It really is just more
intuitive. For a power user, who cares, as long as it works the
same way all the time.

But most of all, I would hate to see these completely different set
of expectations lead to a schizophrenic state of affairs where some
apps use paths, some use FSRef or whatever, and you just NEVER KNOW
what the computer is going to do until you try it. (That is
actually the situation we have right now.)

With the wildly different and strongly-held opinions expressed by
various folks in this thread (well actually, the other thread on
the same topic, though, I fear we might be stuck with that
schizophrenia...

--
Mason

[Graeme Hiebert]

Post by strobe anarkhos

Post by Graeme Hiebert
On a Mac you'd normally just pick the file and then "Command-D" to
duplicate. It has the same effect.

Better yet select 'save as' in your application, thus you don't have to
know where the file is when you're in the Finder. Command-D is
relatively new in comparison and in a way has the same problem as the
NeXT method in that you have to know where the file is.

Normally I'd want to make a backup of the existing file before saving a
file with the same name. I don't want to "Save As", because then, aside
from having to muck around with the "Save As..." panel, I'd have to muck
around further to get the files named the way I want.

-g

[John Siracusa]

Post by strobe anarkhos
This is not just a different way of doing things, it's a superior way.

I agree. Another example of similar intelligent behavior: I often start
downloading a file, then drag it to a buried folder without worrying that
the app downloading it will "lose track of" the file. And IME, this is what
most users (not conditioned by the limitations of inferior OSes :) expect.
The ultimate goal of "file tracking" should be to create links that are as
strong as the user's conception of them. If I know it's the same file (but
in a different place or under a different name, etc.), then so should the
OS. The Mac OS behavior is closer to that ideal than the slavish devotion
to implementation details (and the "features" derived from it) represented
by hard-coded paths and such.

-John

[Scott Anguish]

Post by John Siracusa

Post by strobe anarkhos
This is not just a different way of doing things, it's a superior way.

I agree. Another example of similar intelligent behavior: I often start
downloading a file, then drag it to a buried folder without worrying
that
the app downloading it will "lose track of" the file. And IME, this is
what
most users (not conditioned by the limitations of inferior OSes :)
expect.

This has zero to do with aliases... this has to do with keeping the
file descriptor open and continuing to write to it.

[Scott Anguish]

Post by strobe anarkhos

Post by Erik M. Buck
Personally, I would hate the SimpleText behavior. If I move or rename
an
open file, I may be trying to save a backup copy so that I can revert
from
the changes I am making in TextEdit days later if necessary. With the
SimpleText behavior, my effort is wasted because by backup will be
clobbered
anyway. Suppose I open a read-only file in TextEdit with no intention
of
editing it. Then I notice something that I must change. I might
rename the
read-only file on disk so that I can save my changes and also preserve
the
original version. Yes, I know I could use save-as, but then I would
have to
rename two files later...

Oh great, "would hate". Nothing like the realm of theory to make a case.

No more ludicrous than your claim of having relied on the alias
functionality in Mac OS for 'decades'.

[Guillaume Lessard]

Post by Scott Anguish

Post by strobe anarkhos
Oh great, "would hate". Nothing like the realm of theory to make a case.

No more ludicrous than your claim of having relied on the alias
functionality in Mac OS for 'decades'.

Scott, you are in total flame mode.

He didn't say that he had relied on aliases for decades.

He said he had relied on moveability of open files. That has been the case
since the original System in 1984. 17 years is a bit short for "decades",
but it doesn't warrant your hostile flames.

Do not let your ignorance of the original mac blind you.

--
Guillaume Lessard
***@caltech.edu
Graduate Student
Caltech Applied Physics/Electrical Engineering

[John Siracusa]

Post by Scott Anguish

Post by John Siracusa

Post by strobe anarkhos
This is not just a different way of doing things, it's a superior way.

I agree. Another example of similar intelligent behavior: I often start
downloading a file, then drag it to a buried folder without worrying that the
app downloading it will "lose track of" the file. And IME, this is what most
users (not conditioned by the limitations of inferior OSes :) expect.

This has zero to do with aliases... this has to do with keeping the
file descriptor open and continuing to write to it.

I said "similar", not "identical." You're getting hung up on implementation
again ;)

-John

[Mason Mark]

Post by Scott Anguish

Post by John Siracusa

Post by strobe anarkhos
This is not just a different way of doing things, it's a superior
way.

I agree. Another example of similar intelligent behavior: I
often start
downloading a file, then drag it to a buried folder without
worrying that
the app downloading it will "lose track of" the file. And IME,
this is what
most users (not conditioned by the limitations of inferior
OSes :) expect.

This has zero to do with aliases... this has to do with
keeping the file descriptor open and continuing to write to it.

But these things both have to do with the schism that has become
apparent over the past few weeks/months. (Maybe to a lesser extent
the past couple years?)

It's not like this community is confused over these issues, there
are basically two different camps, with very different opinions.
You see the same names, same kinds of arguments, and the same kinds
of issues:

1) Metadata in Resource Forks (other than type/creator)
Virtually nobody is in favor of essential data being stored in a
file's resource fork, but there was severe disagreement about the
pros and cons of storing nonessential metadata there.

Team A: The Mac has long benefited from programs being able to
store things like cursor location, selection info, and other data
along with a standard file type. The data fork contains strictly
standard data, and can be read by any program that supports it. The
Mac program that understand the resource fork can enhance the user
experience greatly without sacrificing the use of the standard
format.

Team B: Resource forks are inherently a bad proprietary idea, and
the disadvantages outweigh the user experience gains.

2) Types and Creator codes

Team A: Giving my documents Mac creator codes means that my
documents will open in my app when double clicked even if the user
renames the file "My Stuff" with no extension. A document's type
should not depend on the filename, computers should be smarter than
that, and have been in the Mac world for many years.

Team B: 95% of the world is used to using filename extensions. Type
and creator codes are more arcane relics we should do without.

3) References to open documents

Team A: An application should be smart enough to know that a user
has moved or renamed a file. It is still the same file; why should
an app lose track of it just because the name changed? Some other
mechanism than just the path is needed to keep track of it (FSRef
or whatever) and the Mac has long had this ability, which is one
reason why over the past years the Mac user experience has always
been better (except for the hellacious daily crashing of the OS,
ha ha ha).

Team B: Who needs that legacy junk? Paths work fine, 95% of the
world's users are used to it and know they can't move their files
while they are open and expect applications to keep up with them.
Furthermore, I like to rename a file to save it as a backup, rather
than using the cumbersome two-step process of Save As. Plus, the
Mac UI is overrated and NeXT kicked some serious ass, that's why
NeXT got paid $400 million to take over Apple.

4) Alias vs Symbolic Links & paths
We know aliases are supported on OS X, but there is still
disagreement among the two camps.

Team A: For God's sake, the alias has long been a hallmark of what
makes the Mac better. On the Mac you can move things wherever the
hell you want, and it is the computer's job to understand what you
are doing. Unintelligent path-based links don't have nearly as much
value to the user.

Team B: Aliases are imperfect, and kludgey. They don't work across
different volumes. Plus it is annoying when you have an alias and
then you don't notice that your "My Project" alias on the doc now
actually refers to the old "My Project Backup 2001-01-04" that you
filed somewhere else for safekeeping, not your current "My Project"
folder. 95% of the world is used to path-based links.



These are all pretty similar TYPES of issues, even though they are
all different. Now, I am running with Team A, so maybe I have not
adequately represented Team B's arguments. But I don't think these
two basic groups are moving much closer to a consensus; if
anything, the more debate that goes on the more polarized
everything gets.

What *is* clear, though, is that the schism isn't good for the
user, as it means we will continue to have various applications
behaving in fundamentally different ways. For most of these things,
consistency is more important than anything else.

Not that I have any suggestion about how to get people to agree on
this stuff. I think Apple needs to provide some *specific*
guidelines, because nobody else is in a position to do it. That
doesn't mean I think they will, though...

--
Mason

[strobe anarkhos]

Team C: Cocoa should at least have interfaces to these features. Better yet CoreFoundation.

[David W. Halliday]

There are also those of us in Team D (to take into account of the
position of strobe anarkhos <***@mac.com>): The /best of all
worlds/, no "common denominator" (incidentally, "least" common
denominator is a misnomer, since the /least/ common denominator is
/always/ zero or the null set---it's just that calling it the /greatest/
common denominator makes it sound reasonable, to most people), no
compromises (so the system may need to have more options, more choices,
so it can grow with the user).

WARNING: What follows is rather lengthy. Please bear with me.
Furthermore, especially if you think you disagree with me, please read
the whole thing before responding. I think it will help us all.

Post by Mason Mark

Post by strobe anarkhos
This is not just a different way of doing things, it's a superior
way.

...

But these things both have to do with the schism that has become
apparent over the past few weeks/months. (Maybe to a lesser extent
the past couple years?)

Unfortunately, it also appears to have been (if it isn't still) a
schism that exists within Apple. There is an honest difference of
opinion (one which you, with your biases, have not expressed very well).
The only answer, as I see it, if for both camps to admit that they each
really want what is the very best. They both think that what they have,
or have had, is the best. However, both really need to also recognize
that their side /does/ have some weaknesses, and that the other side
/does/ have some valid points.
Right now, Mac OS X is mostly not the old Mac, nor is it the old
NeXT. It has some things, particularly at its core (and, potentially,
with the Quartz graphics system---once optimized, and once it has
distributed capabilities added back in) that are better than either has
had. However, it is also missing some cherished features from both
sides---some very powerful and/or user friendly features.

Post by Mason Mark
It's not like this community is confused over these issues, there
are basically two different camps, with very different opinions.
You see the same names, same kinds of arguments, and the same kinds

There is, of course, more than this---a whole spectrum---but there
are those that are on the extremes, or who think that the way to get the
community to move to the middle is to take an extreme position.

Post by Mason Mark
1) Metadata in Resource Forks (other than type/creator)
Virtually nobody is in favor of essential data being stored in a
file's resource fork, but there was severe disagreement about the
pros and cons of storing nonessential metadata there.
Team A: The Mac has long benefited from programs being able to
store things like cursor location, selection info, and other data
along with a standard file type. The data fork contains strictly
standard data, and can be read by any program that supports it. The
Mac program that understand the resource fork can enhance the user
experience greatly without sacrificing the use of the standard
format.
Team B: Resource forks are inherently a bad proprietary idea, and
the disadvantages outweigh the user experience gains.

Metadata (other than TYPE/CREATOR codes, which are /not/ stored in
the resource fork anyway), whether "essential" or not, is a good thing.
We have to get away from a particular implementation (at least at first),
and think about such things from a higher level of abstraction. There
are limitations to the resource fork implementation. There are pitfalls
in the bundle implementation.
Let's first tackle the idea of what metadata can and should be used
for, to what extent it should be strictly a part of the file (at least
from a user's perspective), and to what extent it should be globally
associated with the file vs. being associated with the file on a per-user
basis (or even a per-user, per-role basis: The role, here, being how the
user is using the file: Edit, View, whatever). Only then can we
rightfully consider an implementation.
Any decisions should be implemented at a very high API level, so
programmers don't have to be aware of the nature of the implementation
(this is where OO shines). In this way, the implementation can be varied
(even depending upon file system [including remote vs. local], write
privileges or capability, and so forth), without adversely affecting the
programmers, and, therefore, the users.

(Incidentally, there are those that accuse the *n*x [Unix-like]
community of not solving the problem at a fundamental file system
level---not "fixing" the file system---but, rather, using a "band-aid"
like fix. The problem these people don't seem to
understand---understandably, since they usually have little idea of the
nature of file systems, at their implementation level---is that any such
"fundamental" fix would, in actuality, create a /new/ file system
[admittedly, it would be a superset of the old, but it would be
fundamentally incompatible with systems that use the original]. The same
would be true if one were to fix certain "fundamental" flaws of the HFS
or HFS+ file systems [HFS+ /is/ a fundamental fix of the HFS---look at
how it is, in actuality, a different file system: The only reason it is
at all viable as a "fix" of the old is that support for it has been added
to the old system {even though the old system's limitations don't allow
it to take full advantage of this new system}].
This is not to say that creating a new file system might not be such
a bad idea [I'm certainly entertaining the idea], it's just that we have
to recognize that that's exactly what we would be doing if we make
fundamental changes in the file system. Furthermore, even if a new file
system is deemed desirable, there will still be the issue of whether we
can make our "brave new world" work on older file systems. Whether it's
worth trying, and, if not, how to address such a loss in the most user
friendly manner possible.)

Post by Mason Mark
2) Types and Creator codes
Team A: Giving my documents Mac creator codes means that my
documents will open in my app when double clicked even if the user
renames the file "My Stuff" with no extension. A document's type
should not depend on the filename, computers should be smarter than
that, and have been in the Mac world for many years.
Team B: 95% of the world is used to using filename extensions. Type
and creator codes are more arcane relics we should do without.

You are certainly being disingenuous here.

It can be proven that, barring border cases (and there always are
such), all the functionality (even the ones that adversely affect the
users) of TYPE/CREATOR codes /can/ be encoded into the file name, and
that this can be done in such a way that the user will not know the
difference (except in some of the border cases, and when they use lower
level tools [a CLI, using one of the usual interpreters, can be rated as
one such]).

However, I believe it is far more instructive if we focus on
designing a system that is superior to either. Again, recognizing that
implementation on any particular file system (or implementing a /new/
file system) is a secondary consideration. (Getting Apple to adopt such
is certainly a further concern, but as we hash out generally acceptable
details we should certainly give Apple our feedback. I have already sent
some of my ideas on certain parts of this to the Cocoa team at Apple---it
turns out that Cocoa is far more amenable to such fundamental changes due
to the level of its abstractions [even if some of those abstractions are
presently implemented such as to allow programmers to take shortcuts in
certain directions]. It will certainly help if such abstractions are
woven into CoreFoundation/Foundation so they are fundamentally available
to all levels [admittedly, there will certainly be a lot more work
required of Carbon developers to take advantage of such, since their code
tends to expose more of the implementation details].)

Post by Mason Mark
3) References to open documents
Team A: An application should be smart enough to know that a user
has moved or renamed a file. It is still the same file; why should
an app lose track of it just because the name changed? Some other
mechanism than just the path is needed to keep track of it (FSRef
or whatever) and the Mac has long had this ability, which is one
reason why over the past years the Mac user experience has always
been better (except for the hellacious daily crashing of the OS,
ha ha ha).
Team B: Who needs that legacy junk? Paths work fine, 95% of the
world's users are used to it and know they can't move their files
while they are open and expect applications to keep up with them.
Furthermore, I like to rename a file to save it as a backup, rather
than using the cumbersome two-step process of Save As. Plus, the
Mac UI is overrated and NeXT kicked some serious ass, that's why
NeXT got paid $400 million to take over Apple.

Again, you are being disingenuous---even inflammatory.

The primary issue here is one of how the system behaves from a user's
perspective. If a file is moved or renamed, is it still the same file,
and in what sense? Even when the contents of a file are changed, to what
extent is it still the same file (this has bearing upon per-user
association of metadata)? Again, implementation details are secondary.
(As has been pointed out, Cocoa abstracts the nature of the file to the
point that such can certainly be implemented without any modification to
Cocoa applications---especially once the handling of aliases is
integrated [in fact, from my perspective, this is the only issue with
aliases---I, as a programmer, just as any user, should not have to be
bothered with whether I run across an alias, a symbolic or hard link, or
a mount point {this is not to say that there cannot be any way to find
out, it's just that the default is that it should "just work"}].)

[Erik M. Buck]

That was a very nice reasonable post. However, I think it is hopeless. None
of the advocates is willing to accept any change in behavior regardless of
merit. The current OS-X irritates all because it is not either of its
ancestors.

Specifically regarding FSRefs and Aliases:
If every computer was an island, every computer had exactly one file
system/hard disk, and users have grown accustomed to the aliases behavior,
you suggestion that aliases could be seamlessly incorporated in Cocoa would
be valid.

However, on our network, each user's home is on an NFS server. Our
employees are required to use and sometimes modify files that are stored in
shared network locations (sometimes in special configuration controlled file
systems). Aliases absolutely do not work in this environment. No matter
what the historic Mac user's expectations regarding aliases and open files,
they just don't (can't) work in the real world of networked computers. URLs
and paths do work. I personally think it is worse to expect users to detect
and accommodate aliases vs. path differences on a file by file / location by
location basis than to pith aliases completely and standardize on the
ubiquitous behavior. This is particularly important given that file systems
may be local or remote and may be mounted at any point in a file system and
that the mounts can be changed by administrators from local to remote or
visa versa without the user's knowledge.


This debate is really about networked computers with multiple file systems
vs. "This is MY Mac and it will NEVER be networked and I don't need no
network administrator between me and MY Mac"

[Fritz Anderson]

Post by Erik M. Buck
However, on our network, each user's home is on an NFS server. Our
employees are required to use and sometimes modify files that are stored in
shared network locations (sometimes in special configuration controlled file
systems). Aliases absolutely do not work in this environment. No matter
what the historic Mac user's expectations regarding aliases and open files,
they just don't (can't) work in the real world of networked computers. URLs
and paths do work.

Perhaps you are referring to a specific limitation of aliases (as now
implemented) to files in NFS shares. One of the canonical demos of
aliases has always been to put an alias to a shared file onto a
floppy, take it to another user's machine (or nowadays, mail it to
another user's machine) on the same net, double-click the alias, and
watch as it authenticates the access, mounts the share, and opens the
shared file.

[jgo]

Post by David W. Halliday
The primary issue here is one of how the system behaves from a user's
perspective. If a file is moved or renamed, is it still the same file,
and in what sense? Even when the contents of a file are changed, to what
extent is it still the same file (this has bearing upon per-user
association of metadata)? Again, implementation details are secondary.
(As has been pointed out, Cocoa abstracts the nature of the file to the
point that such can certainly be implemented without any modification to
Cocoa applications---especially once the handling of aliases is
integrated [in fact, from my perspective, this is the only issue with
aliases---I, as a programmer, just as any user, should not have to be
bothered with whether I run across an alias, a symbolic or hard link, or
a mount point {this is not to say that there cannot be any way to find
out, it's just that the default is that it should "just work"}].)

[Rick Roe]

There would seem to be two parts to this discussion; there's the technical
issue of how to make apps keep track of moved files, and the increasingly
inflamatory debate over whether that's a good thing. The latter subject
might be better discussed on macosx-talk.

[Bruce Toback]

Post by Scott Anguish
Nice to see that you're not blowing your claim to
ridiculous proportions. Decades huh? I think it was System 7
that first introduced them. So that would have been MAYBE 10
years ago.. MAYBE...

Well, my "Official" System 7 Alpha CD-ROM is dated May, 1990 --
so that's two different decades :-).

-- Bruce

--------------------------------------------------------------------------
Bruce Toback Tel: [phone]| My candle burns at both ends;
OPT, Inc. [phone]| It will not last the night;
11801 N. Tatum Blvd. Ste. 142 | But ah, my foes, and oh, my
friends -
Phoenix AZ 85028 | It gives a lovely light.
***@optc.com | -- Edna St. Vincent Millay

[Rob Rix]

Post by s***@execpc.com
Personally, I do not know how many times I have had a file open in
SimpleText and moved the
thing to the trash, saved my file, and then emptied my trash. AND THE
DANG THING ATE MY FILE!!!
I have always considered the SimpleText behavior a fundamental oversight
in design.

This is what I use the Save As... bit for. To me, that seems like it's
primary use.

For some reason, a lot of people seem to prefer arguing about the pros and
cons of this sort of system, instead of just working in a slightly
different (and no less efficient) manner when using the other method.
I don't get it.

-- Rob

[email appendRandomWittySig];

[Eric Peyton]

Guys,

You are all getting WAY off topic here. This list is one of my
favorites because it rarely drops into pontification and opinion. Let's
keep the topic on topic (Mac OS X Development). The answer the original
poster sought was given (it can be done in a Cocoa app, but is not
*currently* done for you in Cocoa. Both methods are currently supported
in OS X.)

Topic closed.

Move it to -talk.

Eric

On Fri, 8 Jun 2001, strobe anarkhos

Post by strobe anarkhos

Personally, I do not know how many times I have had a file open in SimpleText and moved the
thing to the trash, saved my file, and then emptied my trash. AND THE DANG THING ATE MY FILE!!!
I have always considered the SimpleText behavior a fundamental oversight in design.

Good grief, what a stretch.
I've been using macs every day since 1986 and have never done that. You see, you can't delete a file that's actually in use in MacOS. Compare that to other systems where any file can be deleted, open or not.
Now which system looks more foolproof?
_______________________________________________
MacOSX-dev mailing list
http://www.omnigroup.com/mailman/listinfo/macosx-dev

[Scott Anguish]

Post by Guillaume Lessard
He said he had relied on moveability of open files. That has been the
case since the original System in 1984. 17 years is a bit short for
"decades", but it doesn't warrant your hostile flames.
Do not let your ignorance of the original mac blind you.

I developed for the Mac for 10 years starting in 84.. I'm well
aware of what the system was capable of.

[Bruce Toback]

Post by Erik M. Buck
However, on our network, each user's home is on an NFS server. Our
employees are required to use and sometimes modify files that
are stored in
shared network locations (sometimes in special configuration
controlled file
systems). Aliases absolutely do not work in this environment.
No matter
what the historic Mac user's expectations regarding aliases and
open files,
they just don't (can't) work in the real world of networked computers.

I don't understand this statement. In the end, aliases are a
superset links; if the Alias Manager fails to resolve the alias
by using file and directory reference numbers, it falls back on
path searches -- including the entire original path. Aliases can
certainly cross file systems.

Aliases aren't just inodes; they're complex data structures with
lots of information for locating a file.

-- Bruce

--------------------------------------------------------------------------
Bruce Toback Tel: [phone]| My candle burns at both ends;
OPT, Inc. [phone]| It will not last the night;
11801 N. Tatum Blvd. Ste. 142 | But ah, my foes, and oh, my
friends -
Phoenix AZ 85028 | It gives a lovely light.
***@optc.com | -- Edna St. Vincent Millay

[t***@mac.com]

Post by Bruce Toback

Post by Erik M. Buck
However, on our network, each user's home is on an NFS server. Our
employees are required to use and sometimes modify files that
are stored in
shared network locations (sometimes in special configuration
controlled file
systems). Aliases absolutely do not work in this environment.
No matter
what the historic Mac user's expectations regarding aliases and
open files,
they just don't (can't) work in the real world of networked computers.

I don't understand this statement. In the end, aliases are a
superset links; if the Alias Manager fails to resolve the alias
by using file and directory reference numbers, it falls back on
path searches -- including the entire original path. Aliases can
certainly cross file systems.

That's not true. Broken aliases doesn't default to paths.
This is a frequent problem I (and many other users) have: suppose you
upgrade an application, say GraphicConverter, from v4.0 to 4.1. Both
executables are named 'GraphicConverter'. So you trash the older one,
empty the trash, then put the new one exactly in the same location, so the
paths are exactly the same.
THEN all aliases to it are broken (in the Launcher, in recent items,
etc.). REALLY BAD.
Ok, there is a trick: if you put the new item in the folder without moving
the older one first, so that the Finder will replace it, then the aliases
stay valid. BUT that means that you have to know the trick, which is not
obvious. Plus, it becomes complicated to handle if files have different
names (say 'MyApp 3.2' and 'MyApp 3.3', or if you would like to keep the
older item as a backup (very common for documents).

I'm a long time Mac OS user, and I am a great fan. There are some great
things here that I want to keep (most of them are in OS X already,
fortunately). I used to think that aliases were great, but now I realize
there are not so much, because they are TOO SMART. We have a shared iMac
at work (with OS 9), and I noticed that users there do the following when
they have finished their session: if they have edited some private
documents, they move them (usually from the desktop to a personal folder).
They believe that, since the document has moved, it cannot be retrieved by
the 'recent items' menu (they don't know how to clear that menu; that's
one of the small GOOD additions in OS X, BTW). They are wrong, as you know.
TOO SMART.

I wish the Finder would offer some simple way to creat symbolink links...

Thomas Lachand-Robert
********************** ***@mac.com
<< Et le chemin est long du projet à la chose. >> Molière, Tartuffe.

[t***@mac.com]

I don't find it really surprising since the documentation states that
the clipping rect is set to the View frame before calling - (void)
drawRect:(NSRect) frame;
If you want to draw something, don't draw it in a 2 by 2 pixels rect.

Had you read what I wrote, you can see that the clipping to the view is
not the cause of the problem, since the rectangles around the text are
drawn correctly. I'm not so new to Cocoa, I know that drawing to views are
clipped (would be a mess otherwise!), thank you.

Plus, it's easier for me to get your messages if I'm in the receivers...

Thomas Lachand-Robert
********************** ***@mac.com
<< Et le chemin est long du projet à la chose. >> Molière, Tartuffe.

[tlr]

Have you considered rendering the text into an image and compositing that,
instead of drawing the text directly into the view?

Please! I'm just trying to draw a simple short string in 12pt (means 12
PIXELS)! The question is whether or not NSAttributedString drawAtPoint
does work as expected --- which is not clear since Apple's doc is
incomplete. If it is not, I can fill a bug report, but I wonder if there
is something I don't understand.

Thanks anyway ;-)

I have put a more descriptive image at this place:
http://lachand.free.fr/bug.tiff
Here you can see on the left the original image as drawn in my view (note
that it is always the same string displayed: some are cropped, some are
not). On the right, the same thing after copy/paste in Sketch; now the
strings are not cropped, but in wrong places ??? In both case, the
recangles are in proper locations.

I would like to draw the string using a 12 pixels font, at the current
point in the view. I first tried to change the size of the font in the
attributes dictionary. It doesn't work,
since in that case the font is scaled down, and eventually disappear in
size < 0.7 (approximately). Don't ask me why.
So I decided to change the transformation matrix during drawing, doing
that (here I draw also a brown rectangle 'r' around the text; 'position'
r.origin = position; r.size = [string size];
[NSGraphicsContext saveGraphicsState];
transform = [NSAffineTransform transform];
[transform translateXBy:position.x yBy:position.y];
[transform scaleBy: scalefactor];
[transform translateXBy:-position.x yBy:-position.y];
[transform concat];
[[NSColor brownColor] set];
[[NSBezierPath bezierPathWithRect: r] stroke];
[string drawAtPoint: position];
[NSGraphicsContext restoreGraphicsState];
Surprise!!! Guess what?
The brown rectangle is drawn as expected, but only SOME PART of the
string is drawn: this depends on the location of the string in the view,
but it looks usually clipped to its lower corner; sometimes nothing
appears, sometimes almost everything. Note that it is not related to the
current clipping path, since the brown rectangle appears as a whole.
Next puzzle: My view has a TIFFrepresentation method, doing what you can
imagine. If I call it, I can now see all the strings in the TIFF, but
they are not in the correct locations (they appear slightly moved with
respect to their brown rectangle).
If anyone can help me to solve that, I would be very grateful; I'm
turning mad about that.

Thomas Lachand-Robert
********************** ***@mac.com
<< Et le chemin est long du projet à la chose. >> Molière, Tartuffe.

[David W. Halliday]

Post by tlr

Have you considered rendering the text into an image and compositing that,
instead of drawing the text directly into the view?

Please! I'm just trying to draw a simple short string in 12pt (means 12
PIXELS)! The question is whether or not NSAttributedString drawAtPoint
does work as expected --- which is not clear since Apple's doc is
incomplete. If it is not, I can fill a bug report, but I wonder if there
is something I don't understand.
Thanks anyway ;-)
http://lachand.free.fr/bug.tiff
Here you can see on the left the original image as drawn in my view (note
that it is always the same string displayed: some are cropped, some are
not). On the right, the same thing after copy/paste in Sketch; now the
strings are not cropped, but in wrong places ??? In both case, the
recangles are in proper locations.

I assume you only put the TIFF representation on the pasteboard? (The
pasted image does appear to follow your description of what the
TIFFrepresentation method gave you.) Remember, the receiver of the copy/paste
can pick whatever representation it wishes from the list you provide.
I also suppose that the blue circle is another piece you added, after your
original post.

Is your "scalefactor" less than one, or greater than one? (I suspect we are
having an interaction with the clipping rectangle, and probably not in a way
that Cocoa would normally intend, since it's acting upon the text differently
than the graphics. It does look like an implementation bug, but I'm sure we
will need to look into this further.) It is interesting to note how both images
suggest an interaction with the scale factor. (I expect you have no problem
whatever if the scale factor is unity. Correct?)

I expect that the "usual" way to accomplish what you are attempting would be
to adjust the font size (the fonts can be any size you wish). Furthermore, I
expect that doing so would not suffer from this malady.
That being said, we still have a mystery on our hands here as to why the
text and graphics are being treated differently. It probably suggest something
in the way the graphics pipeline is working: Either we simply shouldn't do such
things (sounds like a poor restriction to me) or you've tickled a bug in the
pipeline that simply wasn't discovered before because "of course /everybody/
knows that the /right/ way to do such things is ...".

Do you get this same behavior if you render into an image, as opposed to a
view? (Since the TIFFrepresentation is probably implemented by you, it has to
come under the same suspicion as the original drawing code---I'm sure you
understand.)
Using the same drawing code (surrounded by [image lockFocus] and [image
unlockFocus], of course) directly to an image could shed some light here (takes
out at least one variable). Of course it has the potential to simple open up a
whole new mystery.

Post by tlr

...

Thomas Lachand-Robert
...

Just trying to help.

David ***@WebWizardry.net

P.S. If you wish, you could send me your code, and I could try and port it to
OPENSTEP 4.2 to see what it has to say about such things. (Of course, the nibs
will be of little use, except that I can read the XML inside myself. So if your
work in IB is particularly complex, some pointers from you could be helpful in
my recreation.)
Just a thought. (Another data point---especially if it's a bug in the
system.)

[Jonathan Hendry]

Post by Fritz Anderson

Post by Erik M. Buck
However, on our network, each user's home is on an NFS server. Our
employees are required to use and sometimes modify files that are
stored in
shared network locations (sometimes in special configuration
controlled file
systems). Aliases absolutely do not work in this environment.
No matter
what the historic Mac user's expectations regarding aliases and
open files,
they just don't (can't) work in the real world of networked
computers. URLs
and paths do work.

Perhaps you are referring to a specific limitation of aliases (as
now implemented) to files in NFS shares. One of the canonical
demos of aliases has always been to put an alias to a shared file
onto a floppy, take it to another user's machine (or nowadays,
mail it to another user's machine) on the same net,

Assuming that the other user's machine is also running an OS that knows
about aliases.

Post by Fritz Anderson
double-click the alias, and watch as it authenticates the access,
mounts the share, and opens the shared file.

The problem is this. You're working on your OS X machine, with files
from some directory mounted via NFS. You want to create an alias
between two locations on the NFS volume. NFSVolume/foo -> NFSVolume/bar

This is different from the situation you suggested, where you are
creating an alias which lives on HFS, that refers to a file that lives
on NFS. That is not a problem, because HFS knows about aliases.

[strobe anarkhos]

Post by Jonathan Hendry

Perhaps you are referring to a specific limitation of aliases (as now implemented) to files in NFS shares. One of the canonical demos of aliases has always been to put an alias to a shared file onto a floppy, take it to another user's machine (or nowadays, mail it to another user's machine) on the same net,

Assuming that the other user's machine is also running an OS that knows
about aliases.

Actually that has nothing to do with it.

An alias is an arbitrary description of how to locate a file. The limitations of this description are the limitations of the protocol, not the server.

[tlr]

Thanks a lot for your answer. This suggested some other tryouts, and I now
definitely believe it's a bug in NSAttributedString drawAtPoint. Indeed, I
changed the scalefactor for different values, and here is what happens: as
you guessed, the drawing is incorrect only if the scalefactor if < 1.
For instance, the view is about 300 pt wide; if the bounds are made to
have width == 1000, then everything is fine and display is correct. On the
other hand, if the bounds have width == 100, some strings are cropped
(those who lies in the upper right corner, basically); if the bounds have
width == 10, then the situation becomes worse (that was the case of the
image linked below); if width == 1, then no string appears at all.

About the font size: adjusting it DOES NOT work. It appears that the font
is first (internally) rendered at the requested size, THEN scaled to the
view. This implies that it appears very irregular if the final size is
small (1pt say, that is scalefactor = 1/12); and eventually it disappears
if this size is less than 0.6 (about). So this could not be the "usual way"
to do that.

About the behavior in a rendered image, see the TIFF representation. It is
abtained by copying, and the copy procedure is just the same as used by
Sketch. In particular, it uses exactly the same rendering procedure. Here
the text appears completly, but in a wrong place!

I have put the whole project in http://lachand.free.fr/BugDrawAtPoint.dmg.
sit
You can try as follows: build the project, run, and in the window at the
prompt '>>' type the string you like. You will se the result with radius =
10, where 'radius' is half the height of th bounds in the graphics window.
You can change the value of 'radius' in the file 'minitest.c' (try 1000,
100, 1).

NOTE: This project is free (GPL) and is part of "The Commandant project"
(see http://lachand.free.fr/ but it is not translated to english, yet).

Post by David W. Halliday

Post by tlr
http://lachand.free.fr/bug.tiff
Here you can see on the left the original image as drawn in my view (note
that it is always the same string displayed: some are cropped, some are
not). On the right, the same thing after copy/paste in Sketch; now the
strings are not cropped, but in wrong places ??? In both case, the
recangles are in proper locations.

I assume you only put the TIFF representation on the pasteboard? (The
pasted image does appear to follow your description of what the
TIFFrepresentation method gave you.) Remember, the receiver of the copy/
paste
can pick whatever representation it wishes from the list you provide.
I also suppose that the blue circle is another piece you added, after
your
original post.
Is your "scalefactor" less than one, or greater than one? (I suspect
we are
having an interaction with the clipping rectangle, and probably not in a
way
that Cocoa would normally intend, since it's acting upon the text
differently
than the graphics. It does look like an implementation bug, but I'm sure
we
will need to look into this further.) It is interesting to note how both
images
suggest an interaction with the scale factor. (I expect you have no
problem
whatever if the scale factor is unity. Correct?)
I expect that the "usual" way to accomplish what you are attempting
would be
to adjust the font size (the fonts can be any size you wish).
Furthermore, I
expect that doing so would not suffer from this malady.
That being said, we still have a mystery on our hands here as to why
the
text and graphics are being treated differently. It probably suggest
something
in the way the graphics pipeline is working: Either we simply shouldn't
do such
things (sounds like a poor restriction to me) or you've tickled a bug in
the
pipeline that simply wasn't discovered before because "of course
/everybody/
knows that the /right/ way to do such things is ...".
Do you get this same behavior if you render into an image, as opposed
to a
view? (Since the TIFFrepresentation is probably implemented by you, it
has to
come under the same suspicion as the original drawing code---I'm sure you
understand.)
Using the same drawing code (surrounded by [image lockFocus] and
[image
unlockFocus], of course) directly to an image could shed some light here
(takes
out at least one variable). Of course it has the potential to simple
open up a
whole new mystery.

Thomas Lachand-Robert
********************** ***@mac.com
<< Et le chemin est long du projet à la chose. >> Molière, Tartuffe.

[Jonathan Hendry]

For instance, when I copy one of the example projects, and launch
PB on the copy, I expect it to use the files in the new directory.
When I move that project directory to a different directory, I
expect it to still find libraries. Sometimes when I'm in an editor
and move a file out from under it, it's because I want a copy,
but other times it's because I want to move that file and work on
it in a different base location.

Would it be possible for someone with copious spare time to
whip up a description of behaviors that are expected by
Mac users, and supported by the OS, but not automatically
handled by Cocoa?

Us innorant NeXT-heads would probably find it useful. Especially
if there were example code for any Carbon stuff required.

It'd be really keen if someone made a FriendlyFilesKit framework,
that handled all this stuff.

[strobe anarkhos]

Post by Jonathan Hendry
Would it be possible for someone with copious spare time to
whip up a description of behaviors that are expected by
Mac users, and supported by the OS, but not automatically
handled by Cocoa?

Yes, I think I've done this a few hundred times |-)

The screwy thing is they ought to be handled by Cocoa, by default. This isn't OPENSTEP after all. If Cocoa were ported to Windows I would expect open files in Cocoa Windows apps to act like other open files (can't move them).

Anyway some casual observations about Cocoa (no particular order):

* Doesn't use something equivalent to FSRefs (covered to death already). This causes many, many problems.

* Can't handle aliases (used a lot. Dock uses aliases, internet prefs uses aliases, users use aliases, etc.)

* selected text isn't immediately draggable (and I don't think you can change this...yet)

* Selecting text in Cocoa apps is like windows in that selecting a line of text includes the carriage return (this one drives me up the WALL!)

* If an app is going to add a filename extension (like Graphic Converter) you can delete it in the save dialog box. By default Cocoa seems to assume I want to use a filename extension and doesn't give me the option not to. The entire filename ought to be present, like GC.

* Cocoa apps don't seem to care if a file is already open. Most Carbon apps don't allow this, and those which do usually warn when they are open and won't save changes until they are no longer open.

* Utility windows (aka floating windows or NSPanels) use smaller title bars and often smaller scrollers. They should always hide when the app is in the background. If they don't, they are not utility windows and should not use the small title bars or scroll bars. Floating windows which are not utility windows never occur except in purposely annoying apps like Hotline Carbon's banner ad. Global floating windows which never hide are fine (like ICQ). Global floating windows which are semitransparent would kick ass |-)

* Wells are rarely used. Mac users usually use draggable items in lists. The well in OmniWeb's download window is a good example of this, mac users would prefer to drag the item from the list instead of clicking the list then dragging from the well. Saves space too.

* Min screen requirements for an app are now 640x480. 512 is even better for those of us who have kiosks setup |-)

* I could probably write a six page email on command keys. Hopefully QuicKeys will rock and I won't have to. Suffice it to say, F-keys are usually reserved for global stuff (this isn't windows), command-option-key is a good combo for global stuff too, like SERVICES (I find services useless since the hotkey keeps changing)! Don't use command-m for a service, geez.

* I'm sure the Aqua HI Guidelines say this, but all commands ought to be in the main menu hierarchy. Don't make people use toolbars and contextual menus, there should always be the option of using the main menu. Since it's a single hierarchy it's easier to describe how to do something (just follow a simple path like menu->edit->undo) and there is always a possibility of making macros with QuicKeys or something.

less critical annoyances:

* Cocoa apps don't use appearance manager layouts (I can't change the title bar button locations, etc.)

* Cocoa apps don't remember their window locations when using multiple monitors (one exception: Terminal).

I'm sure I've missed some, but these are the most glaring.

[Rosyna]

Floating windows always hide when the app is not frontmost, utility
windows are global. (At least in carbon)

Post by strobe anarkhos
* Utility windows (aka floating windows or NSPanels) use smaller
title bars and often smaller scrollers. They should always hide when
the app is in the background. If they don't, they are not utility
windows and should not use the small title bars or scroll bars.
Floating windows which are not utility windows never occur except in
purposely annoying apps like Hotline Carbon's banner ad. Global
floating windows which never hide are fine (like ICQ). Global
floating windows which are semitransparent would kick ass |-)

[Nat!]

Post by Jonathan Hendry

For instance, when I copy one of the example projects, and launch
PB on the copy, I expect it to use the files in the new directory.
When I move that project directory to a different directory, I
expect it to still find libraries. Sometimes when I'm in an editor
and move a file out from under it, it's because I want a copy,
but other times it's because I want to move that file and work on
it in a different base location.

Would it be possible for someone with copious spare time to
whip up a description of behaviors that are expected by
Mac users, and supported by the OS, but not automatically
handled by Cocoa?
Us innorant NeXT-heads would probably find it useful. Especially
if there were example code for any Carbon stuff required.
It'd be really keen if someone made a FriendlyFilesKit framework,
that handled all this stuff.
_______________________________________________

Yes that would be nice. In the long run though, I expect Cocoa to this
stuff automatically for me.

Nat!

[Graeme Hiebert]

Post by strobe anarkhos
The screwy thing is they ought to be handled by Cocoa, by default. This
isn't OPENSTEP after all. If Cocoa were ported to Windows I would
expect open files in Cocoa Windows apps to act like other open files
(can't move them).

Actually, I believe that the Windows behaviour you describe is enforced
at a much lower level, so there really would be no choice anyway.

Post by strobe anarkhos
* selected text isn't immediately draggable (and I don't think you can
change this...yet)

I much prefer the Cocoa way myself (though it needs more obvious
feedback, like a cursor change). I would rather see Carbon apps change
on this one.

Post by strobe anarkhos
* Selecting text in Cocoa apps is like windows in that selecting a line
of text includes the carriage return (this one drives me up the WALL!)

This should be a user option in Cocoa. Unfortunately it's too late in
Carbon, though I suppose a good portion of Carbon apps could be made to
adhere to the user preference if Metrowerks rewrote a bit of code, and
the app providers rebuilt their apps with the results. (Hopefully we'll
see more shared library use by Carbon programmers...)

Post by strobe anarkhos
* If an app is going to add a filename extension (like Graphic
Converter) you can delete it in the save dialog box. By default Cocoa
seems to assume I want to use a filename extension and doesn't give me
the option not to. The entire filename ought to be present, like GC.

Good idea.

Post by strobe anarkhos
* Cocoa apps don't seem to care if a file is already open. Most Carbon
apps don't allow this, and those which do usually warn when they are
open and won't save changes until they are no longer open.

This is a shame, but what are you going to do with all those Carbon apps
out there?

Post by strobe anarkhos
* Utility windows (aka floating windows or NSPanels) use smaller title
bars and often smaller scrollers. They should always hide when the app
is in the background. If they don't, they are not utility windows and
should not use the small title bars or scroll bars.

<snip>

Good point.

Post by strobe anarkhos
* Wells are rarely used. Mac users usually use draggable items in
lists. The well in OmniWeb's download window is a good example of this,
mac users would prefer to drag the item from the list instead of
clicking the list then dragging from the well. Saves space too.

Good observation. I would say that the icon itself should appear in the
list, to act as the representation for dragging.

Post by strobe anarkhos
* I could probably write a six page email on command keys. Hopefully
QuicKeys will rock and I won't have to. Suffice it to say, F-keys are
usually reserved for global stuff (this isn't windows),
command-option-key is a good combo for global stuff too, like SERVICES
(I find services useless since the hotkey keeps changing)! Don't use
command-m for a service, geez.

Yes, some direction on when to use command-option and when to use
command-functionkeys would be a Good Thing. I like the idea of
reserving Command-Option for services and things. The Services menu
should probably be made completely user-definable in terms of command
key usage.

Post by strobe anarkhos
* I'm sure the Aqua HI Guidelines say this, but all commands ought to
be in the main menu hierarchy. Don't make people use toolbars and
contextual menus, there should always be the option of using the main
menu. Since it's a single hierarchy it's easier to describe how to do
something (just follow a simple path like menu->edit->undo) and there
is always a possibility of making macros with QuicKeys or something.

I'd like to see Mac OS's "Command+FirstLetterOfDialogButton" to select
buttons in a modal dialog/panel/sheet brought forward as well.

-g
--

Post by strobe anarkhos
* Cocoa apps don't use appearance manager layouts (I can't change the
title bar button locations, etc.)
* Cocoa apps don't remember their window locations when using multiple
monitors (one exception: Terminal).

[Rosyna]

Yes, the user should have to select how carriage returns are
handled... How many users even know what a carriage return it?

Post by Graeme Hiebert

Post by strobe anarkhos
* Selecting text in Cocoa apps is like windows in that selecting a
line of text includes the carriage return (this one drives me up
the WALL!)

This should be a user option in Cocoa

[David Dunham]

Post by Jonathan Hendry
Would it be possible for someone with copious spare time to
whip up a description of behaviors that are expected by
Mac users, and supported by the OS, but not automatically
handled by Cocoa?

I appreciate your asking -- many NeXT types seem not to care.

Oh, stuff like using file types (not extensions), putting fonts in the
menu so they're directly available instead of in a floating window that
gets in the way. Aliases (since a file is a file, no matter where it's
moved to).

Strobe had a bunch of good ones.

It's really shocking that Cocoa doesn't do all this stuff already. I
mean, no matter what its heritage, it's supposed to be the premier way
to write Mac OS X applications.

Hmm, I just came to the realization that this is why I'm not using
Cocoa. Not just because I have to learn a new language (because Java
support is only 95% there), but because I will have to work so hard to
create a Macintosh application. (Writing an application that runs under
OS X is apparently easy, but it's not yet a Mac application.)

David Dunham A Sharp ***@a-sharp.com
Voice/Fax: [phone] http://a-sharp.com
Efficiency is intelligent laziness.

[Rosyna]

Ah, the font panel. What a piece of &$*@. There is no way to know if
the choice is sticking (there is no ok button, only a close box)and
there is no way to see from a glance what document it affects.

It's behavior is VERY inconsistent. Change to menu views and make a
selection that contains two fonts. In list mode, do the same thing.
In the former, the menus change to the first selection and the size
is left blank (this is with fonts of the same size), in the latter,
everything but all fonts collection is deselected.

And what happens when the user knows EXACTLY what font he wants? He
has to first go to the font menu, open the font panel, find the
collection (if the user changed widths--that's another thing, why
when stretching the window to the right, something appears on the
left?), then the font, then the style, then the size. On the Mac OS
(AppleWorks, an Apple branded product even), he goes to the Font
menu, sees the what all the fonts look like, and chooses the one he
wants. Even in my Email client this is better that OS X, I have a
visible Font menu in the email message itself.

Two other things about it that bother me. First, why is 8pt even a
choice? No font is legible at that size. Second, and I think this is
a bug, select some text, enter a value into the size field (something
noticeably different), hit tab, unselect the text you just selected,
then reselect any part. The font size field doesn't change!

It'd be nice to sit someone down that has never used fonts on a
computer before and ask them to try to change the text style on three
different computers, a Windows Machine, a classic Mac OS machine, and
a Mac OS X machine.

[Greg Titus]

Post by David Dunham

Post by Jonathan Hendry
Would it be possible for someone with copious spare time to
whip up a description of behaviors that are expected by
Mac users, and supported by the OS, but not automatically
handled by Cocoa?

I appreciate your asking -- many NeXT types seem not to care.

Answering this question would be great, and I appreciate Strobe
mentioning his list...

Post by David Dunham
Oh, stuff like using file types (not extensions), putting fonts in the
menu so they're directly available instead of in a floating window that
gets in the way. Aliases (since a file is a file, no matter where it's
moved to).

Aliases we've already discussed to death. Using extensions and putting
fonts in a font panel ARE the way to write Mac OS X applications. I
don't think Apple representatives have been unclear in these areas at
all. Heck, Steve Jobs has demoed the "floating window that gets in the
way" multiple times as the new and improved way to handle fonts in a Mac
OS X application. He seemed pretty excited about it, in fact.

If you don't like the direction Apple is choosing to go, that's fine,
but IMHO, those value judgements don't belong on a useful list of
"behaviors users expect of the OS but are not automatically handled by
Cocoa". Because I think such a list should be made up of items that Mac
OS X users expect, NOT what classic Mac OS users expect. These are not
necessarily the same thing.

Which is why I think we need to look at what Apple is saying publicly,
what they are doing with their own applications, and what appears in
documents like the Mac OS X Human Interface Guidelines. (And why it
would be incredibly useful to get official "rulings" on all these
things.)

I absolutely agree, by the way, that the default assumption should be
that OS X is still a Mac OS and we should write our apps to do things
the way classic users expect. But only as a default assumption. If Apple
explicitly and publicly changes the rules, I say: assume they know what
they are doing.

--Greg

[Fritz Anderson]

Post by Greg Titus
Aliases we've already discussed to death. Using extensions and
putting fonts in a font panel ARE the way to write Mac OS X
applications. I don't think Apple representatives have been unclear
in these areas at all. Heck, Steve Jobs has demoed the "floating
window that gets in the way" multiple times as the new and improved
way to handle fonts in a Mac OS X application. He seemed pretty
excited about it, in fact.

I almost completely agree.

Let me gently prevent you from getting away with slipping extensions
into much-longer praise of the font panel, which is at least arguably
an improvement, and which we can avoid if it turns out not to be a
good idea.

My delight in OmniOuliner is impaired by its secretly inflating
5-character file names by 180%, and going on strike if I try to
regain control of my file names. This, despite Apple's backing-off
on extensions, and advising the additional use of file types where
practicable. If Mac OS programmers shouldn't assume that what they
are used to is the only right way, then neither should
Windows/Solaris programmers.

Post by Greg Titus
If you don't like the direction Apple is choosing to go, that's
fine, but IMHO, those value judgements don't belong on a useful list
of "behaviors users expect of the OS but are not automatically
handled by Cocoa". Because I think such a list should be made up of
items that Mac OS X users expect, NOT what classic Mac OS users
expect. These are not necessarily the same thing.

Two points. Minor point: Mac OS X users, one and all, invested in
machines that ship with a pre-X Mac OS. The overwhelming majority
bought machines that didn't ship with Mac OS X at all. Classic Mac
OS users may not be 100% of Mac OS X users, but it's not far from 98%.

This is not to take away from your excellent general point: We are
looking for users who are not well-served by Windows, or UNIX, or
even classic Mac OS. Today's Mac OS X user is a Mac OS 9 purchase;
but we hope tomorrow's user will be using Mac OS X because it is
better than anything else, no matter what, if any, other system he is
used to. We should value excellence over authenticity to old ways.

I believe, however, that as between those old ways, classic Mac OS is
entitled to respect as having met our goals of excellence better than
the others.

Second point, on the terms of debate, and not at all a reflection on
the great blessing Greg Titus and Omni are to our community: It
seems to be the idea that any design decision that does not
immediately crash the machine is merely a "value judgment," by which
is meant "a question of taste."

No: Ease-of-use, as measured by the user's efficiency and error rate
in using and learning applications, _is_ a value, but it is not a
matter of taste on which artistes may differ. It is an engineering
goal that can be met or failed. If a design choice measurably
reduces the efficiency or safety of the user's work, then saying so
is a matter of engineering. It is also a value judgment -- we value
supporting people over abusing them -- but it is not legitimately
debatable. (Except in terms of tradeoffs, in which all engineering
decisions are debatable.)

Post by Greg Titus
I absolutely agree, by the way, that the default assumption should
be that OS X is still a Mac OS and we should write our apps to do
things the way classic users expect. But only as a default
assumption. If Apple explicitly and publicly changes the rules, I
say: assume they know what they are doing.

I assume Apple is working competently, even doing the best possible
job. I can't assume, though, that Apple is infallible on every
detail -- they had to let Mac OS X out a week or two before it was
perfect. Cocoa shows imperfect integration with Mac OS, and
imperfect separation from Windows and OpenStep. Good? Yes, very
good. But not _perfect._ There were defects in Apple's
documentation, examples, and practice under Mac OS 9 (Undo came 15
years late to the Finder, and still works incompletely); still less
can we close discussion by appealing to the same things, so much less
complete, in Mac OS X.

My read on file typing, for instance, is that the technical and
political difficulties were such that they went with something
good-enough, and left refinement till after release, when they could
hear from the market (including Omni, and including me). Other
features seem also to await refinement. I do think Apple is serious
about these things, and that they are listening.

-- F

[strobe anarkhos]

Which is why I think we need to look at what Apple is saying publicly, what they are doing with their own applications, and what appears in documents like the Mac OS X Human Interface Guidelines. (And why it would be incredibly useful to get official "rulings" on all these things.)
I absolutely agree, by the way, that the default assumption should be that OS X is still a Mac OS and we should write our apps to do things the way classic users expect. But only as a default assumption. If Apple explicitly and publicly changes the rules, I say: assume they know what they are doing.

The problem with Apple's HI guidelines is they always lag what the mac community chooses as standards and are always incomplete. The Aqua HI Guidelines are no exception. There are countless discussions going on about what the guidelines are missing like:

* text selection behavior

* command-click-through (or other modified click-through). Something IMO OS X needs since it takes a click just to activate a window. Neither Carbon or Cocoa implements it fully or sanely.

* command-dragging lists/matrixes (only mentions command-click)

* drag+drop issues (could write a whole email on this alone)

* window management

and others.

I don't suggest you wait for Apple to decide what to settle in their guidelines. Nobody waited for the Finder in MacOS to use command-click instead of shift-click.

[David Dunham]

Post by Greg Titus

Post by Jonathan Hendry
Would it be possible for someone with copious spare time to
whip up a description of behaviors that are expected by
Mac users, and supported by the OS, but not automatically
handled by Cocoa?

Aliases we've already discussed to death. Using extensions and putting
fonts in a font panel ARE the way to write Mac OS X applications. I
don't think Apple representatives have been unclear in these areas at
all. Heck, Steve Jobs has demoed the "floating window that gets in the
way" multiple times as the new and improved way to handle fonts in a
Mac OS X application. He seemed pretty excited about it, in fact.

Steve is great at making a feature out of a bug... (He was real big on
the single application mode, which actual users seem to have told Apple
was a bad idea.)

But you're missing the point. Mac users expect certain behavior. Mac OS
X in general, and Cocoa apps in particular, do not give them the
behavior they expect. In many cases, I think Cocoa (or Cocoa
programmers) could provide those behaviors pretty easily (such as not
insisting on an extension)

Post by Greg Titus
I think such a list should be made up of items that Mac OS X users
expect, NOT what classic Mac OS users expect. These are not necessarily
the same thing.

I'd love it if Apple is actually growing the Mac market by means of OS
X, but in the absence of actual data, I have to assume it's mostly
classic Mac OS users.

David Dunham A Sharp ***@a-sharp.com
Voice/Fax: [phone] http://a-sharp.com
Efficiency is intelligent laziness.

[strobe anarkhos]

I'd love it if Apple is actually growing the Mac market by means of OS X, but in the absence of actual data, I have to assume it's mostly classic Mac OS users.

Whether this is true or not, I don't think matters. As a long time mac user there are lots of things in MacOS which never made any sense, like the Desktop. I disabled my desktop in OS X using TinkerTool. Nothing but an easily hidden background which mac users spend countless wasted minutes reorganizing windows to keep unobscured.

I was also against bringing the Apple Menu back. I'd get rid of it if I could.

However I think everybody can recognize that mac developers have placed a great deal of effort into making their interfaces the most easily understood and consistent, their users demand it. Apple has also placed a high priority on human interface design. Things like FSRefs, aliases, file types and creators, and various finder flags were always designed with the user in mind. This is a far cry from other systems which were designed to work well enough for a human to adapt to.

It's very easy to say it ought to be a user preference whenever there is anything slightly controversial like the desktop, apple menu, control strip, or FSRefs. However in my eyes, some ways of doing things are just retarded and I'm not going to pretend otherwise just to comb egos. And don't tell me Apple brought the Apple Menu back for any other reason (global options, whatever)

We're all OS X users here, let's just try to prevent it into becoming some toolkit-riddled good-enough 'you want GUI, I got GUI right here' X11 platform, or for that matter some macos-user kiss-ass platform (oops, too late).

[Bruce Toback]

Post by strobe anarkhos
As a long time mac user there are lots of things in MacOS which
never made any sense, like the Desktop. ... Nothing but an
easily hidden background which mac users spend countless wasted
minutes reorganizing windows to keep unobscured.
I was also against bringing the Apple Menu back. I'd get rid of
it if I could.
... in my eyes, some ways of doing things are just retarded and
I'm not going to pretend otherwise just to comb egos. And don't
tell me Apple brought the Apple Menu back for any other reason
(global options, whatever)

Good thing you're not in charge of designing the HI for *my*
machine! :-) And incidentally, they did *not* bring the Apple
menu back. They just beat it senseless and left it gasping at
the bottom of the screen.

A general principle: don't confuse "I don't need it" or "I've
never used it" with "it's a dumb idea."

-- Bruce

[Jonathan Hendry]

Post by strobe anarkhos
Things like FSRefs, aliases, file types and creators, and various
finder flags were always designed with the user in mind.

Well, I'm sure they were also designed with the system limitations
of the day in mind as well...

[Jason H Clouse]

<<No: Ease-of-use, as measured by the user's efficiency and error rate
in using and learning applications, _is_ a value, but it is not a matter
of taste on which artistes may differ.>>

Oh but it is! I have a distinct dislike for the Mac OS interface and
make far more mistakes with it than I do with the old OPENSTEP interface
or with Bash.

J
________________________________________________________________
GET INTERNET ACCESS FROM JUNO!
Juno offers FREE or PREMIUM Internet access for less!
Join Juno today! For your FREE software, visit:
http://dl.www.juno.com/get/tagj.

[Eric Peyton]

This post has absolutely *nothing* to do with development on OS X
as far as I can see. This is a personal opinion describing your
"take" on the OS X font panel. Please take your rants to -talk
mailing lists or to the apple HI talk list where you can talk about
the merits or lack of them of portions of the operating system such
as this, and stop wasting our bandwidth. None of this belongs on
an OS X *development* list.

Eric

if the choice is sticking (there is no ok button, only a close
box)and there is no way to see from a glance what document it
affects.
It's behavior is VERY inconsistent. Change to menu views and make
a selection that contains two fonts. In list mode, do the same
thing. In the former, the menus change to the first selection and
the size is left blank (this is with fonts of the same size), in
the latter, everything but all fonts collection is deselected.
And what happens when the user knows EXACTLY what font he wants?
He has to first go to the font menu, open the font panel, find the
collection (if the user changed widths--that's another thing, why
when stretching the window to the right, something appears on the
left?), then the font, then the style, then the size. On the Mac
OS (AppleWorks, an Apple branded product even), he goes to the
Font menu, sees the what all the fonts look like, and chooses the
one he wants. Even in my Email client this is better that OS X, I
have a visible Font menu in the email message itself.
Two other things about it that bother me. First, why is 8pt even a
choice? No font is legible at that size. Second, and I think this
is a bug, select some text, enter a value into the size field
(something noticeably different), hit tab, unselect the text you
just selected, then reselect any part. The font size field doesn't
change!
It'd be nice to sit someone down that has never used fonts on a
computer before and ask them to try to change the text style on
three different computers, a Windows Machine, a classic Mac OS
machine, and a Mac OS X machine.
_______________________________________________
MacOSX-dev mailing list
http://www.omnigroup.com/mailman/listinfo/macosx-dev

[Rosyna]

The conversation this spawned from didn't either. and if you didn't
want to waste bandwidth, why did you respond to the list about it?

This post has absolutely *nothing* to do with development on OS X as
far as I can see. This is a personal opinion describing your "take"
on the OS X font panel. Please take your rants to -talk mailing
lists or to the apple HI talk list where you can talk about the
merits or lack of them of portions of the operating system such as
this, and stop wasting our bandwidth. None of this belongs on an OS
X *development* list.

[Bruce Toback]

Post by Rosyna
Two other things about it that bother me. First, why is 8pt
even a choice? No font is legible at that size.

Hmm... my development machines are usually set for 7- or 8pt
text. I buy top-quality displays so that I can fit as much text
as possible onto the screen.

-- Bruce

--------------------------------------------------------------------------
Bruce Toback Tel: [phone]| My candle burns at both ends;
OPT, Inc. [phone]| It will not last the night;
11801 N. Tatum Blvd. Ste. 142 | But ah, my foes, and oh, my
friends -
Phoenix AZ 85028 | It gives a lovely light.
***@optc.com | -- Edna St. Vincent Millay

[Rosyna]

Video card resolution and font points really have nothing to do with
each other. an 8 point font on the Mac OS takes up about 8 pixels,
this is not enough space for most fonts to be completely formed.
There are some exceptions like Mini7, which is designed with 7 pixels
in mind. On windows, 7pt is about 9 or 10 pixels (9 1/3rd pixels),
which is plenty of space for a fully formed font. If you had an 8pt
font on the Mac, it would be equal in size to a 6pt font on the PC.

Of course, I could be wrong.

Hi Rosyna,

Is your development machine a windows machine? If not, what fonts do you use?

[Thomas Hudson]

Post by Rosyna
Video card resolution and font points really have nothing to do with
each other. an 8 point font on the Mac OS takes up about 8 pixels, this
is not enough space for most fonts to be completely formed.

Font handling is done incorrectly on every system. A point is 1/72 of an
inch and
should be on every monitor. Monitor resolution was hardcoded to 72 DPI
on older
Mac systems and this is wrong. The DPI is hardcoded to 96 DPI on
windows, and
this is wrong. It can be set on startup in X windows, but usually is
left at 100 DPI.

An 8 point font should be 0.111 inches (1/9) high on every system as
measured
on the screen. The monitor on an iMac measure 8 inches high and at 768
vertical
resolution gives a DPI of 85, which means an 8 point font would be
about 9.5
pixels. An iBook is 7.5 vertical display at 600 rendering 80 DPI. So 8
points would
be 8.8 pixels. .My development monitor has a vertical of 12 w/ 1200
pixels, so
100 DPI and an 8 point font size of 11 pixels. On this monitor, even a
seven
point font is legible (9.7 pixels).

Points are an absolute measure of size and shouldn't be dependent on
monitor
resolution. A 72 point font should be one inch on every monitor.

I hope more OS's in he future will handle point size properly. Then when
we
render a page at 100 percent it will exactly match printed output. I've
had the
frustrating task in the last year of trying to get fonts displayed
properly on Linux
and Windows, in an application written for another platform which wrongly
assumed that 72 points == 72 pixels. We finally scrapped the built in
font
handling and used FreeType.

Tomy

----
Hacker looking for work.
http://www.tomy.net/thudson/resume.html
http://www.tomy.net/thudson/tools.html
---

[vaucanson]

Post by Rosyna
Two other things about it that bother me. First, why is 8pt even a
choice? No font is legible at that size.

On screen may be, but it's a fairly common size for print work.

-jacques

[Rosyna]

Where can you set this resolution? And where can you get it
programmatically? (How's that for tying it to Mac OS X dev?)

It would NOT be wise to show 72point font as 1 inch at every
resolution, this would be very wrong. Not only would it defeat the
purpose of higher resolutions, and case unbelievable problems with
webpages, it would make the text MUCH bigger than the graphics. All
designers care about is font size relative to the rest of the
document, that should be consistent but would not be if the font size
changes and the graphic size doesn't?

Post by Thomas Hudson
Font handling is done incorrectly on every system. A point is 1/72
of an inch and
should be on every monitor. Monitor resolution was hardcoded to 72
DPI on older
Mac systems and this is wrong. The DPI is hardcoded to 96 DPI on windows, and
this is wrong. It can be set on startup in X windows, but usually is
left at 100 DPI.
An 8 point font should be 0.111 inches (1/9) high on every system as measured
on the screen. The monitor on an iMac measure 8 inches high and at
768 vertical
resolution gives a DPI of 85, which means an 8 point font would be about 9.5
pixels. An iBook is 7.5 vertical display at 600 rendering 80 DPI. So
8 points would
be 8.8 pixels. .My development monitor has a vertical of 12 w/ 1200 pixels, so
100 DPI and an 8 point font size of 11 pixels. On this monitor, even a seven
point font is legible (9.7 pixels).
Points are an absolute measure of size and shouldn't be dependent on monitor
resolution. A 72 point font should be one inch on every monitor.
I hope more OS's in he future will handle point size properly. Then when we
render a page at 100 percent it will exactly match printed output.
I've had the
frustrating task in the last year of trying to get fonts displayed
properly on Linux
and Windows, in an application written for another platform which wrongly
assumed that 72 points == 72 pixels. We finally scrapped the built in font
handling and used FreeType.

[Michael B. Johnson]

Post by Rosyna
Where can you set this resolution? And where can you get it
programmatically? (How's that for tying it to Mac OS X dev?)
It would NOT be wise to show 72point font as 1 inch at every
resolution, this would be very wrong. Not only would it defeat the
purpose of higher resolutions, and case unbelievable problems with
webpages, it would make the text MUCH bigger than the graphics. All
designers care about is font size relative to the rest of the
document, that should be consistent but would not be if the font size
changes and the graphic size doesn't?

umm, at 100%, you would hope that one inch on the doc on-screen corresponded to one inch on paper
when printed. That means that a 72 pt high thing would be one inch high, regardless of the dpi of
the screen. Right now, as far as I understand things, this is not true.

There are two ways to think of higher resolution:

(a) I'm seeing more pixels at a higher resolution, and therefore my units have gotten tighter
(b) I'm zooming out, so things are getting smaller.

I'd argue (a), but you're arguing (b) (and that seems to be the way most things are implemented).


The fact that web pages aren't zoomable has always seemed screwed to me...

[Thomas Hudson]

All designers care about is font size relative to the rest of the
document, that should be consistent but would not be if the font size
changes and the graphic size doesn't?

In the case of desktop publishing apps, you have the concept of document
scale.
If I'm creating a document on standard American letter sized paper, at
scale 1
the document should measure 8.5x11 on the screen. If I zoom in or out on
the
document the fonts scale appropriately:

pixel_height = desired_point_size / 72.0 * DPI * document_scale;

unbelievable problems with webpages

Isn't this where we already are? I'm not quite sure who to pity more,
web designers
trying to create something that looks decent on every
platform/browser/resolution,
or the viewers of their work. :-)

Tomy

----
Hacker looking for work
http://www.tomy.net/thudson/resume.html
http://www.tomy.net/thudson/tools.html
---

[jgo]

Post by Graeme Hiebert

The screwy thing is they ought to be handled by Cocoa, by default...
* selected text isn't immediately draggable (and I don't think you can
change this...yet)

I much prefer the Cocoa way myself (though it needs more obvious
feedback, like a cursor change). I would rather see Carbon apps
change on this one.

Feed-back plus a way to change, i.e. if it gave me the begin dragging
cursor (or whatever) and I didn't want to drag, let me get back out
of drag mode without losing my selection.

Post by Graeme Hiebert

* Selecting text in Cocoa apps is like windows in that selecting a line
of text includes the carriage return (this one drives me up the WALL!)

This should be a user option in Cocoa...

Yes.

Post by Graeme Hiebert

* Cocoa apps don't seem to care if a file is already open. Most Carbon
apps don't allow this, and those which do usually warn when they are
open and won't save changes until they are no longer open.

This is a shame, but what are you going to do with all those Carbon apps
out there?

This is a case where they're both broken, if it really works as he
described. Yes, in many contexts you should be warned if someone
else is using a file that you try to begin using. If they've got
it open for writing, you shouldn't be able to get it at all because
whatever you see will likely not reflect the correct current content
of the file. If they've got it open for reading, you should only
be able to get it for reading. It shouldn't just store up several
processes' changes and apply them in turn...

Post by Graeme Hiebert

* I could probably write a six page email on command keys. Hopefully
QuicKeys will rock and I won't have to. Suffice it to say, F-keys are
usually reserved for global stuff (this isn't windows),
command-option-key is a good combo for global stuff too, like SERVICES
(I find services useless since the hotkey keeps changing)! Don't use
command-m for a service, geez.

Yes, some direction on when to use command-option and when to use
command-functionkeys would be a Good Thing. I like the idea of
reserving Command-Option for services and things. The Services menu
should probably be made completely user-definable in terms of command
key usage.

We've got customers who like multiple character command-keys,
where they type command+f followed by red to trigger their
fred macro or some such. Personally, my fingers get all twisted
up trying to hold modifiers and typing at the same time.

I've also used systems where function keys could be defined to
do whatever the user wished: enter a macro, serve as a command-
key equivalent, open a particular file, switch among apps,
selectively extract source from a library then compile and link it,
extract all the shell scripts & app scripts & auxiliary files
needed to run all available tests of curve intersection and of
bezier surfaces and run them. (I remember toward the end of one
30 hour work-day, trying to help someone edit the equivalent of
their .login file and pressing f6 because most folks had that set
as the equivalent of vi's :wq only this guy had it set to the
equivalent of :q! )

The ones on my key-boards go unused just now because we're only
given the option to launch an app (please, tell me I'm wrong).
I would sorely like to define F12 to be the same as delete so
that when I'm fumbling 'round in the dark these neighboring
keys will do the same thing.

John G. Otto Nisus Software, Engineering
www.infoclick.com www.mathhelp.com www.nisus.com software4usa.com
EasyAlarms PowerSleuth NisusEMail NisusWriter MailKeeper QUED/M
Will program Macs for food.

[Jason H Clouse]

<<If they've got it open for writing, you shouldn't be able to get it at
all because whatever you see will likely not reflect the correct current
content of the file.>>

What about pipes though?

J
________________________________________________________________
GET INTERNET ACCESS FROM JUNO!
Juno offers FREE or PREMIUM Internet access for less!
Join Juno today! For your FREE software, visit:
http://dl.www.juno.com/get/tagj.

[jgo]

Post by David Dunham

Post by Jonathan Hendry
Would it be possible for someone with copious spare time to
whip up a description of behaviors that are expected by
Mac users, and supported by the OS, but not automatically
handled by Cocoa?

I appreciate your asking -- many NeXT types seem not to care.

Answering this question would be great, and I appreciate...

Post by David Dunham
Oh, stuff like using file types (not extensions),

Yes. Meta-data is a feature.

Post by David Dunham
putting fonts in the menu so they're directly available instead
of in a floating window that gets in the way.

This is a matter of taste that depend a lot on how many fonts one
uses. If you've got just a few, a small foot-print palette or menu
can be great. If you've use many, being able to keep nested lists,
search tools, etc. can greatly increase productivity. In cases
like this, people should have options from which to choose, not
be strait-jacketed into the "one true approach" from some big-headed
coterie.

Post by David Dunham
Aliases (since a file is a file, no matter where it's moved to).

Aliases we've already discussed to death.

Apparently not. Aliases should be available and implemented,
but made use of at the user's option.

Using extensions and putting fonts in a font panel ARE the way
to write

BAD

Mac OS X applications.
I don't think Apple representatives have been unclear in these
areas at all.

Yes, clearly mistaken.

Heck, Steve Jobs has demoed the "floating window that gets in the way"
multiple times as the new and improved way to handle fonts in a
Mac OS X application. He seemed pretty excited about it, in fact.

Yep, clearly mistaken. I was just grumping at management and developers
who have such a floating window that gets in the way in one of our apps.
It's one of the big reasons I rarely use it, though it has some other
advantages over the analogous app that I do use.

If you don't like the direction Apple is choosing to go, that's fine,
but IMHO, those value judgements don't belong on a useful list of
"behaviors users expect of the OS but are not automatically handled
by Cocoa". Because I think such a list should be made up of items
that Mac OS X users expect, NOT what classic Mac OS users expect.
These are not necessarily the same thing.

There are expectations, there are habits, and then there is good design.
I'm not religiously devoted to either 9- or X. I have used, and promoted
and developed for Macs because, in general, they work better for the
price, than the alternatives.

Which is why I think we need to look at what Apple is saying publicly,

We don't care what "Apple is saying". We care what the individuals
at Apple are delivering.

what appears in documents like the Mac OS X Human Interface Guidelines.

Yah, definitely defective. Blurry letters ("character glyphs") are
NOT the wave of the future.

+ there are lots of things in MacOS which never made any
+ sense,

Putting Quit in the File menu, or Preferences in File or Edit.

+ like the Desktop. I disabled my desktop in OS X using
+ TinkerTool. Nothing but an easily hidden background which mac
+ users spend countless wasted minutes reorganizing windows to
+ keep unobscured.

What are you talking about? What aspect of the MacOS screen
appearance, which they quaintly call the "Desktop" is it that
you don't like? Or is it the idea of a "Desktop" directory/folder
that you don't like?

+ I was also against bringing the Apple Menu back. I'd get
+ rid of it if I could.

Why? it serves a purpose that was otherwise neglected.

+ However I think everybody can recognize that mac developers
+ have placed a great deal of effort into making their interfaces
+ the most easily understood and consistent, their users demand it.
+ Apple has also placed a high priority on human interface design.
+ Things like FSRefs, aliases, file types and creators, and various
+ finder flags were always designed with the user in mind. This is
+ a far cry from other systems which were designed to work well
+ enough for a human to adapt to.
+
+ It's very easy to say it ought to be a user preference whenever
+ there is anything slightly controversial

Whenever there is more than one good way to have an interface
work the user should be able to choose what s/he prefers.

+ like the desktop, apple menu, control strip, or FSRefs.

What's controversial about having something displayed on the monitor?
What's controversial about having a system-wide menu of things
commonly usable regardless of what applications are running?
What is controversial about control strips or tool palettes?
What is controversial about being able to refer to a specific
file without having to drag around a huge character string?
Is it more common to make one mistake out of several hundred
characters typed or one out of a couple dozen?

+ However in my eyes, some ways of doing things are just retarded
+ and I'm not going to pretend otherwise just to comb egos...

Agreed. 9- was far from perfect and X only has a little
farther to go than 9- did. :B-)

John G. Otto Nisus Software, Engineering
www.infoclick.com www.mathhelp.com www.nisus.com software4usa.com
EasyAlarms PowerSleuth NisusEMail NisusWriter MailKeeper QUED/M
Will program Macs for food.

[jgo]

Post by Rosyna

Font handling is done incorrectly on every system. A point is
1/72 of an inch and should be on every monitor.

And printer.

Post by Rosyna

Monitor resolution was hardcoded to 72 DPI on older Mac systems
and this is wrong.
The DPI is hardcoded to 96 DPI on windows, and this is wrong.
It can be set on startup in X windows, but usually is left at
100 DPI...
Points are an absolute measure of size and shouldn't be dependent
on monitor resolution. A 72 point font should be one inch on
every monitor.
I hope more OS's in the future will handle point size properly.
Then when we render a page at 100 percent it will exactly
match printed output...

Where can you set this resolution? And where can you get it
programmatically? (How's that for tying it to Mac OS X dev?)
It would NOT be wise to show 72point font as 1 inch at every
resolution, this would be very wrong.

Thomas & Michael are correct. Displaying a 72 point font as
anything other than 1 inch in size would be wrong at a 100% zoom.
Of course, you could zoom in or out to simply look at it, while
leaving the "model" correctly reflecting the equality of
72 points and 1 inch.

Post by Rosyna
Not only would it defeat the purpose of higher resolutions,

The purpose of higher resolution is to display that 72 point or
6 point type more clearly, not to make it larger or smaller.
This is why we need those 60 inch diagonal monitors for our
PowerBooks, with the 3000d/i resolution to get nice smooth,
clear crisp lettering and graphics while displaying a dozen
pages of a few hundred lines each of the apps we're developing.

Post by Rosyna
and cause unbelievable problems with webpages

It would correct the current unbelievable problems with web pages,
and, as noted, you could still zoom in or out.

In a previous career I was a printer and did some lay-out work
when cut & paste meant you got out knives and scissors & a bottle
of glue, and this craziness of having a resolution change alter
the sizes of type and icons (and move them around!) has always
been irritating. It's understandable how it evolved but it's
time to correct it, now that we can.

John G. Otto Nisus Software, Engineering
www.infoclick.com www.mathhelp.com www.nisus.com software4usa.com
EasyAlarms PowerSleuth NisusEMail NisusWriter MailKeeper QUED/M
Will program Macs for food.

[jgo]

Post by Jason H Clouse

Post by Jason H Clouse
If they've got it open for writing, you shouldn't be able to get it at
all because whatever you see will likely not reflect the correct current
content of the file.

What about pipes though?

You're quite correct. A pipe can be open by "another" process for
writing and by "this" process for reading. It can have only one
kind of change, an append, as the sender streams to it and the
reader accepts, so it avoids the problem of random access changes
and the 2 processes stumbling over the same few octets, that I had
in mind.

John G. Otto Nisus Software, Engineering
www.infoclick.com www.mathhelp.com www.nisus.com software4usa.com
EasyAlarms PowerSleuth NisusEMail NisusWriter MailKeeper QUED/M
Will program Macs for food.