|
From: Anthony K. <ant...@sb...> - 2006-11-27 01:15:36
|
Bernard Bel wrote on 11/21/06 4:55 AM:
>> but it does try to create files in its own folder.
>
> It is the case with the default settings file. This one should indeed be
> moved to the proper location.
> Another file that was created in the same folder is an invisible file
> used for registering, but I believe you have already removed that part.
Yes, I have already disabled the registration code. I hope to release a
new 2.9.5 final version before beginning the Carbon port so that we have a
final "reference version" on OS 9 and so that anyone still using the program
can get these updates.
> The general philosophy was that whenever you open a grammar file the
> machine remembers the location of the folder in which that grammar file
> was located, and it will try to load all related files (settings,
> alphabet, orchestra etc.) from that same folder. It will also propose the
> same folder, by default, for saving files of the same "project".
Hmmm ... this made me realize that it will be a bit more work to allow
different combinations of prefixes/suffixes for filenames. The file parsers
will have to be updated to understand the new formats. And if we allow the
user the freedom to use their own conventions, it will be desirable to have
some sort of syntax for marking the filenames as "grammar", "alphabet", etc.
Allowing full or relative pathnames as references to other files would also
make sense on most platforms.
> At one point I was tempted to define a specific "project file" that would
> contain the links/paths to grammar, data etc. but I found it easier to
> maintain the explicit links in grammar and data files.
I've thought about this ... it could always be done later. One thing to
consider is that once BP is split into libraries, people will be able to
write new GUIs for the engine to work in whatever way seems logical to them.
> It gets a bit more complicating when running scripts: every "open file"
> script instruction contains the ID of the folder in which the file was
> located, but this ID will change if files are moved to another disk. When
> it does not reach the file at the specific location, it tries other
> strategies such as the "current folder", or the last folder in which
> another file of the same type was opened, etc. I am not sure these
> strategies will still work in MacOS X, but redefining them should be done
> only in the next phase (after the release of the beta version) because
> scripting is not a vital feature of BP.
I think the current stategy will still work, but a better way (on OS X or OS
9) might be to use the Alias Manager since under many circumstances it can
track files that have been moved or renamed.
> Since we have larger monitors now they could be flashed on any
> relocatable window. At least we do it with the first version of the
> port. They could even disappear because the program is too fast now to
> enable reading those messages, and we still can use the option "Display
> last messages" to trace the recent actions.
OK.
> The option was already there: if you push the 'option' ("alt") key when
> typing "command-O" you get access to all text files whatever their
> prefix/file type.
Oops! I forgot about that :) No problem then.
>> As for OS X, I think we should adopt some file extension suffixes as
>> "standard" for each of BP's file types, and continue to set file and creator
>> types when saving files from BP (this is acceptable in OS X if frowned upon
>> by Apple). When opening a file, a popup menu could be provided for choosing
>> the type. [...]
> This is a nice way to do it. Keeping file creator/type is also a good
> strategy even though we know that it won't make any sense when porting to
> Linux and other systems.
>> The user can then decide how they wish to name files (using prefixes,
>> suffixes, or any scheme of their own) and it will still be possible to open
>> them with BP.
> This option is fine because at this point we cannot decide what is more
> practical for users. It partly depends on the availability of navigation
> services.
> I agree that the priority is to run the program in MacOSX, even if it is
> at the cost of limiting window sizes to 32,000 characters in the first
> version. We never see grammars of that size. [...]
>> and I think we could release a version of Carbon BP without printing if it
>> will take significantly longer to add.
> I agree totally.
> At a later stage some users might even wish to use an external editor for
> all Bol Processor files.
Good. I am glad that we agree on all of these core issues.
Anthony
|
