User forums > General (but related to Code::Blocks)

Customizable Folder Tree

(1/2) > >>

Electron:
I'm new to codeblocks, so perhaps I've missed somethign that's possible, but Codeblocks seems to be missing several one the things I like about Dev-C++'s project file display, though codeblocks is in many ways the superior IDE.
   In Dev-cpp one can add additional folders to organize the project files. These folders need not correspond to the actual directories on the hard drive as the folders in CodeBlocks file display pane do. IMHO it would be very nice if codeblocks had this feature

Physicus:
That's what I am missing in C:B, too. It would be great to even have the possibility to make custom tree folders for the different projects in the workspace. This is only interesting for really huge projects, but I am sure ReactOS (an OpenSource windows NT/2000/XP compatible alternative, still apha, www.reactos.org) developers would really appreciate it, as it consists of hundeds of "projects" and it would be useful to have them sorted in one big workspace. Maybe recursive workspace files would be great, so you could create different workspaces for different parts of the projects and merge them together in a parent workspace.
I am not sure if it would be fast enough to load thousands of files into the tree, but it could be done "on the fly" only if you open a subfolder.

thomas:
This is a feature which cannot be implemented without a radical change to the way projects are handled. Unluckily, we still have plenty of other problems to handle at the present time (real problems, not gadgets). It is thus unlikely that this will come any time soon.

As a sidenote, I once used this great feature with Dev-CPP back in the old days, and renaming something crashed the application, corrupting a project file with ~250 sources beyond repair.
That's something we may want to avoid... :lol:

Game_Ender:

--- Quote from: thomas on March 02, 2006, 05:17:57 pm ---As a sidenote, I once used this great feature with Dev-CPP back in the old days, and renaming something crashed the application, corrupting a project file with ~250 sources beyond repair.
That's something we may want to avoid... :lol:

--- End quote ---

Yes, but you could do it right, like Xcode and you will have a wonderfully helpfull tool.  It is very easy to make a project which consists of files from all over the place, but is still nice and organized.  Don't knock the feature because someone else did it badly.  After all I bet they didn't unit test it first ;).

ikolev:
I don't think creating custom folders is such a good idea. Whenever I've used this feature in other IDE's (Visual C++ and Dev-Cpp), I've always used it just to mirror the directory folder structure. I haven't worked on very large scale projects (such as an OS - btw, I really hope ReactOS will achieve its goals one day), but I think that on such projects its even more important to keep project files properly organized into folders (packages). (At such points I like refering to John Lakos' "Large Scale C++ Software Design" - a fundamental book for anyone working on large C++ projects.) So I think C::B's feature to mirror the directory structure in the project tree is just what's needed.

There is however one small improvement that can be done. Source and header files are often pushed a few levels down the hierarchy for some reason. In such cases they appear in the project tree below a few levels of empty folders. Here's an example project structure:

/
/include
/include/MyLib
/include/MyLib/*.h
/src
/src/MyLib
/src/MyLib/*.cpp
/src/Samples
/src/Samples/*.cpp
/proj_cb
/proj_cb/MyLib.cbp
/proj_cb/MyLibTests.cbp
/proj_cb/Samples.cbp

In this case, the MyLibTests project will display this structure:
- src
  - MyLib
    *_t.cpp

If MyLib was larger and had sub-packages, the chain of empty folders at the top would be longer. It would be nice if C::B had an option to skip the top levels in the project tree (in this case src and MyLib) and display the content of first folder which has more than one item (file or sub-folder) in it. Of course, this problem would not exist if .cbp files were kept in the folder of the files they include, instead of a separate common folder. But this approach is prefered on projects which use more than one compiler and have several different sets of project files.

Navigation

[0] Message Index

[#] Next page