using a set is not particularly efficient. maybe you could turn FileType into a bit field instead? dunno what consequences it would have for the other code.

i'm not sure i like the whole feature. it looks completely asymmetric. i for one don’t like the subfolders at all. others may want to factor out only the “other” files. now what?

My opinion about bit field is another. With set this solution is more flexible. For example – to use bit field we have to declare one more struct, that will dublicate ProjectExplorer::FileType enum.
But I agree that QSet is not particularly efficient in this case.

That’s why I can suggest alternative desicion: use QFlag instead of QSet. What you think about it ?

What about this feature at all I can explain whay I decided to realise it. Almost modern IDE’s are using trees in project trees. And there are three different ways to display it:
1. By content type, like now in Qt Creator (XCode, Visual Studio).
2. By folders, like my suggestion (CDT-Eclipse, Delphi).
3. Simple list, like now in QtCreator (vim)

No one of them is better or not. The question is what kind of them is more convenient to end-user. And It’s nice to have realisation to every favour. It makes adaptation of new user more comfortable.

Also I can add such submenus:
-Hide “Other” files
-Hide “resources” files
-Hide “Forms” files
… and other File Type.

I think it’s rather flexible way to display project tree. For example I can open two project trees, one display sources, another – “other” and “Forms”.

I can add this functionality while refactoring usage of QSet.

What do you think aboutit at all?

Hi Oswald.
Do I need improve this feature, or it denied and it’s not needed anymore?

regarding the bitfield: the suggestion was to modify ProjectExplorer::FileType itself. i don’t know how many other changes this would cause.

i won’t comment on the rest, as that’s not really my domain.

“regarding the bitfield: the suggestion was to modify ProjectExplorer::FileType itself.”
I don’t really think that it’s a huge overhead.
But maybe making ProjectExplorer::FileType as QFlag may cause better memory footprint.
I'm still waiting for same maintainers attention.

Hi, and sorry that it took me so long to reply to you.

As I already wrote in a reply mail to your original mail to the qt-creator mailing list (Jan 5th), I don’t think that this is a good idea in the whole. It really just fills your specific usecase, and, generalizing it, opens a never ending can of filter options. I’ll quote here what I said in the mail:

What is a missing “feature”, which I looked into (but it’s not trivial to implement in the “FlatModel” because one needs to merge nodes from a deeper level), is to make it possible to hide the categories (but still have the “complex” tree).

This is for the people who simply want to see their file system structure, not some magic folders at all.

Now that you know the code a bit after that exercise :)