[Lazarus] Lazarus config woes
DrDiettrich1 at aol.com
Sat Apr 2 15:49:53 CEST 2011
> On 02/04/2011 00:45, Hans-Peter Diettrich wrote:
>> 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?
> Because as I wrote a line further down:
> "Rules for "invalid/incompatible" may be complex. They may not always
> apply, even if the user hopes for. "
> Also I wrote "from the end users view. "
> Someone knowning all the "rules" can predict, if the current config is
> "invalid/incompatible" or not.
My above rule is so simple, that just the *end user* must not know more.
In either case, when the *end user* has to adopt a config, he *must*
know what he must change, or else the result *is* unpredictable.
Whatever is updated automatically, by the IDE or installer, eliminates
the need to know about just these issues.
IOW your argumentation is based on the unpredictable behaviour, that
results from arbitrary changes to the config, while my argumentation is
based on the unpredictable settings that have to be changed, in order to
provide an *intended* behaviour.
All such argumentation IMO ends up in the same conclusion: the user must
be told what he has to know about Lazarus, because he cannot know in
advance, whatever items affect the behaviour of a Lazarus installation,
in what way.
>>> 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.
> Sorry, but I am not sure what you mean. Isn't that the idea of a script,
> just run it?
See my above argumentation. The user must not learn anything about
details, that are handled automatically by some tool (installer, IDE...).
I'm not used to write scripts myself, nor to understand the scripts of
other people. This is not a Windows issue, as some people believe. There
exist users that have no use for a GUI, and others that have no use for
consoles. While commandline freaks prefer to use Emacs for all their
development, GUI freaks will use Lazarus instead <BG>
>>> 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.
> That wasn't the question. How should it?
When a (Linux) console user knows how to write scripts and create links,
a (Windows, KDE, Gnome...) GUI user knows how to create and configure
desktop shortcuts. A GUI user rarely will create links himself, except
for desktop shortcuts, so your question obviously addresses an very
different context. Unless you provide more information, why such a link
is created at all, I cannot understand nor answer your question
<sheepish grin>. Until then I only can suggest to store the Lazarus dir
in the IDE (executable), so that it always knows from which directory it
was built; this preserves the chance to override whatsoever in a script,
>> 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.
> Ok, "creator"? The end user, or the lazarus developper?
Whoever gave the OS the instruction to create the thingy. Nothing
materializes out of thin air.
> if the end user, then that is the same as --pcp, or scripts, the user
> has to set it up onc
> if the laz-developer, then tyes, it is easy to implement some rule, but
> the bigger the set of overall rules grows, the more confusing for the
Confusion can be reduced a lot, when obviously incompatible platforms
are described and managed separately, so that a Windows installation has
not to suffer from problems specific only to UNIX installations.
When a Lazarus installation will work out-of-the-box on Windows, or can
be made to behave so very easily, why not take that chance?
More information about the Lazarus