On 01/04/2011 05:23, Hans-Peter Diettrich wrote:
Martin schrieb:
> Searching for config files in the exe dir (even if done) doesn't
solve
> the first issue, as there may not be any config files in that
directory
> to start with.
Then the IDE creates defaults.
No. This is:
- if a search in the exe-dir is added, (so the the behaviour will be:
search exe-dir, search global-conf dir)
- if a global config exists
The IDE will search the exe dir, will not find a config, will find
the global conf
If no global conf exists, it will search all places, and then create
the globa conf
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.
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.
> In this case the unaware user is still screwed.
Why do you think he is screwed?
Because if the user is unaware, and never creates a config by hand,
or forces it into the exe dir, then he./she always ends up with a
global conf.
So searching the exe dir first, doesn't help. (unless the user is
aware, but an aware user can use -pcp too)
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?
-----
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?
About primary and secondary config paths:
At least on my Windows the Lazarus directory is listed as the
secondary config path. [I cannot check this for Linux, having only an
old Lazarus version without display of the config]
This indicates to me that the IDE already is aware of the Lazarus
(source or EXE?) directory, so that it can/should look there for a
config anyway, before looking into the default directory.
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...
Maybe a check could be added to warn if the environmentoptions.xml
is from a future Lazarus with two options: Quit and continue.
Imho on any conflict:
- diff version
- diff last exe path (doesn't work on linux, since recompiled exe
goes into user dir)
- missing package source
the user should be:
- informed which config is used
- offered to create a new one, in a new place (run some kind of
profile manager)
=> and be told how to load this.
- offered to create or update an according desktop icon
+1
- offered to load a diff config
--
_______________________________________________
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
