On 21/10/2010 11:31, Graeme Geldenhuys wrote:
Hi,
Regarding mantis report (with patch):
http://bugs.freepascal.org/view.php?id=15679
Reasons for the patch and my implementation:
The standard file filters are only imported once (on first
time use), thereafter the user can modify and customize them as they
see fit. The minor side effect is that those default file filter
are not translatable any more, but who really keeps changing there
IDE language back and forth - so I see this as a non-issue.
Quote from Vincent on mantis:
"2. Only store the user added file filters in a config, to prevent
problems with translations and later additions of standard filters. "
I am very much with Vincent on the storage.
And I do think the correct storage format is a major major point => once
it's decided, it is in users xml files, it must be supported forever.....
Here is my proposol for storage:
- Each build in scheme must have a "xml-name" (a none translated token)
=> this could be the extension itself
- using the extension itself, would also work for user schemes
The following would then be possible (but thought would still have to be
given about several extensions in the same group)
<FooList count="xxx">
<BarItem ID="pp" Caption="xxx">
...
if an item is *not* present in the list, then it uses it default.
- "pas" is not present in the list, so it goes with the ide default (and
follows translations
- if the ide adds "p" as to the list of default, all users will get it,
unless someone already has it in their list.
if you want to disable a default
<BarItem ID="pas" Enabled="False">
* I wanted to reorder the file filters, so a new default option is
select when the File Open dialog is shown. For this reason too, the
default file filters was included in the user customizable list.
add o "position" element to the xml
<BarItem ID="pas" Position="4">
will keep the Caption to the default, and it is also still enabled
* I use multiple Lazarus IDE profiles, so instead of having to re-setup
my file filters in each profile, I decided to store the file filters
in a separate xml file, so I can symlink them between profiles. Now
if I update one profile, all profiles are updated. This I believe make
the argument for including it inside the existing environment options
xml file a moot point too. What is the real issue of having another
xml file?
sorry, but that is a very personalized reasoning.
By default it should save in the environment options.
But I would think that there s a way to accommodate both:
- Have an export button, that write a standalone xml file
- allow that file to be copied into the "userschemes" folder (for that
it must follow the xml format of userschemes
if any preset-scheme is found in userschems => display a dropdown on the
option page => if the user chooses the pre-set schem, store the name/id
of the choosen scheme in the enviroment.xml
Then you can have all your useroptions point to one file....
Martin
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
