My current wishlist.

Tue Jul 26 17:20:10 UTC 2005

One thing I am sure of.  There are typos in this document.  It is probably 
much easier to read in HTML, which you can find here:

http://baldur.globalsymmetry.com/open-source/org/kde/kdevelop/kdevelop-wishlist.html

KDevelop C++ Part Wishlist
Table of Contents
1. KDevelop C++ Part Wishlist
Chapter 1. KDevelop C++ Part Wishlist
 Both this item and the next could be supported by providing the user the 
ability to arbitrarily specify the location of source files and header files 
within a subproject, as well as the location of the subproject itself. 
Separate include and source directory trees.  It should be possible to create 
a project with all header files stored in one directory tree, and all sources 
stored in a different tree. Both trees should reflect the subproject 
sturcture. 
                                        project/src/main.cpp
                                        project/src/Project.cpp
                                        project/src/sub1/Sub1.cpp
                                        project/src/sub2/Sub2.cpp

                                        project/include/Project.hpp
                                        project/include/sub1/Sub1.hpp
                                        project/include/sub2/Sub2.hpp

Separate include and source directories within subprojects.  It should be 
possible to place all source files in one subdirectory within a subproject 
directory, and the header files in a different subdirectory. 
                                        project/src/main.cpp
                                        project/src/ProjectClass.cpp
                                        project/include/ProjectClass.hpp

                                        project/sub1/src/Sub1Class.cpp
                                        project/sub1/include/Sub1Class.hpp

                                        project/sub2/src/Sub2Class.cpp
                                        project/sub2/include/Sub2Class.hpp

 Ability to automatically map namespaces to subproject structure .  A project 
should be configurable to automatically create and use a namespace reflecting 
the name of each subproject. 
                                        project/src/main.cpp
                                        project/src/ProjectClass.cpp
                                        project/src/ProjectClass.hpp

                                        project/src/sub1/Sub1Class.cpp
                                        project/src/sub1/Sub1Class.hpp

project/src/sub1/sub1sub1/SubSub1Class.cpp

project/src/sub1/sub1sub1/SubSub1Class.hpp

                                        project/src/sub2/Sub2Class.cpp
                                        project/src/sub2/Sub2Class.hpp

//project/src/main.cpp
#include <whatever.hpp>
int main() {
}

//project/src/ProjectClass.hpp
//optional whether there is a project level namespace
namespace project {
  class ProjectClass {
    ProjectClass();
  };
}

//project/src/ProjectClass.cpp
namespace project {
  ProjectClass::ProjectClass() {
  }
}

//project/src/sub1/Sub1Class.hpp
namespace project {
  namespace sub1 {
    class Sub1Class{};
  }
}

//project/src/sub1/sub1sub1/SubSub1Class.hpp
namespace project {
  namespace sub1 {
    namespace sub1sub1 {
      SubSub1Class{};
    }
  }
}                                               

Code reformatting configuration should be stored per project.  It is 
reasonable to assume different projects will have different requierments for 
source code formatting. It therefore makes sense to save these settings per 
project, with a default global configuration which is also user customizable. 
This global configuration should be used as a template for the project local 
configurations. 
Class browser should display members in declaration order.  The declaration 
order is an important part of class structure, and should be communicated by 
the tools used to represent the class graphically. For example it is 
important that the oder of member declaration be known when populating meber 
initialization lists because members are initialized in declaration order. 
Since declarations are typically in the header file, while member 
initialization lists are typically in the source file, the programmer must 
switch between these files to determine what the ordering is if he should 
forget. 
 The IDE should warn about improperly ordered member initializations .  As 
stated above, member initialization order can be significant to how a program 
behaves. It is almost certainly bad style to initialize out of order, and 
likely it is an error. The IDE should detect this condition and warn the 
user. Perhaps this could be done by changing the font, or font background 
color when members appear in improper order. 
 Option to add new member attribute to the member initialization list .  When 
creating a new member attribute of a class there should be an option to have 
that member added to the meber initialization list of the class. This. of 
course, should place the members in declaration order within the list. 
Optional accessor creation with new attribute creation.  When new new 
attributed are added to a class, it often makes sense to also add accessor 
methods for that attribute. The dialog should provide an option to do this. 
Ability to create classes with only header files.  Some classes do not need 
source files. For example, pure abstract interface classes do not have method 
definitions, and do not need a source file to hold them. Templates, and 
classes with all inline methods are other casses. 
Specify filename extensions per project.  It should be possible to specify 
both the set of filename extensions recognized by the IDE as project source 
files, and the extensions to be added to filenames by the file creation 
dialogs used within a project. It is freaquently the case that different 
projects used different file extension conventions in C++. It should be 
possilbe to easily adjust the project settings so the IDE behavior agrees 
with these conventions. 
Class filename case preservaton should be project local.  Like filename 
extensions, the filenameing conventions for a project often deffer between 
projects. The settings that control whether files created by the new class 
dialog should be local to each project, with the ability to set global 
defaults inherited by each project. 
Extensionless header filename support.  Some projects such as OSG use header 
files with no extension on the filename. Currently KDevelop does not support 
these header files. I know of the following problems related to using 
extensionless header filenames: 
 When these files are opened in the editor, they are treated as plain text. 
The syntax highlighting can be made to work, but the type of the file cannot 
be set to C++. This means that the other support features such as code 
completion, reformatting, class and member creation, etc., do not work. 
 There is no way to create header files without filename extensions using 
either the prject manager or the new class dialog. 
 If such a file is added to the project using the project manager, it is still 
treated as plain text. 
Viewing inherited class members.  Currently there is no way to view the 
complete collection of members of a derived class, includeing the baseclass 
members. It would be useful to have that ability. Ideally, this would go in 
the class browser. 
Open .kdevelop as XML.  This is a minor issue. It would be nice if 
the .kdevelop file for a project were automatically treated as XML by 
KDevelop when opened. 
Modifying declaration and definiont as a unit.  Though we can create member 
functions and have the declaration added to the header, and the definition to 
the source file, there is currently no way to modify the function declaration 
and definion as a unit. One approach would be to extract both the definion 
and declaration from the current header and source where they are defined, 
and display the composite in a small exitor window. If possible, this should 
also bring any doxygen comments into sync with the modifications to the 
funciton. 
Show all signatures of a member function in a code completion.  Code 
completion is not currently working, so I'm not sure about this, but I 
believe I cannot view such things as throw specification and constness in the 
code completion listing. It's important to know what signatures are already 
declared, so we can be sure we are overriding one, rather than declaring a 
new one. It migh even be worthwhile to show some kind of indication if a 
member function uses a name with a different signature. 
Parameter initialization should only be added to the declaration.  If a member 
function is created using the Add Method dialog, and a parameter of the 
function is given a default value, the default is written to both the 
declaration and the definiton. It should only be written to the defition. 
Open Makefile.am from the project manager.  There shoud be an option in the 
project manager to open and edit the Makefile.am associated with the current 
subproject. 
Emacs-style indentation.  If you know what it is, and have used it, you know 
what I mean, and why I want it. 
Better view of current environment.  It should be possible to view a list of 
all variables from the environment in which KDevelop is running, and to 
select an individual variable to display its value. This would help the 
programer determine what is in the various variables used by the compiler, 
preprocessor, etc. 
Header filename completion.  This works for header files within the project, 
but does not work for the entire include path. It would probably be best to 
have a means of registering certain directories as sources of headers to 
include in the current project, rather than the entire include path. For 
example, if the current project is using an SDK such as OpenSceneGraph, the 
OpenSceneGraph include directory would be added to a list of places to look 
for header filenames. The, of course, should add any relative directory names 
as well, e.g., #include <osgGA/GUIEventHandler> 
GCC output de-mangler.  The output form GCC is hard to read, in part because 
it repeats the error: and warning: tags are repeted in multiline messages. If 
the error messages could be reformatted to remove those, it would make them 
easier to read. 
Build environment decoupled from the KDevelope runtime.  This is absolutely 
essential. If there is a requierment to build against libraries other than 
the version that KDevelop was built with, or if the current environment 
conflicts with the target environment the user needes to be able to have 
complete controle over the build environment in terms of all variable such as 
$QTDIR, $KDEDIR, $LD_LIBRARY_PATH 
Virtualize destructors when menbers are made virtual. When a class member 
function is made virtual the destructor of the class should likewise be made 
virtual. It would be a good idea to automatically make a destructor virtual 
when using the method creation dialog. Providing some kind of warning 
indication in the editor and problem reporter would also be useful for the 
cases when the functions are created by hand. 
A #define hunter.  It is often the case that some value relevant to the 
current scope is set by a #define in a header file far removed from the 
currently opened file. I would be valuable to be able to locate such 
#definition. Perhaps there could even be a tool for specifically viewing 
#defines and providing access to the file where they are located. 
Include guard synchronizer.  If a file name is changed, the #include guards 
are likely to get out of synch with the file name. I propose all #include 
guards should reflect the file location relative to the project src 
directory. When a file is moved or renamed, the #include guard should reflect 
that change automatically. 
-- 
Regards,
Steven