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

[Michael Van Canneyt]

On Thu, 21 Oct 2010, Graeme Geldenhuys wrote:

> Hi,
>
> Regarding mantis report (with patch):
>   http://bugs.freepascal.org/view.php?id=15679
>
>
> We seem to have reached a stalemate in mantis discussions, so I thought I
> would bring the issue to light in the mailing list (Mantis is not meant for
> long discussions). Now others can review and comment on this too.
>
> PS:
> Why can't the reporter of a mantis report, delete old (unused) attachments.
>
> Below is a list of reasons why I implemented this feature as I did. They
> seem reasonable to me, and keeps the user's personal preference in mind.
>
> Reasons for the patch and my implementation:
>
>  * I wanted custom file filter is all "File Open" dialogs in Lazarus IDE.
>    There is now a new "Environment Options > General > File Filters"
>    setup screen for that.

This is OK.

>
>  * The default/standard file filter did not include all file types I
>    wanted - hence the reason they are included as customizable by the
>    end-user. 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.

You should not take yourself as a reference for all users.
Each has his ways. I couldn't dream up the ways that some 
users use my programs... Same here.

That said, I see no reason why you would not be able to fix this 
problem. Just keep track of what are 'standard' filters and always 
present the correct translation (i.e. the current text).
For user-added filters, obviously there is no translation.

If each filter in the IDE is uniquely named, you can keep track 
of names that are 'standard' filters, and present them using the 
original texts.

The same is true in all other parts of the IDE: file | new items are also
always uniquely named, and translatable. It's just a matter of correctly
implementing it. (I appreciate that of course the work must be done)

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

Seems like a useful option. A no-brainer, if each filter is named.

>  * Due to the previous 2 points, the argument about translation issues
>    is moot.

This is not correct reasoning. Maybe so in your use case, but not as a
general rule. In each case, see above, it is perfectly possible to keep the
translation feature intact.

> So to is the argument for "possible future addition" of new
>    default/standard file filters. The user can simply add them at will,
>    *if* they actually wanted them. I don't want all the default file
>    filters in my setup, so I deleted those in my setup.
>
>  * 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? Who cares how many xml config files there are, as long as
>    the Environment Options dialog in the IDE is clear and easy to use,
>    nobody should need to worry about the files in ~/.lazarus/ directory.

This is a difficult balance. In theory you could put every option in a
separate file. This will slow down IDE startup, as each XML file takes 
time to set-up, load and parse. So less files is simply better.

>  * The issue about circular unit reference in the implementation section
>    is stupid too, but I opted for that chance to make Vincent happy.
>    Though if it really is such an issue, a FPC bug report should be filed.

Compiler bugs aside, circular unit references IMHO indicate sloppy design, 
and must always be avoided.

My conclusion: The idea is good (I'd very much like this feature, I can 
definitely use it), and with some extra work can definitely make it in 
the IDE. That sometimes a compromise must be made (put all options in 1 file) 
is a fact of life, but no reason not to implement it.

Michael.