QtCreator - Merging header and source folders in tree view
-
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.
-
hi
i dont know why qt deside this way to show folder that is very very annoying but you can download source code of qtcreator from https://github.com/qt-creator/qt-creator and change very small to solve problem
in file qt-creator/src/plugins/cmakeprojectmanager/fileapidataextractor.cpp at function addCompileGroupsif(false)for (size_t i = 0; i < sourceGroupFileNodes.size(); ++i) {
std::vector<std::unique_ptr<FileNode>> ¤t = sourceGroupFileNodes[i];
FilePath baseDirectory;
// All the sourceGroupFileNodes are below sourceDirectory, so this is safe:
for (const std::unique_ptr<FileNode> &fn : current) {
if (baseDirectory.isEmpty()) {
baseDirectory = fn->filePath().parentDir();
} else {
baseDirectory = Utils::FileUtils::commonPath(baseDirectory, fn->filePath());
}
}FolderNode *insertNode = createSourceGroupNode(td.sourceGroups[i], baseDirectory, targetRoot); insertNode->addNestedNodes(std::move(current), baseDirectory); }else{ for (size_t i = 0; i < sourceGroupFileNodes.size(); ++i) { std::vector<std::unique_ptr<FileNode>> ¤t = sourceGroupFileNodes[i]; FilePath baseDirectory; // All the sourceGroupFileNodes are below sourceDirectory, so this is safe: for (std::unique_ptr<FileNode> &fn : current) targetRoot->addNestedNode(std::move(fn), baseDirectory); } }
-
Just to push for the same problem:
I am a big fan of Qt-Creator, and also of CMake: I use them professionally since many years.
In CMake, there are specific syntaxes to set the required project structure, and this has to stay like this (it is not expected to imitate the OS-filesystem structure). However, dividing each project into "Sources", "Headers" and "Other Locations" make the full project much harder to explore.
I found myself opening again and again the same file in the OS-filesystem explorer, just because I can't easily find the desired file in the project structure. This is IMHO a good indicative that the Projects-explorer is below expectations.
Example of project:
client_project |- Header Files | |- Subproject1 | | |- SubSubproject1 | | | |- File1.h | | |- SubSubproject2 | | | |- File2.h | | |- File3.h |- Source Files | |- Subproject1 | | |- SubSubproject1 | | | |- File1.cpp | | | |- File1_bis.cpp | | |- SubSubproject2 | | | |- File2.mm | | |- File3.cpp
Important note: FIle1.cpp and File1_bis.cpp both implement File1.h, thus F4 does not allow to navigate easily between them. F2 helps, but do I really need to go to a function that I know is implemented in the desired file to open that file?
Just imagine that this project has over 1000 files, and that most structures are collapsed, that you need to scroll about 200 lines to see the matching header and source file (e.g. File1.h to File1_bis.cpp).The tree is supposed to be (as per CMake project):
client_project |- Subproject1 | |- SubSubproject1 | | |- File1.h | | |- File1.cpp | | |- File1_bis.cpp | |- SubSubproject2 | | |- File2.h | | |- File2.mm | |- File3.h | |- File3.cpp
Simpler to locate files right? If I prefer to split headers and sources, I can easily do it with CMake too (flexibility).
Note: This is not the OS-filesystem structure. For instance, SubSubproject2 is only loaded on macOS, while another SubSubproject3 is loaded instead on Windows, and a third on Linux.
-
At the moment you can "move" all headers and source files related to project to one folder by clicking "simplify tree" in filter menu.
-
@puzzled_giraffe Thanks, you are my savior.
-
Since Qt Creator 5 if you go to the "Filter Tree" drop down button, you can select "Hide Source and Header Groups".
See it in action here: