[Lazarus] Global dialog "file filters" feature + patch in mantis

[Martin]

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...