Martin schrieb:
If a global config is found, but is invalid/incompatible, a local
config should be created.
sounds good at first, but is actually worse.
Because this behaviour is unpredictable from the end users view.
Unpredictable why?
Currently the results are unpredictable, when the IDE finds a config
unusable, or does not find out, and produces consequential errors :-(
Rules for "invalid/incompatible" may be complex. They may not always
apply, even if the user hopes for.
In fact they may change, later. 2 installations that have shared the
global conf for a long time, may become "invalid/incompatible" at some
point (maybe only for a short time) => but then all the sudden one of
them has a conf in the exe-dir => not good at all.
It's up to the inventors/maintainers of the config thingy, to provide
checks and solutions. I only can assist in improving the current state.
E.g. split the config into an always compatible (user preferences), and
an installation specific part. This will allow to retain as much of the
settings as possible, in case of problems somewhere else. Next offer the
user a menu item, to save the config into the Lazarus directory (current
scp), and later load from that location whatever config files are found
there, before loading missing files from other locations.
The requirement for an explicit -pcp can be reduced to the single
invocation, that shall create a new config. This job also could become
a menu option, or an option button in the IDE settings dialog. Why
press the user to specify a new pcp at the commandline, when the
config always is created by the started IDE?
the requirement to create a script, is a single invocation too...
where is the difference?
a profile manager, selectable from menu, could create this script for
you (or the windows shortcut). Again where is the difference?
The difference is, what the user must know about the script. When the
IDE creates it, the user only has to know about the invocation of the
script (filename or desktop icon), not about the contents of that script.
-----
btw , whith config in the exe dir => it can get really fuzzy.
if you have a link (or shortcut) to your exe, and there is config in the
real exe-dir, and the link-dir... which one to take?
Then it's up to the creator of that link, to make it work as it should.
Windos "links" (desktop shortcuts) allow to specify the working
directory, so it's up to the creator of the link to fill in that
information. Console users on any system may create an equivalent
script, and create links to that script instead of to the executable.
That's why I suggested to have the LazDir path stored in every compiled
IDE, so that the EXE can be moved around freely.
I'm confused about the use of the secondary config path. In which case
is this path used at all?
I think it's for backward compatibility? 0.9.24 had the config in the
exe dir... so it must still be found...
This special case requires an accordingly old FPC, due to the breaking
changes in the FPC versions. This makes old configs and Lazarus sources
unusable with a newer IDE, so that this feature can either be dropped or
must be made work in the new model.
DoDi
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
