Google SOC 2006 Project Proposals
From KDevelop
[edit] Summer of Code 2006 Project Proposals
Please add any Google Summer of Code project proposals to this page. If you are willing to be a mentor for a particular proposal, please add your name to the proposal too. Matt Rogers and Alexander Dymo are willing to mentor any project on this page if the project or the student does not already have a mentor. Mentors for the individual idea should be contacted first.
Also, if you have your own project idea related to KDevelop, please subscribe to the developer mailing list, send it there and you might get some valuable feedback and perhaps even find a mentor!
[edit] Sequence charts
[edit] Summary
To understand a complex program, one has to look not only at static aspects (class inheritance and containment relationship), but also on dynamic aspects (in which order object invoke each other' methods). The plan to to make KDevelop visualize dynamic aspects of program design, in form of sequence or collaboration diagrams alike to UML.
[edit] Use case
User starts a program and indicates to KDevelop a number of objects he's interested in. He can either say he's interested in calls to all methods on those objects, or additionally indicate "interesting" methods. Qt slots are not different from ordinary methods here.
The user then runs the program. KDevelop inserts breakpoints for all interesting methods, and records when the methods are called, with that arguments and what they return. Using that information, it produces sequence and collaboration diagrams and shows them to the user.
[edit] Technical details
The implementation should draw upon "tracepoints" mechanism present in KDevelop debugger part. It's possible to either implement new kind of tracepoints specially for this purpose, or allow to specify JavaScript actions for breakpoint hit, and implement digram drawing using JavaScript. It is desirable to show the diagrams using Umbrello, and make it possible to export diagrams to XMI format that Umbrello can understand. To avoid technical issues, this work should be done on KDevelop 3.4 codebase.
Possible mentor for this project is Vladimir Prus.
[edit] Next-gen version control
[edit] Summary
Existing GUI tools for version control are not extremely helpful for real tasks. It's needed to carefully consider what users really want from version control and make is as simple as possible.
[edit] Use cases
- Annotation. User wonders what the hell is written on line 200 of a source file. He invokes a keyboard shortcut, and revision numbers and author names appear the the left of the edited source file. Hovering mouse over revision pops up log message to that revision. Clicking revision brings a dialog that shows all revisions in which that particular line was modified.
- Committing. User invokes the "Commit" command. In the editor area, new window appears showing the diff for all the changes. For each file, and for each hunk inside file, user can decide to skip that file/hunk from commit. (This means that each file should be preceeded by "active" area with "Skip this file" button, and the same for hunks). Skipping a hunk should be transparent for user -- IDE should revert skipped hunks, commit the reminder and re-apply the skipped hunk. Care should be taken to never lose user's changes.
- Automatic log messages. When comitting, IDE should be able to identify all changed functions and classes, and prepare a log message, listing names of changes entities and allowing the user to document each change. For each changed function, user should be able to see the diff hunks for that function. Probably, this functionality is better integrated with diff viewer talked about above, so that for each hunk in diff viewer user can enter comments that will be added to log message. It is necessary to mark some kinds of "interesting" changes, for example -- user visible changes (that should be added automatically to user CHANGES.txt file), or changes that should be further documented, or security fixes. The idea is that developer should be be able to ever create any changes files manually, everything should be generated from commit logs.
- Integrated diff viewer. It should be possible to open externally sent patch right in KDevelop and apply it wholesale or partially. Amoung other things user should be able to control the amount of context lines shown, including showing the entire files with hunks in them. In this mode it's necessary to provide efficient navigation between hunks.
[edit] Technical details
This project should be done with KDevelop 4 and KDE 4. As such, the student should become very familiar with the Qt 4 model/view framework. The work for the actual version control system (not the patch handling) will need to be implemented as a set of interfaces that pluggable backends can implement to provide services. At least one backend should be implemented. The KDevelop project would prefer that subversion is the backend implemented but the student is free to implement a backend of his or her choosing.
Possible mentors for this project include:
- Vladimir Prus
- Matt Rogers
[edit] Issue manager
[edit] Summary
An important part of open-source is handling bug reports and patches. Usable issue trackers exist, but fully integrating an issue tracker into IDE will bring even more benefits.
[edit] Use cases
- "What now?". User works on several projects, open- and close- source. Each, in theory, has different bug tracker. User should connect KDevelop to all those bugtracker, and after setting bug priorities should have a window in KDevelop, that shows all bugs in all those bugtracker. Filtering is also needed, for example "All my bugs by priority", or "1 most important bug for each project".
- Full access to all bugs. All bugs should be accessible for editing using maximally uniform interface, hiding differences in various issue trackers.
- Auto-creation of issues from code. The TODOs and FIXMEs in code should optinally become issues in bug tracker. It might be good idea to do this after some delay (a day or two).
- Auto-creation of issues from mail. KDevelop should cooperate with KMail to detect patched sent to specified mailing list, and automatically create issues from them. Ideally -- issues should be created after specified delay (a week), and when responding to a mail I should be able to specify that the problem is fixed, so that KDevelop won't create issue for a solved problem. It should also track unreplied user queries.
- Closing a bug should add it to a list of fixes in a file specified by the user.
Possible mentors for this project are:
- Vladimir Prus
- Matt Rogers
[edit] Unified code/header editing
[edit] Summary
In C++, headers and implementation are separate (unlike Java and C#). Some users try to use a "unified" style in C++ too, by writing all methods inline in headers. However, since C++ lacks a module system, this approach is not practical for large projects. The idea is to create the illusion of a "unified" style while retaining header/code separate at the filesystem level.
[edit] Use case
User selects "new class" command. KDevelop creates .h and .cpp files (properly generating header guard and namespaces), and shows to the user a single window. User writes the class with methods defined inside the class. KDevelop internally modifies the .h and .cpp files, writing only method prototypes to .h files, and only implementation to .cpp files.
The important points to consider are:
- How to separate #includes needed by header and #includes needed by implementation? Ideally, user should specify name->header mapping, and using a name will automatically add proper #include. In that case, depending on where the name is used we can add #include either to .h or to .cpp
- How to maintain readable style for generated files. We need working and customizable auto-formatting of code.
Possible mentor for this project is Vladimir Prus.
[edit] C# parser / integration
[edit] Summary
As .NET and Mono are becoming more important for Linux and cross-platform development, KDevelop would benefit from proper C# support part. One important step to reach this goal would be a C# parser that recognizes source code and integrates with KDevelop's code model, so that features like code completion and class/method navigation become available.
[edit] Technical details
KDevelop4 parsers should be written with the help of the kdevelop-pg parser generator because KDevelop4 refactoring will be based on it. The lexer could be done with Flex or re2c. It might be a good idea to simply transform another public domain C# parser (like one for ANTLR) into a kdevelop-pg grammar.
The parser will essentially be independent from KDevelop. When it's done it needs to be hooked up with KDevelop, providing an initial C# language support part.
[edit] Accepted
This project has been accepted and was implemented by Jakob Petsovits, with Alexander Dymo as a mentor and Adam Treat providing additional guidance.
[edit] KDevelop IDE User Interface Design and Development
[edit] Summary
Good UI design is the key for success of KDevelop IDE. The interface should be usable and represent all features, good-looking and at the same time pragmatic, easy to use and at the same time powerful. The emphasis on keyboard-only navigation should be made to make project development as fast as possible.
[edit] Technical details
The design should be documented and sent to the kdevelop-devel@kdevelop.org mailing list for discussion and approval. The KOffice UI competition examples and rules are applicable here. Special care should be taken to the workflow. See for example this thread.
Once the design is approved, the UI library should be written. UI library should be as independent of KDevelop as it is possible. Ideally, it should depend only on Qt and KDE libs. Interests of all KDE projects using KMDI library should be taken into account. Finally the UI library should be incorporated into the KDevelop shell.
The development should be taken in KDevelop trunk (i.e. KDevelop4 version) with Qt4 and kdelibs4.
Possible mentor for this project is Alexander Dymo.
[edit] Teamwork Mode
[edit] Summary
Allow developers to exchange and automatically apply patches, share documents and work on the same document in real time.
[edit] Technical details
Allowing collaborative editing of the same document in real time will require the support of the editor. The student will have to work closely with the kate project in addition to the kdevelop project in order to add that collaborative editing functionality.
[edit] Accepted
This project has been accepted and was implemented by David Nolden. Matt Rogers is the mentor for this project.
[edit] Add support for distributed compiling
Provide a way for KDevelop to detect and use distributed compiling functionality as provided by distcc or icecream. It should require as little configuration on the part of the user as possible. The user should also have the ability to turn it on and off as necessary.
[edit] Static code analysis
Quality check code with extendable lint-like rules. Some ideas of the checks to implement:
- Check that signals and slots within connect statements exist and their parameters match
- make sure operator== is implemented "const"...
[edit] Auto testing integration
Add support for testing frameworks to KDevelop. Functionality would include but is not limited to:
- Run all autotests after compilation
- Run autotests per module
- Make it easy for developers to create tests that use that framework
![[Main Page]](/graphics/theme3/KDevelopBigIcon.png)