[Lazarus] Lazarus shortcuts conflict with windows shortcuts

[Reinier Olislagers]

On 15-8-2012 14:57, Martin wrote:
> On 15/08/2012 13:37, 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.
> 
>> 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
> As I said added schemes go into userschemes
> http://wiki.lazarus.freepascal.org/UserSuppliedSchemeSettings
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.

>> 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 ;)
> 
> 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)
Fair enough.