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.
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
