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.

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

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

* Due to the previous 2 points, the argument about translation issues is moot. 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.

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

Vincent and Paul's ideas add restrictions / limitations to the usefulness of the "File Filters" feature, and that simply doesn't make sense to me. So what do others think?

Regards,
- Graeme -

Op 2010-10-21 11:46, Vincent Snijders het geskryf:

Yes, I think the consensus is that is a useful feature (it is not resolved with won't fix). And it is nice that you can live with the limitations of the implementation.

Please specify what about my implementation do you consider "limitations"?

I have given "real life/usage" reasons for every point, as to why I implemented that feature as I did.

Regards,
- Graeme -

This is OK.

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.

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.

Op 2010-10-21 13:38, Michael Van Canneyt het geskryf:

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.

See above.

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

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 -

Quote from Vincent on mantis:
"2. Only store the user added file filters in a config, to prevent problems with translations and later additions of standard filters. "

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

Here is my proposol for storage:
- Each build in scheme must have a "xml-name" (a none translated token) => this could be the extension itself
- using the extension itself, would also work for user schemes

The following would then be possible (but thought would still have to be given about several extensions in the same group)
<FooList count="xxx">
<BarItem ID="pp" Caption="xxx">
...

if an item is *not* present in the list, then it uses it default.
- "pas" is not present in the list, so it goes with the ide default (and follows translations
- if the ide adds "p" as to the list of default, all users will get it, unless someone already has it in their list.

if you want to disable a default
<BarItem ID="pas" Enabled="False">

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

add o "position" element to the xml
<BarItem ID="pas" Position="4">

will keep the Caption to the default, and it is also still enabled

sorry, but that is a very personalized reasoning.
By default it should save in the environment options.

But I would think that there s a way to accommodate both:
- Have an export button, that write a standalone xml file
- allow that file to be copied into the "userschemes" folder (for that it must follow the xml format of userschemes

if any preset-scheme is found in userschems => display a dropdown on the option page => if the user chooses the pre-set schem, store the name/id of the choosen scheme in the enviroment.xml

Then you can have all your useroptions point to one file....

Martin

You misunderstand. There is an INTERNAL name which you don't show to the user. You are talking about the 'user displayed name'. The internal name remains untouched.

Look at the way the 'File|new' items are done. It's the exact same principle.

Michael.

To make sure it's clear:

Name = 'AllPascalFiles'
DisplayName = 'All pascal files'
Mask = '*.sql'

User edits DisplayName and Mask. 'Name' can be used to track changes.

Michael.

Op 2010-10-21 14:38, Michael Van Canneyt het geskryf:

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)

4) I add more file filter masks. eg: XML files (*.xml)

...[ time goes by and one of the default filters had there display name changed ]...

5) First time I enter the IDE since new default filter display name change. What should happen? Essentially the same as (3).

...[ time goes by and a new default filters had been added. eg: FPDoc Description Files (*.xml) ]...

6) First time I enter the IDE since new default file filter was added. What should happen?
- Essentially the same as (3).
- Automatically add new default filter. But hey, now the mask clashes with my own 'XML Files' filter.
- What about my preferred order of filters. I don't what that to change either, so where should IDE add new file filter.

My observations:
* You guys now made the whole feature a damn site more complicated than it needs to be.
* I don't want the IDE prompting me, I hate such software. So now we need a global setting for prompts. More complicated again, plus what should the default setting be, yada, yada, yada...
* Say it was decided we can keep the file filters in a separate XML file. Yippee! I share that file between my various profiles, which also happens to be different versions of Lazarus. One version containing different defaut file filters to the other. Must one version of Lazarus now update my file filters XML file or not, should it prompt me or not? Beats me!?!

All this, a classic case of "over engineering". I just want customized file filters, with whatever names and masks I specified, and in whatever order I want. That's it, nothing more, nothing less.

Also please tell me how many of you keep changing your language of the IDE? Because I seriously doubt 99% of the developers here keep changing IDE languages after the first install (once they have setup their IDE preferences). In the 5 years I used Lazarus IDE at work, I changed the default language a whopping 0 (ZERO) times.

I think you guys are making a big deal out of nothing! This brings me back to the old point of why do you thing the lazarus project struggles to get contributors? It's always a damn uphill battle for the smallest of things.

This is a trivial and simple feature, but now you expect me to spend hours on it, and then it actually ends up being less flexible than at the start.

I'll continue using it locally where it works, please be so kind as to mark the Mantis report as "won't fix".

Regards,
- Graeme -

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 -

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

if you want to disable a default <BarItem ID="pas" Enabled="False">

* What if I added my own desciption for files *.pas
* 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.

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!

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

Nobody complained about that for the last 10 years!

The lazarus team are welcome to over engineer this simple feature to your hearts content, or simply mark it as Won't Fix. I'm done with this. I already waisted enough time on implementation and all these back-and-forth messages.

Regards,
- Graeme -

Op 2010-10-21 16:07, Martin het geskryf:

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

The IDE already doesn't work like that, so why must this feature. Code Templates being one example.

Oh, but now we have to not only parse the XML file, we now need to compare default and user-enabled file filters via name, id, extension etc... we also need to parse the extensions to see if we should add new defaults or not.

Did I mention this will slow down the startup time of Lazarus even more? Something that Michael pointed out should be avoided. So there goes the idea of speeding up the process by merge the settings into an existing xml file.

Regards,
- Graeme -

The last point is correct. You changed something, nothing is done. As soon as something is marked 'changed', it is ignored.

Nothing. Modified means: do not touch.

...[ time goes by and a new default filters had been added. eg: FPDoc Description Files (*.xml) ]...

New filters are simply added to the end of the list.

No. The name is different. You'll simply have the same thing twice.

A user action is always required when the IDE changes: in your way just as in my proposal...

- What about my preferred order of filters. I don't what that to change either, so where should IDE add new file filter.

Always at the end.

My observations: * You guys now made the whole feature a damn site more complicated than it needs to be.

But it gives maximal user experience, least amount of fuss. Isn't that what it's all about ?

Many things in the IDE are more complicated than I would like them to be, but usually Mattias puts me straight: he always gives the reason why things are the way they are. I may think they are needlessly complicated sometimes, but in the Lazarus IDE, his story is always consequent and logical. Making the IDE a damn sight better than Delphi's meanwhile.

Michael.

PS 1. I am merely an observer in this particular discussion. You asked opinions in order to resolve a dispute. I gave mine, how I would solve the dispute. You're of course free to do different.

PS 2. I often find that the following lyrics help me put things in perspective: http://www.metrolyrics.com/you-cant-always-get-what-you-want-lyrics-rolling-stones.html

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

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)

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

Op 2010-10-21 16:26, Michael Van Canneyt het geskryf:

PS 1. I am merely an observer in this particular discussion. You asked opinions in order to resolve a dispute. I gave mine,

Fair enough.

The changes list from this discussion are added no my "on a rainy day when I have nothing better to do" list. That hardly ever happens. So somebody else that would like all the discussed changes are welcome to jump in and take my patch to the next level - currently it works for me as-is.

Regards,
- Graeme -