I saw that quite a lot of keyboard shortcuts in Lazarus use Ctrl+Alt combos. On Windows this is not a good idea because (system wide) user shortcuts for programs on the desktop use Ctrl+Alt combos too so they conflict with each other. Is it realy necessary to use Ctrl+Alt combos?
I think there should be enough Ctrl+Shift and Alt+Shift combos available for all functions. But maybe it's already too late to change this.

There's nothing stopping you from changing the keyboard layout.

Also Windows is not the only platform where there exists conflicts. E.g. in some desktop environments the Ctrl+Fx keys are set to switching the desktop while in Lazarus Ctrl+F2 is used for stopping an application run and Ctrl+F9 for doing a compilation...

So in my personal opinion: leave the defaults as they are. We won't ever please everyone fully... [also not everyone uses shortcut combos on Windows]

Regards,
Sven

It's dangerous, because AltGr is also encoded as CTRL-ALT, when it comes to shortcut testing.

DoDi

I doubt we can maintain different shortcut tables for different keyboard layouts. The current table for MS Windows defines 232 shortcuts. Design time packages define their
own shortcuts.
Maybe someone knows an elegant solution to reduce the number of conflicts.

Mattias

Mattias Gaertner wrote

I doubt we can maintain different shortcut tables for different keyboard layouts. The current table for MS Windows defines 232 shortcuts. Design time packages define their own shortcuts. Maybe someone knows an elegant solution to reduce the number of conflicts.

Well, the only 'elegant' solution I can think of is to avoid Ctrl+Alt will always be unavoidable conficts with other software which uses system wide hotkeys but at least the OS shortcuts should be respected.

Of course, if this cannot be achieved (for all platforms or at least for Windows only) then I don't believe that there is a solution.

J?rgen Hestermann wrote

Well, the only 'elegant' solution I can think of is to avoid Ctrl+Alt combos at all. There will always be unavoidable conficts with other software which uses system wide hotkeys but at least the OS shortcuts should be respected.

In that case Ctrl should be avoided too, because Ctrl is often used in KDE & Gnome shortcuts.... See how rediculous this is becoming! As Mattias said, there is NO easy solution. Lazarus DOES allow you to redefine shortcuts, so does your OS. So YOU decided what is more important to you - the OS shortcut or the Lazarus one, then simply undefine the others.

Lazarus developers under KDE & Gnome have been doing this for years. The Ctrl+F<n> keys are often used to change virtual desktops, so we simply disable those in KDE & Gnome, because the Lazarus IDE ones are more important to us. Don't be lazy.

I agree with Graeme. Lazarus offers you the option, please use it.

It's simply not possible to find a set of shortcuts that is guaranteed to work on all systems. I think that internal consistency of lazarus is more important.

Michael.

SCNR...
Perhaps some tool called, say lazset*), could be created and used to set/change key shortcuts, e.g.:

lazset --primary-config-path=c:\example\whatever
--set="ContextSensitiveHelpKey=ShiftF1"

or e.g.
lazset --primary-config-path=c:\example\whatever
--set="ContextSensitiveHelpKey="
or
lazset --primary-config-path=c:\example\whatever
--delete="ContextSensitiveHelpKey"

... which would use the existing IDE code (same way lazbuild does) and that could be automated in e.g. a batch file or even an installer (e.g. only called when KDE is detected/selected).

A school, company, organization or user could maintain scripts that change these settings after each new install/upgrade, these scripts could be made available in the CCR or Lazarus repository, on the forum, etc...

Regards,
Reinier

*) Yes, the same as my suggestion in Martin's IDE language thread

LazSet should only be for very selected, special options (like path to fpc). Otherwise it will need too much maintenance, and soon be unusable....

Besides: Like for other settings (color) an import/export facility (Patches welcome) could be written.
The exported layout can (if implemented) be copied into userschemes, and can hen be selected (or if need is, lazset (if implemented) can preset it.

Changing the defaults for schools, pools, multi user environments is already possible. Just put your editoroptions.xml into the secondary config directory.

Mattias

Just an idea:

Delphi allows for selectable editor emulations, with different shortcuts. Lazarus could supply different shortcut maps for every desktop. The only "inconsistency" would arise in communication and documentation, where the default Lazarus shortcuts should be used.

DoDi

That is making a mountain out of a mole heap. The problem of this thread is not really a shortcuts are quick
and easy already.

Martin wrote

Besides: Like for other settings (color) an import/export facility (Patches welcome) could be written.

MSEide has such an import/export of settings function and it works very well. For large installation rollouts of Lazarus (though I don't think this exists), such a feature could help with the shortcuts issue. But again, this looks like a damn lot of effort, for something that can already be fixed very quickly - simply redefine the shortcut in Lazarus or KDE/Gnome/Windows.

Morning all,

@Martin: having an export (and import?) utility that needs to be maintained as well versus a settings tool that needs to be maintained wouldn't be too much difference, I'd think?
Perhaps the color export utility could be
modified/adapted/copied/expanded (whatever) though - wasn't aware of that one; will take a look, thanks.

@Mattias: yes, you're right, you can modify the xml file. Then you'd get into scripting that changes xml files. Not something I'd look forward to as an admin, but certainly doable. To each his own, I'd guess.

@Graeme: just like all help problems have a DocView solution for you, so do all configuration problems have a LazSet solution for me;) More seriously: I've been thinking about a tool like this for a while now and while this problem may not be that big/relevant, it does fit in with the rest of my ideas.

Regards,
Reinier

[...] @Mattias: yes, you're right, you can modify the xml file. Then you'd get into scripting that changes xml files. Not something I'd look forward to as an admin, but certainly doable. To each his own, I'd guess.

You don't need to edit the xml file directly.
You can simply use the IDE to setup the keys as you want and then copy the editoroptions.xml to the target's machine /etc/lazarus folder. When the pupil starts the IDE for the first time he gets your keys. And can alter them.
It's the same for any options of the IDE.

Mattias

Thanks, Mattias.

I was having trouble seeing how parts of environmentoptions.xml could be edited/set while leaving others alone (e.g. set compiler path, leave other settings alone)... but probably my aversion to XML files is playing up again and there might be many tools that already provide for merging XML files...

Regards,
Reinier

Graeme Geldenhuys wrote

In that case Ctrl should be avoided too, because Ctrl is often used in KDE & Gnome shortcuts.... See how rediculous this is becoming!

As I wrote: If it is not possible to define different (standard) shortcuts for each platform (thereby avoiding OS wide shortcuts) then there will be no solution.

As Mattias said, there is NO easy solution.

He wrote

Maybe someone knows an elegant solution to reduce the number of conflicts.

He did not write that such a solution does not exist. Just asking for one.

Lazarus DOES allow you to redefine shortcuts, so does your OS. So YOU decided what is more important to you - the OS shortcut or the Lazarus one, then simply undefine the others.

Of course. But *if* a solution to the problem exists this would be avoidable. So why not do it then?

Don't be lazy.

What does this have to do with laziness? Then you can say that no shortcuts should be can all be configured by the user. And if he complains, just say: Don't be lazy! Rediculous.

Graeme Geldenhuys wrote

Lazarus DOES allow you to redefine shortcuts, so does your OS. So YOU decided what is more important to you - the OS shortcut or the Lazarus one, then simply undefine the others.

Another aspect of this is that I have multiple machines where I use Lazarus/Free Pascal (at home and at work) and I often use the daily snapshots to reinstall Lazarus on them. Afterwards I often find that my settings are reset and I have to do the configuration over and over again. You may answer that there is some XML file somewhere that I only have to save before upgrading but neither do I know all these (many) files and their purpose nor do I *want* to know about them. All I want is a (Pascal) programming tool that lets me think about programming which does not eat up lots of time to bother with its settings instead.

Am 2012-08-14 20:45, schrieb Graeme Geldenhuys: > Lazarus DOES allow you to redefine shortcuts, so does your OS. So YOU decided what is more important to you - the OS shortcut or the Lazarus one, then simply undefine the others. Another aspect of this is that I have multiple machines where I use Lazarus/Free Pascal (at home and at work) and I often use the daily snapshots to reinstall Lazarus on them. Afterwards I often find that my settings are reset and I have to do the configuration over and over again.

The IDE does not reset configs on itself.
Maybe the installer does?

Mattias

Mattias Gaertner wrote

The IDE does not reset configs on itself. Maybe the installer does?

I think the settings are not reset after each update. But I had several situations where I got an startup error message after a certain upgrade which I could only get rid of by renaming the path "C:\Dokumente und Einstellungen\J?rgen\Lokale Einstellungen\Anwendungsdaten\lazarus" (which I was not even aware of that it exists and that it holds my settings). Afterwards all settings were gone. I had to do this on multiple machines.

When updating I am also asked whether "D:\Programme\lazarus\environmentoptions.xml" (why is this file located in the installation directory?) should be updated. I was under the impression that this file holds all my settings but only recently found out the editor settings are in "C:\Dokumente und Einstellungen\<user>\Lokale Einstellungen\Anwendungsdaten\lazarus\editoroptions.xml". What a nighmare of scattered settings. In "C:\Dokumente und Einstellungen\<user>\Lokale Einstellungen\Anwendungsdaten\lazarus" a file environmentoptions.xml exists too. Which one is used? There are 11 XML files in this directory. Are they all config files? Are other (non-XML files) configure something? This all is something the user should not bother about. I find it way too confusing. There should be only one config file with paths (which may be different on different machines) and one for *all* settings regarding Lazarus. But this seems to have evolved over time and cannot be changed back now.

So you removed your settings directory and were surprised your settings were gone???
Saving settings in c:\documents and settings\<username>\... somewhere is the standard location for Windows (XP?) settings files, so it wasn't surprising to me that they were stored there.

Apart from that, perhaps the release notes mentioned (see e.g. http://wiki.lazarus.freepascal.org/Category:Release_Notes) you had to change some settings?

When updating I am also asked whether "D:\Programme\lazarus\environmentoptions.xml" (why is this file located in the installation directory?) should be updated.

Because it is the fallback file that will contain settings if you haven't specified any.
(Secondary config path versus primary config path)

I was under the

Having multiple files does make it much easier to replace some of them (e.g. editoroptions). As discussed in this and other threads, that makes it useful for institutional use where some files can be replaced/updated by centrally standardized files.

If you think these files are confusing and don't want have anything to do with them, why is the number of files a problem? They're all stuck in the config directory anyway...

As far as I know, all your settings are in that settings directory, yes, but perhaps somebody will correct me.

Finally, you can edit your configs via Tools/Options... so why worry about the amount of files etc?

Hi,

J?rgen Hestermann wrote

Another aspect of this is that I have multiple machines where I use Lazarus/Free Pascal (at home and at work) and I often use the daily snapshots to reinstall Lazarus on them. Afterwards I often find that my settings are reset and I have to do the configuration over and over again.

I use multiple machines too, and I have multiple Lazarus versions on a single machine. When testing "unstable" or "new" releases, use the --pcp= parameter to specify the new config directory, thus it will not override your "stable and working" lazarus setup.

Plus, to test the "upgrade your configs to newer versions" feature of Lazarus, I copy my ~/.lazarus directory to something like ~/.lazarus-test, then use --pcp=/home/graeme/.lazarus-test in the test version, thus I can safely test the config upgrade feature too, and my original ~/.lazarus configs are still untouched.

"J?rgen Hestermann" hat am 15. August 2012 um 11:46 geschrieben:>

The next time you get this, can you create a bug report?

When updating I am also asked whether "D:\Programme\lazarus\environmentoptions.xml" (why is this file located in the installation directory?) should be updated.

The folder "D:\Programme\lazarus" is the secondary config directory - the place where the Windows installer places the config files that are copied on first start to the primary config directory (C:\Dokumente und Einstellungen\J?rgen\Lokale Einstellungen\Anwendungsdaten\lazarus). Maybe the Windows Installer maintainer can explain why he chose those directories.
Under Unix the secondary is /etc/lazarus, the primary is ~/.lazarus.

Yes.

Are other (non-XML files) configure something?

Yes. For example staticpackages.inc is a pascal include file.

This all is something the user should not bother about.

The normal user needs to know where the (primary) configs are for backup. Design time package developers need to know more details.

I find it way too confusing. There should be only one config file with paths (which may be different on different machines) and one for *all* settings regarding Lazarus.

The other settings can also be different on different machines. For example short cuts, window positions and history lists.
And vice versus: The paths can use macros and might be the same on different machines.

But this seems to have evolved over time and cannot be changed back now.

The secondary directory can be changed quite easily.

Mattias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120815/22e4a1bb/attachment.html>

Probably not. The code to write the XML already exists. It may need minor modifications, but it probably will still be only one implementation. Then there are 2 buttons.
The command-line isn't XML, it cant use that code.

Reinier Olislagers wrote

So you removed your settings directory and were surprised your settings were gone???

1.) I thought my settings were stored in "D:\Programme\lazarus\environmentoptions.xml". "C:\Dokumente und Einstellungen\<username>\Lokale Einstellungen\Anwendungsdaten" should not be used for such has "C:\Dokumente und Einstellungen\<username>\Anwendungsdaten" for this but I changed this to the installation directory long ago. 2.) I *had* to delete it because I did not know any other way to get rid of the error message (I think it was something about lazbase not found or so). It took me even a while to find out that Lazarus has stored things in this directory too.

Saving settings in c:\documents and settings\<username>\... somewhere is the standard location for Windows (XP?) settings files, so it wasn't surprising to me that they were stored there.

See above.
1.) "Somewhere" should have been "C:\Dokumente und Einstellungen\<username>\Anwendungsdaten" and not "C:\Dokumente und Einstellungen\<username>\Lokale Einstellungen\Anwendungsdaten" (that's for scratch data only and is not save within our roaming profile at work for example). 2.) I changed Lazarus to not use this path (but it seems either this was skipped with some update or was ignored at all).

Apart from that, perhaps the release notes mentioned (see e.g. http://wiki.lazarus.freepascal.org/Category:Release_Notes) you had to change some settings?

I install snapshots very frequently. I don't look into any release notes for each setup. It seems this was a fault and I need to stay with a working installation as long as possible. So using snapshots is not wise. I will not do this again (never change a running system, though sometimes it was not running in parts).

But that's totaly confusing for users if they are asked to overwrite this. If it's a fallback then it should be overwritten silently in the same way that all other files are overwritten too. I also mentioned that I configured Lazarus to save my settings in the installation direcory and not in "Dokumente und Einstellungen" so this message made me think that it will overwrite my settings. But as I now know, this was not the case. I consider this confusing.

Having multiple files does make it much easier to replace some of them (e.g. editoroptions). As discussed in this and other threads, that makes it useful for institutional use where some files can be replaced/updated by centrally standardized files.

But it makes it harder to understand for the user and leads to such confusions

If you think these files are confusing and don't want have anything to do with them, why is the number of files a problem? They're all stuck in the config directory anyway...

Yes, but I was told that I need to configure my shortcut settings and now need to copy all these settings around to all my machines where I use Lazarus. A real pain.

Finally, you can edit your configs via Tools/Options... so why worry about the amount of files etc?

Because I don't want to do that over and over again on multiple installations and I also want to have a backup of my settings which I can reinstall (either after data loss or on other machines).

I don't understand "The command-line isn't XML"? It can use the same units to write the XML config as other existing code (just like lazbuild).

Anyway, I'll shut up now - seems my suggestions were not well received... which is no problem either, I'm busy delving into the depths of documenting FPC's zipper classes right now anyway ;)

"Changed this"? How? Using --primary-config-path then?

2.) I *had* to delete it because I did not know any other way to get rid of the error message (I think it was something about lazbase not found or so). It took me even a while to find out that Lazarus has stored things in this directory too.

Or you could have asked on the ML or forum. IIRC, there were some transition issues with old projects having LCLbase or something dependencies.

Do you have some Microsoft documentation link for that? If that location makes sense, I'd submit a patch so you (and the rest of us) don't get bitten by this again...

2.) I changed Lazarus to not use this path (but it seems either this was skipped with some update or was ignored at all).

"Changed Lazarus".... how then? By patching the binary? I suppose you changed the primary config path then in your shortcuts as that seems the only sane thing to do...

I suppose that running the installer again will create shortcuts... don't know if it overwrites existing ones.
Do you think the installer shouldn't overwrite existing shortcuts? What if you change the install directory in your new installation?

Hmm yes. You did read the warning on the snapshots page, did you?

To counter this, what I do is have a "stable" version installed, which I only rarely update.
Next to that one, I have separate versions (e.g. trunk Lazarus with FPC 2.6.1, trunk Lazarus with FPC 2.7.1, trunk Lazarus with FPC 2.7.1 x64) using different primary-config-paths (that *don't* point to the installation directories - I'd like to be able to wipe the Lazarus dirs and start again)

Well, either your settings are in your Lazarus dir (in which case confirmation is very handy) or they are not. Apparently now you're saying they're not.
Regardless, a user can customize that fallback environmentoptions.xml and distribute it. That's why there's an overwrite question. Presumably, an installer could check to see what release the existing Lazarus install was, if the previous environmentoptions.xml was unchanged with regard to the file distributed with that install etc... but that seems like a lot of work to me.

There's always tradeoffs. Do you really think having one humongous XML file would clarify things? You'd still need to know about the XML schema etc. anyway if you want to make meaningful changes.

Well... perhaps there is a single XML file that has these shortcuts which you can just copy, instead of copying everything which messes up your paths etc. that differ per machine. Hey, and advantage of multiple config files ;)
I don't know though, haven't looked.

That makes sense.

Reinier Olislagers wrote

I don't understand "The command-line isn't XML"? It can use the same units to write the XML config as other existing code (just like lazbuild).

But it needs a separate reader, that writes data into the config object.

The XML reader already exists.

Anyway, I'll shut up now - seems my suggestions were not well received... which is no problem either, I'm busy delving into the depths of documenting FPC's zipper classes right now anyway ;)

I don't see how the export solution is less helpful?

you have an XML file (created once by the IDE):
- contains koymapping only, interferes with noting else
- any future IDE can read it. If formats are changed, old format are still supported.

*IF* the export exists, AND someone submits a patch, it would be possible to do "lazarus.exe --keymap=xmlfile.xml"

Snapshots aren't tested. It is part of them that you get the occasional hickup.

For the release, we test the actual upgrade installation and (hopefully) catch those things.

But that's totaly confusing for users if they are asked to overwrite this. If it's a fallback then it should be overwritten silently in the same way that all other files are overwritten too.

I agree with that. I have no idea why it was originally set to ask.

2012/8/15 Martin :

I guess I didn't want to overwrite an existing file without asking. http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=rev&root=lazarus&revision=28087 Maybe because it was at one time the primary config file, but probably not anymore at that time.

Feel free to remove the question.

Vincent

Ehm, ok, I'll take your word for it. I have the feeling we must be misunderstanding each other.

Ehm yes, this is shifting backward compatibility to another layer... I don't know if that is an actual advantage ;)

*IF* the export exists, AND someone submits a patch, it would be possible to do "lazarus.exe --keymap=xmlfile.xml"

You mean it will then import/merge xmlfile.xml into the regular config (overwriting existing settings or creating them depending on situation)?

Yes, that might be very helpful. As I said in an earlier post, I'll have a look at what's available.

This import mechanism by itself need not be restricted to colors etc (a GUI would be)... as long as
1. you devise a schema that takes into account the Laz xml filenames (environmentoptions.xml, editoroptions.xml)=>fortunately that already seems to be have been done in the Laz xml files themselves
2. mappings to deal with old versions if wanted
3. some strategy on how to deal with child objects (e.g. overwrite those with same name?)
you could perhaps just dump all the XML as is, e.g. this for a corporate install script:

<?xml version="1.0"?>
<CONFIG>
<EnvironmentOptions>
<Language ID="de"/>
</EnvironmentOptions>
<EditorOptions>
<General>
<Editor TabWidth="2" TabIndent="True"/>
</General>
</EditorOptions>
</CONFIG>

Added benefit: people can define their keymappings like that as well ;)

Having said that,
1. my XML-fu is almost nonexistent so please take all this with a pinch of salt.
2. aren't there any tools that already provide such a "merge XML" functionality?

Thanks,
Reinier

Right, I think 0.9.26 was the last version that saved config in the exe dir.

So anyone upgrading from that version will then loose their conf

Reinier Olislagers wrote

> *IF* the export exists, AND someone submits a patch, it would be > possible to do "lazarus.exe --keymap=xmlfile.xml" You mean it will then import/merge xmlfile.xml into the regular config (overwriting existing settings or creating them depending on situation)?

For colors the extra schemes are saved in the primary conf subfolder "userschemes"
That XML contains the definition of added schemes.

The user conf refers to it, and the user conf can then have individual changes based on it.

Similar for keymaps. There are already 3 schemes. So added schemes could be installed. (including via commandline)

"lazarus.exe --keymap=xmlfile.xml"

would have to copy the scheme, and set it as default, (and optional clear existing user overwrites, which would otherwise be applied to the scheme)

Yes, that might be very helpful. As I said in an earlier post, I'll have a look at what's available.

Their might be fixes needed. the keymaps afaik already have issues of their own. But that applies to any solution.

As I said added schemes go into userschemes
http://wiki.lazarus.freepascal.org/UserSuppliedSchemeSettings

2. mappings to deal with old versions if wanted

That is the intend.

But eventually automated testcases would be needed....

3. some strategy on how to deal with child objects (e.g. overwrite those with same name?)

Explain? What would have the same name?

You can already do some of it

Strip the editoroptions down to contain only the keymap settings. Put it into the secondary conf path

It will be used as template. The keymaps apply, the rest is using defaults. (Secondary conf only works for new installs, upgrades do not look at it, as they already have primary conf)

Yes, ok, you're talking about a specific use case now. Let's take that as an example.
A color scheme from that link e.g. has
<?xml version="1.0"?>
<CONFIG>
<Lazarus>
<ColorSchemes Version="6">
...
... so by seeing ColorSchemes in this hierarchy, the import tool can now where to place it (a mapping to the relevant xml file in the userschemes directory).

> 2. mappings to deal with old versions if wanted That is the intend. But eventually automated testcases would be needed....

Well ok. Thinking out loud: How about letting users import their settings in Laz, update the laz versions, export again. No old version support needed.
Otherwise we'd be duplicating old version support in Laz and this tool. ... Ok, if the source is shared that may actually not be that much of a problem.
Anyway, I understand what you mean.

> 3. some strategy on how to deal with child objects (e.g. overwrite those > with same name?) Explain? What would have the same name?

A Lazarus package for instance, present both in the source/user XML file and the config file.
Alternatively (Note: haven't looked at actual layout): if a user can have multiple color schemes and has a color scheme named "MyFunkyScheme" as the 3rd scheme... what happens if we import a "MyFunkyScheme"? I'd say you can't rely on the order being the same.
Remember, I'm talking about a general case her. This may be deferred for more simple settings.

Fair enough.

Reinier Olislagers wrote

On 15-8-2012 13:39, J?rgen Hestermann wrote: > 1.) I thought my settings were stored in > "D:\Programme\lazarus\environmentoptions.xml". "Changed this"? How? Using --primary-config-path then?

No. Many years ago (don't remember exactly) when installing Lazarus I was asked where the configs should reside, in the installation directory or in the user config directory. I chose installation directory.

It was discussed in this forum but there was no real fix given. Everybody said that it does not happen on a clean install but I was not aware that I did not have a clean install when renaming D:\Programme\Lazarus. Only after a while I found out that another Lazarus directory exists under "C:\Dokumente und Einstellungen\J?rgen\Lokale Einstellungen\Anwendungsdaten". I had a look in C:\Dokumente und Einstellungen\J?rgen\Anwendungsdaten" but there was no Lazarus directory so I was assured all is stored on D:.

I only found this in http://en.wikipedia.org/wiki/Microsoft_Windows_profile :

Local Settings is functionally similar to Application Data, and in fact it contains a second subfolder of that name. It also contains the temporary files generated by Windows programs themselves, and as a result of Internet Explorer's online activities. For standalone computers the two folders are functionally similar, but on networks employing Roaming profiles, the Local Settings folder is not included in the profile-synchronization process. Thus, data in the Local Settings folder will not be copied between computers when the user roams.

As said: If I remember right I was asked by an older installation routine where to store settings (which IMO was and would be a good idea). I am not asked again with newer installations though.

I suppose that running the installer again will create shortcuts... don't know if it overwrites existing ones. Do you think the installer shouldn't overwrite existing shortcuts? What if you change the install directory in your new installation?

Why are you talking about shortcuts? The shortcut simply starts lazarus.exe.

Hmm yes. You did read the warning on the snapshots page, did you?

Yes, of course. So it's forbidden to post anything for those people who use snapshots? It is not said so there.

To counter this, what I do is have a "stable" version installed, which I only rarely update.

I can't see any difference between "stable" and other versions. What makes a stable version stable? Interestingly, after major releases of software mostly a bug fix version is publish soon afterwards because suddenly many people start using the "stable" version and find bugs.

Well, either your settings are in your Lazarus dir (in which case confirmation is very handy) or they are not. Apparently now you're saying they're not.

That's true but I did not know about this because: 1.) I changed it (if I remember right) so I was under the impression they should be in the install dir 2.) Environmentoptions.xml exists in this dir (and has a recent date) 3.) Snapshot installer ask for overwriting this file from 2.) 4.) No Lazarus directory exists under "C:\Dokumente und Einstellungen\<username>\Lokale Einstellungen\Anwendungsdaten"

Regardless, a user can customize that fallback environmentoptions.xml and distribute it. That's why there's an overwrite question.

Yes, but if it is not used why ask and let the user believe that it is used? There are lots of other XML files in the installation path which seem to be overwritten silently when installing a snapshot. Why not this one too?

Presumably, an installer could check to see what release the existing Lazarus install was, if the previous environmentoptions.xml was unchanged with regard to the file distributed with that install etc... but that seems like a lot of work to me.

In general, under Windows path settings are stored in the registry so an installer could look for an existing installation and only ask when overwriting config files which are in use. Though this may not be possible for Linux if no central store for installed programs exists (which I don't know).

Do you really think having one humongous XML file would clarify things? You'd still need to know about the XML schema etc. anyway if you want to make meaningful changes.

I don't want to make changes within the file. I only want to copy settings (by copying the config file).

I am looking at Lazarus as a solid standalone product like Delphi (which of course is not the case but I hoped that everything was bundled so that it looked like that). Therefore I would expect a single configuration file for everything except paths which should be in a second config file (or even better in the registry). I know that this is quite Windows centric but that's how Windows users would expect it. Other Windows software does it this way.

J?rgen Hestermann wrote

4.) No Lazarus directory exists under "C:\Dokumente und Einstellungen\<username>\Lokale Einstellungen\Anwendungsdaten"

This should of course read:
4.) No Lazarus directory exists under "C:\Dokumente und Einstellungen\<username>\Anwendungsdaten"

If you feel strongly about it, you might want to submit an issue in the bugtracker...

Yes. And you can use it to set the configuration path using --primary-config-path=... or -pcp=...
In fact, it's the only way I know to change the configuration directory.

> Hmm yes. You did read the warning on the snapshots page, did you? Yes, of course. So it's forbidden to post anything for those people who use snapshots? It is not said so there.

Of course not. Just that if it breaks, don't act all surprised saying "I did not expect this", "I want every upgrade from snapshot to snapshot to work without breaking things" etc.

Ehm yes. I'll let you choose your own "stable" version.

The point was rather that you can have multiple versions side by side that don't influence each other, allowing you to experiment with bleeding edge stuff while you can always fall back on a known version.

Never seen any evidence of silent overwrites.
The fallback environmentoptions.xml is used in some situation. I can't help it you don't grasp the difference of primary versus secondary config path... TBH it took me a while to catch on as well. For discussion: perhaps this version could be renamed as environmentoptionstemplate.xml or something?

1. I hope you realize by now Lazarus doesn't store its settings in the registry. AFAIK, the only Lazarus-related things in the registry are the file associations.
2. Talking about the environmentoptions.xml in the Lazarus directory, how do you tell when "config files are in use" other than the method I already described?

Ok, I see what you mean. I'd think having a cross platform config capability using files is much more important, but perhaps the Windows installer devs agree with you...

2012/8/15 Reinier Olislagers :

I would not say scratch data, but data that should confine to one computer.

There are two reasons why local app data is used:
* That is what GetAppConfigDir in fpc returns
* It is used to store a lazarus executable with compiled packages, if the current executable directory is not writable. Having +/- 150 MB extra in my roaming profile doesn't help login time ...

Vincent

Reinier Olislagers wrote

> http://en.wikipedia.org/wiki/Microsoft_Windows_profile : If you feel strongly about it, you might want to submit an issue in the bugtracker...

It's not that I have a strong feeling about it but as you can see, this little inaccuracy can cause quite a lot of confusion (and data loss).

> Why are you talking about shortcuts? The shortcut simply starts lazarus.exe. Yes. And you can use it to set the configuration path using --primary-config-path=... or -pcp=... In fact, it's the only way I know to change the configuration directory.

That's the root cause of all this confusion: If I *know* all the nitty little details then I can act on them. But if I only want to use a software I don't see the need to invest so much time into it. If that's not possible the installer should show a warning with all the details the user has to know before he can use Lazarus.

The reason for breaking things was not that I used snapshots. The same would have happened for an official release. It is a kinda "design flaw".

The point was rather that you can have multiple versions side by side that don't influence each other, allowing you to experiment with bleeding edge stuff while you can always fall back on a known version.

Maybe. But I consider this a useless effort. If I see that a snapshot installation does not work anymore or breaks things (never happened yet) I would revert back and install an older version, if necessary after removing configs (if reinstallation alone does not fix it). It should be possible to get a clean installation somehow. The only problem was that I was not aware of all files and directories involved. Well, at least the *same* issue will not happen again. A hard way of learning though.

Never seen any evidence of silent overwrites.

Just have a look into the installation directory and search for XML files. They are all silently overwritten when installing Lazarus except environmentoptions.xml.

It seems that you miss the whole point. Tell me *any* reason to have multiple versions of the same (config) file? I can't think of any. If a file is not found and instead a new version needs to be used then it should be created in that situation (not before) and also the user should be informed about this. Then he can check what went wrong and he can to act on it accordingly. With your argumentation it would be a good idea to put a version of all config files in all directories found because in case another version is missing it can use some of the others. That's not very clever IMO and fools the user by letting him think that it is a file used by Lazarus (especially, because it exists in the installation directory).

1. I hope you realize by now Lazarus doesn't store its settings in the registry. AFAIK, the only Lazarus-related things in the registry are the file associations.

Yes. But a good idea would be to store paths to the configuration file(s) in the registry and allow the user to (re)configure them in the Lazarus IDE. This would allow a (Windows) installer to detect a previous installation and (re)use config files (which the user may have adapted heavily). That would be user friendly (especially on Windows, where such a behaviour is common and expected). For Linux the registry could be skipped and the user here needs to take care about config files himself (which seems to be common for Linux).

2. Talking about the environmentoptions.xml in the Lazarus directory, how do you tell when "config files are in use" other than the method I already described?

I only expect one config file (for each purpose) and not many where all except one are dummies. Such a kind of software installation is very new and unexpected to me. So when I install Lazarus and it asks for overwriting a file named environmentoptions then I expect that it will be used. Otherwise: 1.) Why should it be created?
2.) Why does it ask for overwriting?

Agree. I think both directories should be used:
[apps data] for things that should be roamed when a user is logging into another machine (I think config files fall into this category) and [local settings apps data] for files which are needed on this special computer only and which are not important for the user in case of data loss.

A normal user, who only uses releases, should not need to know.

The latest installer eve warns you, if you try to install (windows) multiple copies (which is one known cause for config issues)

Are you sure? Some of the issues that caused errors when upgrading to a snapshot, where fixed in the RC1 installer (again windows)

And I did tes myself, twice: starting once with a clean install of 0.9.30.4 and once with a 0.9.30 (not sure if I did a 0.9.28 too). Each time: Started the old install, compiled a new project, then quit and install the RC1.0. There were no errors.

So releases do differ from snapshots.

That said. everyone is entitled to use snapshots. Also entitled and invited to ask questions.
But not entitled to expect it to work flawless. And Required to pcik up some of that nitty gritty to kep going...

To bo clear. I am not saying the releases are flawless. No software is. But some effort goes into the releases, whereas none goes into the snapshots.

There are 2 reasons for this primary/secondary conf

1st reason)
the secondary (exe dir) is used as a template, if no primary exists yet. This is a once off. Since the primary will be created automatically.

So this is usually the case, after the very 1st install. Most options have defaults hardcoded in the lazarus.exe. But some (like path) are OS and installation depending. So the installer creates a custom environmentoptions.xml that reflects the directory into which the installation was made

Yes, the installer could write that to primary conf dir.
- As a weak argument: The existence of old config is easier to check in lazarus, than in the installer.
- Also: The installer does not know about a future --primary-config-path. Not automatically touching the default primary conf dir, means the installer can be used to *prepare* a secondary install
- historical (see next)

2nd reason)
0.9.26 and before actually stored all config in the exe dir

So if a user upgrades from 0.9.26 to 1.0 (or any other version, including future). Then his old config must be moved. This is currently happening.
This is the reason the installer needs to ask.

Though, either the installer should check, if it updates from such nan old version, or it should assume that it does not, and should skip the "overwrite" question

Only file-associations
And the installer info (so it is listed for uninstall)

No actual config

The (previous conf) should automatically be used.

- Either they are already in <user/appdata> Then they are used.
- Or they are in the exe dir (0.9.26), then they are copied to <user/appdata>

Only exception: previous install was 0.9.26 and you install to a new directory

Actually, it is a template.
But if you upgrade from 0.9.26, then it is a real config, and will be moved (actually copied)

To be clear.

No tests were done, if upgrading from a snapshot to 1.0 will work.

Reinier Olislagers hat am 15. August 2012 um 16:03

That would complicate things.
IMO it would better if the secondary folder has is renamed and/or a prominent README.txt file is put there.

[...]

Mattias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120815/8b39bcb7/attachment.html>

In general: if you think things should be done better, why not come up with specific improvement proposals instead of just complaining? Apart from that: I'm not going to answer this post. I think we're repeating ourselves.

Hope Lazarus works for you despite its problems.

Regards,
Reinier

Martin wrote

The latest installer eve warns you, if you try to install (windows) multiple copies (which is one known cause for config issues)

Ok. That's nice.

> The reason for breaking things was not that I used snapshots. The same would have happened for an official release. It is a kinda "design flaw". Are you sure? Some of the issues that caused errors when upgrading to a snapshot, where fixed in the RC1 installer (again windows)

Hmm. No, of course I am not sure because I don't know about these details. I was just assuming that *this* kind of data handling does not change within snapshots in a different way as in official releases. I understood the snapshot warning more in respect to my compiled programs (which may not run as expected). But of course, if such fundamental things change too then it may fail.

Nevertheless, the original thread was about hot key conflicts and this discussion about installs only began because I was adviced to change my settings and I only wanted to point out that this is not so easy when using multiple installations on multiple machines. To sync all of them without the hassle of manual config change I have to copy the config file. And for this purpose I need to know details. And having all settings in one (or two) config file and no config file with the same name in the install dir would help very much here.

> It seems that you miss the whole point. Tell me *any* reason to have multiple versions of the same (config) file? I can't think of any. There are 2 reasons for this primary/secondary conf 1st reason) the secondary (exe dir) is used as a template, if no primary exists yet.

Then it is very confusing to give it the same name as a currently used config file. As already mentioned it should be renamed to avoid any confusion.

2nd reason) 0.9.26 and before actually stored all config in the exe dir So if a user upgrades from 0.9.26 to 1.0 (or any other version, including future). Then his old config must be moved. This is currently happening. This is the reason the installer needs to ask.

Understand.

> I only expect one config file (for each purpose) and not many where all except one are dummies. Actually, it is a template. But if you upgrade from 0.9.26, then it is a real config, and will be moved (actually copied)

But that's the source of confusion: The installer cannot tell whether an environmentoptions.xml in the install dir (from previous installs) is a template or a working config file. If the template name would have been named differently (by versions later than 0.9.26) then this would have been clear. On the other hand this may be more programming work on the installer and the IDE (I don't know).

"Martin" wrote

> > 1. I hope you realize by now Lazarus doesn't store its settings in the > > registry. AFAIK, the only Lazarus-related things in the registry are

the

And I personally hope it stays that way, because currently one can easily install (!) multiple Lazarus distributions side by side (by just changing the primary config path before one starts Lazarus). It's already annoying enough that a new installation overwrites the old installation record... (but this is because of Windows' install system)

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120815/8798153e/attachment.html>

2. aren't there any tools that already provide such a "merge XML" functionality?

An XML document parses into an tree. This tree can be used as the start for parsing the next XML document, merging or overriding the old and new tree nodes.

DoDi

So what tools do you know that do that? Otherwise I don't really understand why you wrote this comment...

You don't get my point. You could as easily have said no on my question.

I'm aware that there are difficulties involved in merging XML files.

Searching for a tool may not be the way to go. How should a tool know how to deal with duplicate entries?

I'd suggest to look into the XML classes, provided by Lazarus, in detail the laz2_XMLRead/Write units. They provide procedures to read entire XML files and to insert XML text into that document. If these procedures fit your needs, the merged document can be saved using WriteXMLFile.

DoDi

Please see patch in
http://bugs.freepascal.org/view.php?id=22673

Thanks,
Reinier