Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Make file extensions to be freely defined
MortenMacFly:
Setting up (new) compilers is greatly modularised ind Code::Blocks. So should be for the file-extension.
This would enable two improvements:
1.) Imagine someone would like to use ".c++" and ".h++" extension for his files. Currently he's a bit lost since some operations apply to the default extensions only (e.g. saving settings "Link file" and "Compile file" in file properties).
2.) Attaching other (non-C++ domain) compilers would be fully enabled, e.g. the GNU Fortran (g77) or Java compilers.
To sum up: Why not making extensions be generally freely defined? Maybe one could use the lexers (there are the extensions provided anyway) for this...?!
I would like to hear the thoughts of the main developers...?!
Morten.
mandrav:
You 're right. You see, C::B evolved much faster than I would expect it to and now we 're trying to catch up :)
I don't think it should be done using the lexers. We shouldn't mix the editor and compiler configuration like this.
What we could do is have a different configuration file, parsed at the beginning, specifying the file types.
E.g.:
--- Code: ---<FileTypes>
<File type="ftSource"
name="C source"
ext="*.c"
compile="1"
link="1"
compiler="CC">
<File type="ftHeader"
name="C header"
ext="*.h"
compile="0"
link="0"
compiler="CC">
<File type="ftSource"
name="C++ source"
ext="*.cc,*.cpp.*.c++,*.cxx"
compile="1"
link="1"
compiler="CPP">
<File type="ftHeader"
name="C++ header"
ext="*.hh,*.hpp.*.h++,*.hxx"
compile="0"
link="0"
compiler="CPP">
</FileTypes>
--- End code ---
This way, C::B could be extended to understand more about a file by editing this config file.
What do you think?
Yiannis.
Urxae:
I think it would be a lot nicer if this information was kept in C::B's settings, and you could edit it somewhere in the settings menu. That would be a logical place for it, wouldn't it? It would also be much more user-friendly than an extra configuration file.
mandrav:
--- Quote from: Urxae on August 20, 2005, 11:19:58 am ---I think it would be a lot nicer if this information was kept in C::B's settings, and you could edit it somewhere in the settings menu. That would be a logical place for it, wouldn't it? It would also be much more user-friendly than an extra configuration file.
--- End quote ---
Good point. But how many users will ever use (or even understand) the dialog you 're proposing?
The way I see it, config dialogs are for settings that people change (usually often). This kind of configuration is one-shot. And if someone has different needs can still edit one file. And if it extends C::B (like the fortran support that Morten is trying to add) the changes will be included in the C::B dist.
The point here is to avoid hardcoding values in C::B. You can think of it as a first step.
Don't forget: that's how lexers are done. XML config files which are written to registry on modification (and the registry has precedence over the XML - whether that's good is another thing altogether ;) ).
Thanks for the comments :)
Yiannis.
MortenMacFly:
I think both suggestions (mandrav's and Urxae's) don't exclude each other. Both sound good to me. I think there is an ongoing discussion in another thread about where and how to store the configuration. If a decision was made to store everything in XML files (which IMHO is a good option) both is possible. GUI's for such settings could be nicely done as plug-ins for those who would like to have buttons for configuration (why not?!). Using the registry is just so "Windows-like". Meanwhile I have a 50MB registry but as mandrav said: That's another story.
--- Quote from: mandrav on August 20, 2005, 11:03:08 am ---You see, C::B evolved much faster than I would expect it to and now we 're trying to catch up :)
--- End quote ---
Looks like the typical developer's dilemma... :? - especially if a software envolves as Code::Blocks does. Seems as if you guys hit the nail on the head with Code::Blocks. I myself searched a lot for a good cross-platform IDE. Visual SlickEdit (www.slickedit.com) came close but it's not free. Code::Blocks is even better in certain areas and I think a lot of people were just waiting for it.
Morten.
Navigation
[0] Message Index
[#] Next page
Go to full version