The only thing that alters the actual files list, is this piece of code:
while (i < array.GetCount())
{
// discard directories, as well as some well known SCMs control folders ;)
// also discard C::B project files
if (wxDirExists(array[i]) ||
array[i].Contains(_T("\\.svn\\")) ||
array[i].Contains(_T("/.svn/")) ||
array[i].Contains(_T("\\CVS\\")) ||
array[i].Contains(_T("/CVS/")) ||
array[i].Lower().Matches(_T("*.cbp")))
{
array.RemoveAt(i);
}
else
++i;
As you can see, some items are discarded from the list. C::B project files, directories and files that reside under paths like /CVS/ or /.svn/.
Is your directory structure something like this?
Why can't you just for once accept it if you are told that something is intentional and that something is like this because of some reason?
I can accept it (and I'm doing it) because I think this is only a thing like what's two lines below
// ask the user which files to add
// TODO (mandrav#1#): Make these masks configurable
Yes, but we know that you want everything configurable and changeable, even if it makes no sense at all.
Yes, in reality the point we don't agree is not the "configurable and changeable", but the part about "if it makes sense".
What makes sense for ones doesn't for others (ask Alex, which lost perhaps some time finding the issue, and if Yiannis wouldn't told that, he may would never know). I don't think everything in the IDE has to fit everybody, that's why it's modular, but for the SDK part, yes, IMHO it should have the less things possible hard-coded (and for file extensions/paths, there exist some enums for them).
You are right, that in this case (we're talking about a very little feature "called usability by the comments"), it does not make a lot of sense to touch anything further, because it involves time (which is scarse), but not because it is inherently bad to touch it.
(I see this as an another TODO like the one two lines below).
Remember "_svn" in autorevision? Well, it's missing here too. (It's about moduladirity)
The only difference is that here this a little feature, not something crucial (like autorevision), so not much people would mind.
But, and as a whole, I don't really care for this (if I talk for myself, because if I would be Alex the situation would change), I'm only trying to remember that there exist code in the SDK which needs
1) Resolve some TODOs like "Make these masks configurable"
but (most importantly):
2) Add some TODOs to the code, which are hard to see (this case), and may need some discussion before implementing it.
This is of what I'm convinced, but I don't want to make loose more time for any of you on this (since I'm more worried about the big picture rather than a little issue which is a feature and not a bug anyways).
Since obviously anybody can't provide patches if there's no agreement for this (neither change the functionality trough a plugin), we should move on and end this topic.
Note that I'm not angry at all and I understand all choices being made, but I just see that there's too much things left to modularize in the SDK (and the compiler plugin and codecompletion...) so I'm looking after a positive response (either "fixed in svn", or "marked as a todo" or "yes, that's right, you can provide a patch for this").
Particularly I'm more concerned regarding modularity and generalization for languages other than C/C++ in the SDK (not plugins yet).