|
From: Anthony K. <ant...@sb...> - 2007-01-04 21:44:59
|
Bernard Bel wrote on 1/2/07 8:34 AM:
> Some files (grammars, data, scripts, glossary...) could be stored in eith=
er
> pure text or HTML. HTML is the option we should retain unconditionally f=
or
> those files because it is not dependent on the system's text encoding.
This is an interesting point that I had not considered.
> Otherwise we will face compatibility problems with high-ASCII signs: spec=
ial
> signs in European languages, and the bullet sign and typographic suspensi=
on
> points used in polymetric expressions ("period notation" and "undetermine=
d
> rests").
Support for different high-ASCII encodings, 8-bit Unicode, the HTML
"encoding" should all be considered. Also, it might be convenient to have =
a
low-ASCII-only syntax for polymetric expressions. (I know that period
notation allows '.' instead of '=80', right? What about undetermined rests?)
> BP2 used to recognize a HTML file from its content, either because it sta=
rted
> with the <html> tag or it contained some other typical tokens (see
> "BP2-info.txt"). This looks a still valid choice.
Sure, looking at the content of a file is, in my opinion, the best way to
determine its type on any platform.
> However, HTML files created by BP2 had the 'MOSS' signature and would not
> launch BP2 when double-clicked. This was a wrong choice.
Yes, this should probably be changed.
> However, if I append ".doc" after "-gr.dhati" which was created by BP2, t=
he
> file "-gr.dhati.doc" is still displayed with its old icon, and double-cli=
cking
> it still launches BP2 via Classic. Therefore, if the file has a signature=
and
> type, these remain dominant over the information provided by its name.
I have not tried this, I hope that it is always true ...
> What to do next?
>=20
> The problem is what to suggest users when users create new files under BP=
3.
> With MS-Word X, appending the ".doc" suffix is suggested but not compulso=
ry.
> With TextEdit, appending ".txt" is done automatically, even if the user t=
ries
> to erase the suffix in the save-file dialog.
The mandatory suffixes is the recommended approach by Apple. I personally
believe that this is a very wrong choice. Users should be able to name a
file whatever they want. If the suffixes were ALWAYS hidden and never
required the user to know about them, then they would function like OS 9
file types, but they do not. The fact that the OS X Finder puts up a
warning dialog when changing a file suffix is extremely irritating and
confusing to the user in my opinion.
> Still, if the suffix is later
> removed from the Finder, MacOS X will launch TextEdit on a double-click o=
f the
> renamed file, unless the new name bears a prefix pointing to another
> application.
I believe that this is due to TextEdit being a "default" application for an=
y
unknown files.
> The reason for TextEdit to be insisting on suffixes is that it
> needs them to determine whether the file is in pure text or RTF, whereas
> MS-Word checks the content of the file for making a decision. (This is si=
milar
> to BP2 deciding that the file is HTML when it detects a significant tag.)
TextEdit could and should just look inside the file to detect whether it is
RTF. A usable system would not burden the user with having to manage this
information.
> BP3 will certainly save something similar to the "signature" information
> whenever a new file is created. We may therefore allow users to go on usi=
ng
> file names without a suffix, though we should suggest a suffix by default=
to
> anticipate cross-platform use of BP3. Whatever the user's decision,
> double-clicking the file will launch BP3.
This is fine. On OS X, we can continue to set the old creator and filetype
information. A default of suggesting file suffixes for each file type is
also a good idea for cross-platform use as you point out.
> An option for easy file identification would be to store a file-type
> identifier in the beginning of a file. I always discarded it, and more
> generally I had discarded the idea of inserting a file header, because I
> estimated that it should be possible to create/edit BP2 files with any
> external text editor. This option of using an external editor must be
> retained in BP3 because the in-built editors (Toolbox TextEdit or WASTE) =
are
> too rudimentary and I do not think that developers will have fun implemen=
ting
> text-editing features. If so, no header should be used in text files.
All true, but adding a simple "comment" at the beginning of the file to
identify it as a grammar, homomorphism, etc. file may be the only way to
guarantee being able to identify the files cross-platform. I see that
recent versions of BP2 already do this for most of its file types:
// Grammar file saved as '-gr.dhati'. Date: Sam 21 Juin 1997 -- 21:39
// Alphabet file saved as '-ho.tryCsound'. Date: Sat, Jan 11, 1997 -- 17d24
We could definitely look for these comments to confirm a file's type but no=
t
make them mandatory.
> Anthony suggested that we include the file type information in the suffix=
.
> Thus, a BP3 grammar file name would end with ".bpgr", BP3 data would be
> ".bpda" and so on. If this makes it possible to open BP3 on a double cli=
ck of
> the file then we should proceed this way.
> In this case, prefixes will no longer be necessary for the program to sor=
t out
> file types. However, I anticipate users who want prefixes (for the sake =
of
> sorting on names in the old fashion) and others who prefer using suffixes=
.
> Therefore I suggest that it is made a global option of BP3:
>=20
> 1) If "Use prefixes" is on, when creating a file the dialog suggests the
> prefix and proposes the suffix as a checkbox option. If the user refuses =
the
> suffix it will not be appended, but the prefix cannot be deleted nor modi=
fied
> in the save-file dialog.
>=20
> 2) If "Use prefixes" is off, suffixes are compulsory (juste like TextEdit=
) and
> prefixes are not suggested.
I think a global preference for prefixes, suffixes, (and prehaps neither) i=
s
a very good idea. I am against the idea of the save dialog forcing any
particular behavior though.
> Whatever the option, BP3 will be able to recognize a file type looking at=
both
> suffix and prefix in the name. If both are present in an inconsistent ma=
nner
> (because the file name was fiddled with from the Finder) it should take t=
he
> prefix as the correct reference and automatically change the suffix to ma=
ke it
> consistent.
I think BP3 could be made very "smart" about all of this and look at the
traditional Mac filetype codes, the prefix, the suffix, and the contents of
the files (in that order, I think) to determine file type. Mac filetype
codes can be relied on without question when present unless the type is
'TEXT'. The contents of a file can be used to confirm whether a prefix or
suffix is correct. If any of those three do not match, perhaps the user ca=
n
be asked for the correct type.
I also wonder whether we might be better off using "structured" text data
for some of the files such as settings and Csound instruments which are not
currently very editable by the user anyways. XML is becoming quite popular
for this purpose and has the same benefits as HTML as well as library
support built-in to OS X and probably other operating systems as well.
Sorry for the length of this post :)
Anthony Kozar
anthonykozar AT sbcglobal DOT net
http://anthonykozar.net/
|
