|
From: Bernard B. <be...@lp...> - 2007-01-02 14:10:06
|
First let me broadcast once again the good news of year 2007: Bol Processor porting to MacOS X ("Carbon") is now in full swing thanks to Anthony Kozar's dedication to this work. The estimated time for completing a running version with the same features as BP2.9.5 is three months. Modifications of the code will regularly be displayed in the CVS.
One of the major changes from the user's point of view will be file types, names, prefixes and suffixes, which requires a discussion.
The old situation under MacOS 9
Three parameters were associated with every file created by Bol Processor. The first two ones were stored in the file's resource fork:
1) Its signature (creator) which was 'bel0' for every file.
2) Its type which was different for grammars, data, scripts etc. as it would determine the icon displayed near the file name. File types 'BP02', 'BP03' etc. are listed in the document "BP2-info.txt".
The third parameter was again the type as indicated by the prefix of the file name: "-gr" for grammar, "-da" for data, "+sc" for a script etc. Using prefixes to indicate file types was inherited from the early (BP1) version running on the Apple II, when there was no Finder with a graphic interface.
When the user double-clicked a file, the Finder would launch the proper application using the "signature" information found in its resource fork.
Assigning icons to files was done via the Desktop in MacOS 9. Rebuilding the Desktop on a MacOS 9 volume meant looking at file types and match them with the list of types recognised by each application - also stored in a resource fork.
File types were supposed to be unique for the sake of displaying the proper icons. (I had deposited the signature and file types for BP2.) If a file type had been wrongly duplicated in two applications installed on the same machine, the icons might be messed up but double-clicking files would not create any conflict because the system was looking at the file signature (here 'bel0') to identify the application.
Some files (grammars, data, scripts, glossary...) could be stored in either pure text or HTML. HTML is the option we should retain unconditionally for those files because it is not dependent on the system's text encoding. Otherwise we will face compatibility problems with high-ASCII signs: special signs in European languages, and the bullet sign and typographic suspension points used in polymetric expressions ("period notation" and "undetermined rests").
BP2 used to recognize a HTML file from its content, either because it started with the <html> tag or it contained some other typical tokens (see "BP2-info.txt"). This looks a still valid choice.
However, HTML files created by BP2 had the 'MOSS' signature and would not launch BP2 when double-clicked. This was a wrong choice.
The new situation under MacOS X (with "Classic" running)
When dealing with files created under MacOS 9, MacOS X is still looking at the type in the resource fork because (1) it launches BP2 on a double click and (2) it correctly displays the BP2 icons.
However, things are likely to change because MacOS X no longer uses a Desktop to assign icons and applications to files.
By default, MacOS X looks at the file name's suffix to assign an application to a file. This method is consistent with Unix and Windows and we therefore should suggest users to opt for suffixes so that their projects will become system-independent once BP3 has been ported to other environments.
Nonetheless, files earlier created by MacOS 9 programs are still opened by the same application (MacOS X, Carbon or Classic) if no suffix has been appended.
In MacOS X, appending ".doc" after a file name immediately changes its icon and sets it to be opened by MS-Word or OpenOffice, whichever is installed. However, if I append ".doc" after "-gr.dhati" which was created by BP2, the file "-gr.dhati.doc" is still displayed with its old icon, and double-clicking 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.
Further, looking at a file information it is possible to set it to launch any application that works in the current environment. (If Classic is running, it also gives access to MacOS 9 applications.) In this way, if both Ms-Word and OpenOffice are installed, it is possible to set some ".doc" files to launch OpenOffice and others to launch MS-Word. This further confirms that MacOS X takes care of file signatures as a priority over suffixes.
What to do next?
The problem is what to suggest users when users create new files under BP3. With MS-Word X, appending the ".doc" suffix is suggested but not compulsory. With TextEdit, appending ".txt" is done automatically, even if the user tries to erase the suffix in the save-file dialog. Still, if the suffix is later removed from the Finder, MacOS X will launch TextEdit on a double-click of the renamed file, unless the new name bears a prefix pointing to another application. 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 similar to BP2 deciding that the file is HTML when it detects a significant tag.)
BP3 will certainly save something similar to the "signature" information whenever a new file is created. We may therefore allow users to go on using 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.
If it is possible to retain the idea of file types associated with custom icons, it will be fair, though I doubt that it will work cross-platform. It seems that all text files are associated with a unique 'text' type, which means that the distinction between grammar, data, script etc. might be lost at the level of the operating system. Icons are not a big deal, anyway, but BP3 will still need information to process the file content, for instance displaying a grammar in the grammar window and a script in the script window.
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 implementing text-editing features. If so, no header should be used in text files. (Binary format is only used for MIDI files in BP2.)
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 click of the file then we should proceed this way.
In this case, prefixes will no longer be necessary for the program to sort 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:
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 modified in the save-file dialog.
2) If "Use prefixes" is off, suffixes are compulsory (juste like TextEdit) and prefixes are not suggested.
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 manner (because the file name was fiddled with from the Finder) it should take the prefix as the correct reference and automatically change the suffix to make it consistent.
This will not be difficult to program since there is a unique procedure in the source code for creating a new file and another one to open a file and decide on its type.
Bernard Bel
|
