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

[Martin]

On 21/10/2010 15:00, Graeme Geldenhuys wrote:
> Op 2010-10-21 14:38, Michael Van Canneyt het geskryf:
>> Name = 'AllPascalFiles'
>> DisplayName = 'All pascal files'
>> Mask = '*.sql'
>>
>> User edits DisplayName and Mask. 'Name' can be used to track changes.
> OK, so lets say the above is implemented... now lets walk through a use
> case. Remember I said, I DO plan features, I don't just code them off the
> top of my head.
>
> 1) First time in IDE since 'File Filter" patch was applied. File Filters
>     grid is populated with default display name (from translation resource
>     strings) and default file masks.
>
> 2) I modify the display name and file masks of existing filters, and I
>     add my own filters.
>
>
> ...[ time goes by and one of the default filters had there file mask
>       changed ]...
>
>
> 3) First time I enter the IDE since new default filter file mask. What
>     should happen?
>     - Lazarus overwrites my customized file mask for that filter? I'd be
>       pissed off about this.
>     - Lazarus prompts me to to do something?
>        * I'd be pissed off about pointless prompt.
>        * Prompts for what?
>        * I don't like software that prompts me for every damn change, so
>          no I want to know where do I disable such prompts?
>     - Lazarus just ignores the new default filter file mask, and keeps
>       using what I specified (I opt for this, which is essentially what
>       I have already implemented)

Maybe I missed it, but I nowhere read anyone asking for that.

The point is, that if a user only:
- adds new filters
- modify some, but not all of the existing
- disable some but not all of the existing
- or a combination of the 3 above

then those items that where not user-modified, should follow future 
changes to IDE defaults

As well as newly added default should automatically be available.
- if of curse a user already defined "*.foo" then a newly added default 
for that, does not need to be shown

The last bit may be hard to archive by using the "build in" names. But 
it could work by using the extension itself as an ID

However several extensions are usually grouped. so you need to store 2 
things.

group-info:
- default groups stored given by ID
   - only stored if caption, position/order or enabled/visible changed
- user groups

then for each extension in which group it is:
- extensions used in a default group are only stored in xml if they are 
either:
   - diasbled / or moved to another group.

e.g. if "*.pas" is not in the xml, it will be part of it's default group

If a new default group is added, for *.foo => but *.foo is already in a 
user group, then the default group will be empty, and not displayed
   -