[Lazarus] Lazarus 0.9.29, Project/New Project/Custom Program?

[Mattias Gaertner]

On Thu, 12 May 2011 22:56:00 +0200
Graeme Geldenhuys <graemeg.lists at gmail.com> wrote:

> 2011/5/12 Mattias Gaertner:
> > But as far as I remember it lacks the ability to update defaults.
> 
> Simply delete your custom file extensions file, and a new one is
> created with the latest defaults. Obviously it might be wise to backup
> your old one first, so you can merge customizations back in.

Well, for one config item this might be doable. But in general this is
a bad solution.

 
> > For
> > example the file group "project" was extended from *.lpr to *.lpr;*.dpr. The
> > patch stores the default values to the config file, but a good config file
> > should only contain the non default values.
> 
> That would be that for a "project" I would always have the IDE
> defaults, which I might not want. In my case, that was exactly so. I
> don't create LCL based projects, but do use the Lazarus IDE. So my
> desired defaults are very different. Just what I wanted.

Easy solution: If a user clears the extensions of an item it is not
shown. Then the item has a non default value, which is saved and kept
even when you upgrade.

 
> > Just an idea: Maybe instead of storing a simple list it can store the
> > extensions for each standard item plus the list of custom items.
> 
> This makes a relatively simply feature so much more complicated, with
> very little benefit for all the efforts required to implement it. As I
> described above, simply delete or backup your customization file and
> the IDE will create a new one for you with the latest defaults.

Complicated?
You just need to add a simple array.
If I would have the time to maintain your extension I would do that.


> Not to mention... how often does the IDE defaults really chance... in
> the last 6 years, very little. So is what you describe really needed.

There were some feature requests about adding a mechanism to
register new file types.


> The bottom line is, I wanted *new* defaults, hence the feature in the
> first place - I don't care much for what the IDE considered defaults
> once upon a time. My filters look very different now, but it suits my
> needs.
> 
> What everybody else proposed in the bug report comments, simply
> limited the features of what I implemented.

Your patch is a good start.

Mattias