QtCreator - Merging header and source folders in tree view
Is it possible to have QtCreator not separate the headers from the sources? Ideally I would just like to see a "source" folder that contains all my headers and sources in the same tree.
The Projects view is meant to visualize the project structure, which is why it is very independent of the filesystem layout. In the project source and header files (and the other kinds of files supported) are processed in very different ways, so they are shown in separate places.
You can always switch to the filesystem view, which will give you a view of how your files are organized on disk. That is not tree-based though, but -- as always -- patches are welcome:-)
Not a nice one, but a quick hack against current Qt Creator 2.6 branch
I actually meant patches to the file system view... not patches to mess up parsing of .pro-files.
This patch will have quite a few side effects: Creator needs to know which files are headers and which are sources and this patch removes this distinction.
I guessed it would have side effects, but the resulting view is what I think mirswith wanted, and what I wanted to have in my current situation too.
An internal separation of header and source maybe necessary for Qt Creator, the visualization doesn't require that probably. In my case I had quite a large framework with several subfolders. Those folders are perfectly shown in the Qt Creator project view, but switching to the header using the project navigation is not very convenient, because if the Source folder structure is expanded, you have to scroll a lot to find the related header file. Of course you can always use the Header/Source keyboard switch. But letting the user choose the way of grouping would be better.
How is pressing F4 inconvenient?
Seriously: Your patch is changing how Creator parses .pro-files, not how the project tree is rendered. I admit that this is most likely the only way to do what you are trying to do: The Project view is supposed to visualize the .pro-files, their contents and their relation to .pri-files, etc. The separation of headers, sources, ui-files, etc. is important in this context. Changing the grouping will break that and make this view rather useless.
Why don't you use the file system view if you want to see files that are located together in the file system?
Comming from Visual Studio and XCode I might have a different view on code project managment as someone who is grown up with QMake's pro an pri files. I only wanted to visualize with the patch what the original poster might wanted to archive, I never said, this patch should be integrated in any way.
I myself don't use Qt Creator with qmake, but only as an IDE for simple GNU Makefiles (for what it may be not intended, but it's the best solution for Linux I found so far, and if project managment would be better, it could even compete with Visual Studio). File System View is quite limited if you handle multiple projects, so that's not an option.
I doubt I would find time digging into creator's source code, but as an inspiration, having build dependencies between loaded projects (by the way, where does Creator store the dependencies you can configure in the project settings?) and creator files that are user independent (storing virtual folder structures and project dependencies) would be something very very convenient.
All in all, don't get me wrong, I like creator, it just doesn't fit my needs for 100% currently. But it's< still much better than eclipse. Haven't tested KDeveloper 4 yet, but doubt it would be more convenient when handling multi platform development.
I just played a bit with the file system view and adjusted it to make it behave more like a project explorer.
It shouldn't have any side effects on Creator and may make the project navigation a bit more convenient for some people (depending on your project file structure).
Volki21: That looks much more useful, thanks! Would you please consider to push this into "gerrit":http://codereview.qt-project.org/ for review? We unfortunately require the legal paperwork that gerrit enforces to accept contributions.
All the settings creator has about the project are stored in a .user file in your source directory. I am not sure build dependencies work well, and I think those should not even be covered by creator at all: We want projects to work without creator, too, so information like project dependencies should not be handled by the IDE. Dependencies are also something that build systems are very good at handling, why should we duplicate that functionality in Creator?
We are getting closer to having user independent .user files with each release:-) You can already move parts of your configuration into .shared files in Qt Creator 2.5. Those have exactly the same syntax (just copy sections over and fix the XML, there is no tool for that yet) and enable e.g. sharing of for the coding style settings. It does not work well for build configurations, etc. as those reference information specific to one instance of Qt Creator.
The trickiest part in the .user files used to be the Qt versions that were stored in there, which are gone in Qt Creator 2.6. What is left are a couple of pathes. Let's see whether we can make those relative or add variables or something to make them work for other people. This will of course assume that all developers have a rather similar setup of Qt Creator (essentially the same kits as set up by the new sdktool). That should be doable in a commercial developer team, but I am not so sure about open source projects where setups tend to vary a lot more between developers.
I wouldn't add the patch in the current state to the main trunk yet. It's far away from being really what I intended, because you currently can not manage the project using the file system view. I would recommend to add another plugin similar to the file system view, but allowing manipulation of the project configuration. Something I might inspect in the future if I can find some time.