Hi!
25-Янв-2005 17:11 [EMAIL PROTECTED] (Rich) wrote to [email protected]:
R> how possible would it be to create such a functionality that oo.org
R> would read a single file for configuration items and all settings that
R> would be specified in this file would take precedence over all other
R> places of settings ? in this case user could create such a file and just
R> copy this single file over to another oo.org installation. it would be a
R> single file, minimal screwup possibility, easy to edit etc.
But what happen, if user try to change option in Options menu, and this
option be overrided by _additional_ file? Should OOo configurer change also
this additional file?
PS: I myself love centralized configuration files in text format, but
sometime there are troubles. For example, Borland C command line compiler
(BCC) read options from turboc.cfg file, but this file in current directory
(.\turboc.cfg) overrides (hides) turboc.cfg in BCC' startup directory
(%startup%\turboc.cfg). So far, so good - but %startup%\turboc.cfg contains
-I and -L options with pathes to include files and library directories and,
if you make your own turboc.cfg, you should copy into it -I and -O options
from startup one (and you should adapt .\turboc.cfg on each machine, where
it will be copied/distributed). On the other side, imagine, what happens if
.\turboc.cfg will be "added" over %startup%\turboc.cfg - in this case, to
make default configuration (ie. prohibit changes in all options, beside
explicitly chnaged in your .\turboc.cfg), you should write all possible
options in your turboc.cfg! And don't forget, than newer BCC presents some
options, which are unrecognizable by previous one... :( Hard problem.
In case of BC, there exists (theoretical) solution: in startup
directory should be present another configuration file with _compiler
specific_ options (like -I/-L, or options, which regulate memory usage by
compiler). Thus, turboc.cfg may contain only compilation specific options
(optimizing, code generation, additional include and library pathes, etc)
and it will be added to "compiler configuration file".
This was only one example of possible problems. As for OOo and your
proposal, another problem with "overriding" may be changes, which made from
inside OOo. On the other side, we may want to copy settings of Writer, but
not other components. I think, configuration problem must be deeply studied
before selecting some design.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
