KDevelop4: Creating a Qt slot, the cool way

In an earlier blog-post I’ve already written about automatic signal/slot matching and completion(See this). The code-completion box shows you the appropriate connectable signals and slots, and also shows exactly what signals match what slots. Now what if you have a signal, and you know want to connect to it, but you don’t have a matching slot yet? In the last days, I’ve implemented a new feature, that allows automatically creating a matching slot with the typed name, exactly matching the signature of the connected signal.

See this example:

A signal is being connected, but there is no perfectly matching slot(Or maybe you want another one). Now you can just continue typing, and you will see this item in the list:

Now when you execute this completion-item, KDevelop will automatically create the slot within the declaration of the local class, and will nicely complete the current connect(..) call, pointing a the new slot:

Here you see the declaration that was created within the header-file:

Together with the implementation-helpers, this will allow really rapid programming: Just pick your signal from somewhere, let KDevelop create the declaration and finish the connect(..), go to the place in the source-file where you want to implement the slot, and let the implementation-helper create a stub declaration for you. 🙂

Development update
Except for this, I’ve mainly done smaller bug- and crash-fixes since my last blog.
One interesting development is that Hamish Rodda has started fixing up our old version of the integrated debugger, which is nearly a straight port from KDevelop3, so we might have a usable debugger soon. He’s doing it in a branch. The debugger that is in trunk has some additional interesting features like hover-tooltips, and internal refactoring has happened since the original maintainer considers the code of the old debugger a mess, but suffers from the fact that it doesn’t properly work, and seems to be quite a bit away from it, at least that’s what those who tried to fix it found out.

Advertisement

KDevelop4: Automatic include-directives and forward-declarations

Missing Include Completion
C++ is a great and powerful programming-language. Yet it has the downside against some other languages, that you always have to deal with include-directives or forward-declarations before you can use a class.

This is a factor that often motivates me not to create too many different source-files, although design-wise that would make sense. Wouldn’t it be nice if you could just start hacking without caring about the whole visibility stuff? Especially when you have to do the same includes again and again, and already know the library you’re using and it’s classes, this is nothing more than an annoyance.

I had implemented a feature to automatically add include-directives within KDevelop 4 about a year ago, but it wasn’t as comfortable and useful as it could be. During the last days, I’ve taken the time to polish up this feature so it’s worth a blog-post.

The whole thing is based on the DUChain, and it respects all declarations from within the global duchain store. This means that from the moment on that KDevelop has processed a source-file, you can start just using the declarations from within that file from anywhere. Whenever you type something and the completion-list does not offer any completions, which means it’s not visible, then the missing-include completion will start searching the duchain store for matching declarations, and when it finds some, it will offer you right within the completion-list to automatically add an include-directive for you.

This works in many different situations: If you try calling a function or constructing a class, template-instantiate a class, if you try to access the contents of a class that is either unresolved or has only been forward-declared, or if you just type in the name of an arbitrary declaration.

Sometimes however when writing header files, you do not need the whole class-definition but rather just a forward-declaration. From today on, the very same list will show you an entry to automatically add a forward-declaration for the typed class for you. This even works with template-classes, and it correctly respects namespaces, creating namespace declarations around the forward-declarations as needed.

Together, under the circumstance that KDevelop already knows the classes you are working with, this frees you of one annoying part of the hacking.

Examples

This is what happens when you try calling a known function that has not been included yet:

And this is the effect you will have when you push the up-arrow and execute the “Add #include …” action:

This is what happens when you simply type the name of a known class:

And this is what you’ll get when you pick the “Add forward-declaration” action. A fully valid forward-declaration was inserted. Well, apart from the fact that std::allocator is not defined. 😉

Now std::vector is forward-declared. But what if you actually try using it? KDevelop will notice it, and will offer you including the correct header for being able to use it:

And this is what happens when you try to instantiate a known but not included template. Notice that it does offer to include the forwarding-header “QMap”, and not only the header that really contains the class which is “qmap.h”:

And now a little demonstration how this can help you using most any library:

See that ICore has a lot of members that again return pointers to other classes, that of course were only forward-declared. This usually means that before you can use the result of activeSession(), you have to find out where KDevelop::ISession is defined, and include it manually:

With KDevelop4, the content is only one key-press away:

Disclaimer
This is a feature for experienced users who know what they are doing. It always has to be reviewed, and KDevelop does NOT do any programming for you. 😉

Development Update
Although I don’t have that much time any more, I did find enough time to do quite some polishing during the last weeks. Many crashes and bugs were fixed, and I even found time to imlement some smaller features.
Here the most important points:
– The implementation-helper and signal/slot completions now are shown within separate groups in the completion-list, that are shown in an appropriate place(usually right at the top)
– Access-rights is now fully respected by the completion-list, including friend-declarations.
– Not found declarations can be highlighted with an error-underline now(There’s a new “highlight semantic problems” option in the configuration)
– Added context-sensitive code-completion for builtin C++ keywords
– Full code-completion, use-building and refactoring for namespace names
– Less annoying automatic completion, because it auto-hides when an item in the list is matched
– Workaround a multi-threading problem within kdelibs and ksycoca that caused KDevelop to crash very often
– Fix a repository-locking problem that made kdevelop reproducably crash under special circumstances

Although we do not have all the features we want together, we will be releasing a beta-version of KDevelop4 soon, because we believe it’s already a useful application. Aleix Pol Gonzales has started working on the much needed documentation integration, and Hamish Rodda has today started some new discussion on the debugger, and is planning to bring it into a usable state.