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

[Graeme Geldenhuys]

Op 2010-10-21 13:38, Michael Van Canneyt het geskryf:
>>  * 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)

And this is where you and Vincent are wrong. The File Filters dialog allows
you to customize the filter name and the filter file mask. I have changed
both in my case, so there is *no* reference any more for the IDE to know
what _was_ a default/standard filter and what was added by the end-user. So
no matter how you look at it, the translations cannot be applied any more.
Oh, and I changed the order of my filters too, so you can't even use
positioning as a reference either.


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

See above.


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

Such micro-optimization will make no difference in the startup time of the
IDE. I know of many other areas that could be improved to give a much
bigger speed gain.

And, as I mentioned, I used a separate file for a reason - otherwise I
can't share file filters between IDE profiles. Putting those settings all
in one xml file reduces the flexibility, not increasing it. I write
software to solve problems, not make problems. ;-)


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

Since the start there was NO circular reference issues, so I really have no
idea why Vincent even brought it up. That aside, to reduce circular
reference issues, it is preferable to use the implementation section uses
clause, which is what I did at the start (and even quoted Delphi help
saying the same thing), yet Vincent thinks adding it to the interfaces
section uses clause is the way to go. He is wrong.


> 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

And I'm already finding in very useful for months. I just don't understand
the issues than "seem" to exist. I justified every part of my
implementation with a actual use case - something that solved a problem for
me (and probably other too) and keeps flexibility in mind. After all, we
are developers, so our installations and usage are allowed to be
non-standard (ie: I never install to /usr/local/ and use multiple lazarus
IDE profiles), so the IDE should be flexible too.

Like I mentioned in the Mantis report, at this point I simply don't care if
the lazarus team applies the patch or not (I'm using it locally already). I
think it works, and I think it is a very handy feature. It's just a shame
non of the other lazarus users will know or see it any time soon.  [Makes
you wonder how many other gems are lying stagnant in Mantis]



Regards,
  - Graeme -

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://opensoft.homeip.net:8080/fpgui/