My running wishlist of KDevelop
Steven T. Hatton
hattons at globalsymmetry.com
Fri Jun 3 13:13:05 UTC 2005
This is a file I just threw together to try an capture all the things I whish
KDevelop supported. Many of them are in the bug database somewhere. I just
felt like it might be a good idea to pull them all to gether and see what
patterns might be revealed. The list is by no means complete. For example I
don't even mention extensionless headers. Nor do I list any of the
functional bugs I am concerned about.
<?xml version='1.0'?>
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.3b5//EN"
"/usr/share/xml/docbook/schema/dtd/4.3/docbookx.dtd">
<book>
<title>KDevelop C++ Part Wishlist</title>
<chapter>
<title>KDevelop C++ Part Wishlist</title>
<itemizedlist>
<listitem>
<para>
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.
</para>
<formalpara>
<title>Separate include and source directory trees</title>
<para>
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.
</para>
</formalpara>
<screen>
<filename>project/src/main.cpp</filename>
<filename>project/src/Project.cpp</filename>
<filename>project/src/sub1/Sub1.cpp</filename>
<filename>project/src/sub2/Sub2.cpp</filename>
<filename>project/include/Project.hpp</filename>
<filename>project/include/sub1/Sub1.hpp</filename>
<filename>project/include/sub2/Sub2.hpp</filename>
</screen>
</listitem>
<listitem>
<formalpara>
<title>Separate include and source directories within subprojects</title>
<para>
It should be possible to place all source files in one
subdirectory within a subproject directory, and the header
files in a different subdirectory.
</para>
</formalpara>
<screen>
<filename>project/src/main.cpp</filename>
<filename>project/src/ProjectClass.cpp</filename>
<filename>project/include/ProjectClass.hpp</filename>
<filename>project/sub1/src/Sub1Class.cpp</filename>
<filename>project/sub1/include/Sub1Class.hpp</filename>
<filename>project/sub2/src/Sub2Class.cpp</filename>
<filename>project/sub2/include/Sub2Class.hpp</filename>
</screen>
</listitem>
<listitem>
<formalpara>
<title>
Ability to automatically map namespaces to subproject structure.
</title>
<para>
A project should be configurable to automatically create
and use a namespace reflecting the name of each subproject.
</para>
</formalpara>
<screen>
<filename>project/src/main.cpp</filename>
<filename>project/src/ProjectClass.cpp</filename>
<filename>project/src/ProjectClass.hpp</filename>
<filename>project/src/sub1/Sub1Class.cpp</filename>
<filename>project/src/sub1/Sub1Class.hpp</filename>
<filename>project/src/sub1/sub1sub1/SubSub1Class.cpp</filename>
<filename>project/src/sub1/sub1sub1/SubSub1Class.hpp</filename>
<filename>project/src/sub2/Sub2Class.cpp</filename>
<filename>project/src/sub2/Sub2Class.hpp</filename>
</screen>
<para>
<programlisting>
//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{};
}
}
}
</programlisting>
</para>
</listitem>
<listitem>
<formalpara>
<title>Code reformatting configuration should be stored per
project.</title>
<para>
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.
</para>
</formalpara>
</listitem>
<listitem>
<formalpara>
<title>Class browser should display members in declaration order.</title>
<para>
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.
</para>
</formalpara>
</listitem>
<listitem>
<formalpara>
<title>
The IDE should warn about improperly ordered member initializations.
</title>
<para>
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.
</para>
</formalpara>
</listitem>
<listitem>
<formalpara>
<title>
Option to add new member attribute to the member initialization list.
</title>
<para>
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.
</para>
</formalpara>
</listitem>
<listitem>
<formalpara>
<title>Optional accessor creation with new attribute creation.</title>
<para>
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.
</para>
</formalpara>
</listitem>
<listitem>
<formalpara>
<title>Ability to create classes with only header files.</title>
<para>
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.
</para>
</formalpara>
</listitem>
<listitem>
<formalpara>
<title>Specify filename extensions per project</title>
<para>
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.
</para>
</formalpara>
</listitem>
<listitem>
<formalpara>
<title>Class filename case preservaton should be project local</title>
<para>
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.
</para>
</formalpara>
</listitem>
</itemizedlist>
</chapter>
</book>
<!--
<listitem>
<formalpara>
<title></title>
<para></para>
</formalpara>
</listitem>
-->
--
Regards,
Steven
More information about the KDevelop-devel
mailing list