On 21/10/2010 15:14, Graeme Geldenhuys wrote:
Op 2010-10-21 14:28, Martin het geskryf:
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.....
Like I said, take a simple feature and over engineer it until it's really,
really complicated. No thanks!
* How many times have you change your IDE language settings?
Actually: regularly.
Sometimes I forget, but normally, if I change the layout of a dialog, I
check at least a 2nd language.
But that's not the (biggest) point. Even in the approcah I proposed: any
modified item will no longer follow language (never can, as there is no
translation to a users custom naming)
The issue is, that as far as I understand, as soon as any change was
made by the user => all entries will be frozen, even those not modified.
and it will prevent new (none conflicting) defaults from being made
available.
The last bit is a problem we already have with "templates" (always saves
the whole template file, not just modifications). So yes we did the
fault. And we know we need to fix it...
But that doesn't mean it should be done again
* I've modified both file extensions and file filter names, so no you can't
count on the extensions as a key in the XML file.
you could, an extension that is removed is flaged as
"pp" => disabled
then the new named one is simply added.
if you want to disable a default
<BarItem ID="pas" Enabled="False">
* What if I added my own desciption for files *.pas
you store that extension => with the new description => or better with
the ref to the group it should be in in future (and the description on
the group)
Of course ther is a different betwen renaming an existing group (newly
added default extensions will still be added)
OR moving all extensions from that group into a new one => newly added
defaults will not follow to the new group
* What if I disabled a default option, and then later that default option
gets removed from the IDE, now the XML file contains rubbish that needs
to be clean-up up. So now we need periodic "check for xml cleanups" too.
The xml config has a version, which should increase. So the rubish is
harmless and can stay. => it will only be remove,d the next time the
user saves the file
happens in other locations too. It's by far a lesser drawback...
Over engineering! My initial implementation was simple and to the point. If
you felt so bad about missing out on new default file filters or
translations, simply delete your customized xml file, and you get the
defaults with translations back. No periodic xml cleanup code. No
enable/disable rubbish in the xml file. No conflicts with names on file
masks when either defaults changes or end-user added. Can't get easier than
that!
point of view.
I accept this is yours.
You should accept the expressed views of others on this too.
unfortunately the decisions is not made according to your view. (and
there has already been too many discussions about how decissions should
be made => so please don't again)
If you want to go down that road, then start looking at the other simalar
issues in Lazarus IDE too. Lets take Code Templates as an example:
* The lazarus.dci file is a separate file, and not in one of the existing
XML files.
Yes as i said => the error has been made once.
And it already cause some issues (as new features where added, defaults
changed to support them, and users complained they couldn't find them in
their installation....)
* In never gets "auto updated" when the defaults changes.
* Descriptions don't get updated when I change my IDE language
* I can't disable default options, I have to simply delete them.
* etc, etc....
All true.
someone committed suicide by jumping from the bridge => will you do to...
someone robbed a bank => will you ?
SCNR, Sorry about the last 2 lines...
Nobody complained about that for the last 10 years!
Not true, so I am not bothered to find the case...
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
