Recently, when porting away from KSharedPtr (which is now deprecated under KF5) to QExplicitlySharedDataPointer in KDevelop's frameworks branch, I noticed an interesting issue in the QExplictlySharedDataPointer API.

Suppose we have two classes both inheriting from QSharedData (directly and indirectly):

class Base : public QSharedData {};
class Derived : public Base {};


Now let's use QExplicitlySharedDataPointer to manage these shared data objects. And let's write some bogus code on purpose:

QExplicitlySharedDataPointer<Base> base(new Base);
QExplicitlySharedDataPointer<Derived> derived(base); // Oops. That compiles!


Huh? What happened? We now have a shared pointer of type Derived* pointing to a Base* object. This is definitely implies wrong usage of the shared pointer type.

The code causing this is easily spotted in qshareddata.h:

template<class X>
inline QExplicitlySharedDataPointer(const  QExplicitlySharedDataPointer<X> &o)
: d(static_cast<T *>(o.data()))
{
if(d)
d->ref.ref();
}


Wow. There's a static_cast<> inside one of the constructors of QExplicitlySharedDataPointer. This cast makes our code compile without any warning/error.

After some discussion with people from the QtCore team we concluded that this is is just wrong and the static_cast<> shouldn't be there at all. Now in Qt 5.4, this code path is completely disabled thanks to the following patch: https://codereview.qt-project.org/#/c/88569/

Happy porting to QExplicitlySharedDataPointer again!

Note: QtXmlPatterns is the only Qt module depending on this hidden cast at all. Other modules compile fine without it. This one now needs to define a special macro in order to re-enable the static_cast<>: QT_ENABLE_QEXPLICITLYSHAREDDATAPOINTER_STATICCAST

Hey,

In the first two weeks of my GSoC I've spent time on moving out lots of code from the current C++ language support into kdevplatform (the base of KDevelop, which contains all the non-language agnostic, reusable components for the IDE).

## Task recap: Assistants / Refactoring

• Rename assistant: When you change a local variable name, this assistant renames all uses of it, too. This feature is mostly non-language-agnostic, so it makes sense to refactor it in a way it gets available for all supported languages. Currently, this feature is only available in oldcpp, being less useful than it could be.

• Adapt signature: Similar to above – when changing the signature of a function at the declaration/definition, this offers adapting the corresponding definition/declaration signature. This probably doesn't fit for a non-language-agnostic assistant (because of C++-specific bits required when adapting signatures), hence we need to port this over from oldcpp to clangcpp.

• Declare function/member/variable: When you use some undeclared function/member/variable, we offer you to create a private/public/local declaration of that as appropriate.

• Rename File: When you rename a class and the file it was declared in matches the old identifier, we offer you to rename the file in accordance.

## Achievements

An image is worth a thousand words, so let me quickly show you a screenshot of the rename assistant in action:

Prior to my change, these assistants basically were only useful to the C++ language support. The infrastructure (the controller for showing/hiding the popups) resided in the C++ plugin. But funnily, for example the Python plugin accidently re-used parts of the old C++ language support and hence was able to show these assistants, too. However, whenever we're using the Clang plugin we have to disable the original C++ language support, which suddenly exposed that there's something wrong (i.e. the assistants didn't show up anymore). So, I had a look at it and in the end we've decided that this is useful for all languages and agreed to move this API into kdevplatform.

So, in fact, that change gave us the possibility to base all assistants we have in place on a common interface (called StaticAssistant) and a central place for registering those to the session (via StaticAssistantsManager). The full diff can be seen here: https://git.reviewboard.kde.org/r/118542/ (kdevplatform change).

While this change has basically nothing to do with KDevelop-Clang itself, it still helps to provide a better experience with the Clang plugin enabled. Just let me show you this helpful assistant popup:

or this little guy here:

Note: As you can see, there's a small issue in this screenshot. It doesn't actually show the error text anywhere. It just proposes how to fix it. That's an issue we were already discussing.

What I personally would love to see is to be able to embed widgets in-between the lines in the editor that show the actual error. Working with a bit with Coverity (a static analysis tool) lately, I've found this way of representing errors quite convenient. I've already been in touch with the Kate guys in order to (hopefully) get that implemented at some point.

## Wrap-up

So, while these two weeks consisted more of a refactoring work on existing code, it still needed to be done. Any change which cleans up architectural issues in KDevelop land actually makes us really happy.

For the next two weeks I'm focusing on getting all the Code Completion features (see my original blog post for reference) into KDevelop-Clang.

By the way, if you enjoy what we're working on in KDevelop these days, or what people do in KDE in general, please consider donating to a fundraiser helping us to organize a meeting for bringing KDE/KDevelop forward. Your help is greatly appreciated!

Thanks!

Hey,

I'm happy to announce that I've been accepted as student for this year's Google Summer of Code! This summer, I'll have the chance to improve the Clang integration in KDevelop, something we (the KDevelop developers) have been working on for some months already.

# Project Introduction

Milian's blog post from two months ago pretty much explains all you need to know about the current situation regarding C/C++ language support in KDevelop.

A quick recap: KDevelop's current C++ language support plugin basically implements a fully custom C++ parser frontend, in about 55 KLOC of code. This includes an implementation of a C Preprocessor (about 4 KLOC) the actual C++ parser (about 15 KLOC) and a whole lot of glue code to transform all that in a meaningful representation for the user. As you can imagine, this is a real maintenance nightmare. Our bug tracker is full of entries containing code snippets where our custom C++ parser just fails. Fixing each of those and/or adding support for more complex language features such as C++11 lambdas, variadic templates, etc. is extremely difficult and error prone.

Using Clang to actually do the heavy-lifting for us was a long-standing idea. A few months ago, that idea actually began to take shape, when Olivier JG started playing around with Clang's C API (provided by libclang) in kdev-clang. kdev-clang aims to integrate Clang into KDevelop for C/C++/Objective-C language support.

The benefit is immense -- Citing Milian: "(Now) we can actually concentrate on making our IDE shine instead of playing catchup with the compiler."

# Current State

The Clang language plugin already supports:

• Parsing of full projects, supporting all C++ features that Clang supports
• Semantic highlighting
• Code browsing
• Basic code completion, including macros
• Support for Clang diagnostics [implemented by me]
• Support for Clang fixits (they are the solution approaches to common errors) [implemented by me]

## DUChain integration

• Qt Integration: Oldcpp has some extensions for improved Qt support. Examples are support for the Q_PROPERTY(...) declarations which are parsed by Qt's MOC, but expand to nothing in C++. Olivier Goffart did some investigations in that regard, and showed that clang can be made to work with this, see http://woboq.com/blog/moc-with-clang.html. In order to provide a good user-experience for Qt/C++ developers, we should be able to provide context browsing inside the Q_PROPERTY(...) macro. Other interesting stuff: Support the new signal-slot syntax in Qt5 properly.

• Macro support: When hovering over macro uses oldcpp shows macro definition location, the original macro text plus the expanded preprocessed text. This is currently missing in clangcpp – would be nice to get this back. Oldcpp also offers to navigate inside the preprocessed text, something we'd want back as well.

• Include navigation: Allow to browse includes again (triggered by hovering of #include <somefile> directives and similar)

## Code completion

• Code completion: This is work-in-progress at the moment, so it is left to see at what state we are when GSoC begins. Currently some things are still missing, such as “virtual override completion”. Also the automatic replacement of . to -> and vice-versa in case of pointer/non-pointer types is still missing.

• “Implement function” feature: If a function is only declared but not defined, we offer a "implement function" helper item in the code completion. This is currently not yet ported to clangcpp.

• "Switch to Definition/Declaration” feature: If the cursor is at some declaration in a header file, KDevelop offers a shortcut to automatically switch to its definition in the source file (opening the corresponding file in the active view). This is not yet possible in clangcpp.

• Show viable expressions for current context: When inside a function call or constructor call, show viable expressions which fit the signature of the current argument. Example: int i = 1; char* str = “c”; strlen( – this should show variable str in the completion popup as best match.

• Include completion: Oldcpp offers completion hints when attempt to #include some file, port this to clangcpp.

## Assistants / Refactoring

• Rename assistant: When you change a local variable name, this assistant renames all uses of it, too. This feature is mostly non-language-agnostic, so it makes sense to refactor it in a way it gets available for all supported languages. Currently, this feature is only available in oldcpp, being less useful than it could be.

• Adapt signature: Similar to above – when changing the signature of a function at the declaration/definition, this offers adapting the corresponding defintion/declaration signature. This probably doesn't fit for a non-language-agnostic assistant (because of C++-specific bits required when adapting signatures), hence we need to port this over from oldcpp to clangcpp.

• Declare function/member/variable: When you use some undeclared function/member/variable, we offer you to create a private/public/local declaration of that as appropriate.

• Rename File: When you rename a class and the file it was declared in matches the old identifier, we offer you to rename the file in accordance.

• Refactoring (libtooling): Clang provides a complete infrastructure for writing standalone tools for inspecting or manipulating code, available in libtooling. The FrontendAction class reference provides a list of readily available actions that can be performed by the frontend and which already might be useful for use once we're able to run them.

• Microsoft Windows integration: LLVM/Clang works on Windows, too. Make sure we're able to compile the Clang-based C++ language support plugin on Windows and that the Windows version is feature-compatible with the Linux version.

• Selecting standard version: Be able to define the version of the C/C++ standard (e.g. c++03, or c++11, etc.) used for parsing the source files. The C/C++ version for a specific project can be retrieved via our CMake integration or could be explicitly set by the user via the GUI.

# Final words

I'm really excited about my project and I hope to get kdev-clang into a state where it's usable by early adopters. Personally, I'm really looking forward to having a complete and working C/C++ support (including all the new C++11 features) and superb Clang diagnostics.

With these features in place, you can be pretty much sure that if KDevelop/Clang says your code is fine, then actually compiling it won't reveal any further compilation issues.

Thanks!

Hello World!

This is my very first *Amarok* specific blog post. Yay!

(Okay, admittedly I did not really blog at all since now. This will change now, of course!)

As you may know, I've been a rather semi-active Amarok contributer until now, hacking Amarok's codebase to improve the User Experience. My major *feature* contribution is the KNotify backend in Amarok (which of course is not the most crucial part of Amarok). Other than that I was mostly fixing bugs noone cared about or exceeded the patience of the average Amarok developer when trying to be solved. I think there's going to be more activity on this blog now, since I seem to get involved in Amarok more and more these days (which is exciting).

The past week I've been at Randa, the most important KDE Sprint this year, I guess.  To work on Amarok and KDE Multimedia in general. See http://community.kde.org/Sprints/Randa/2011 for hints an information about this event. The most important aspect of the meeting was the Platform 11 meeting of course, where the future of KDE with regards to Qt's Open Governance Process was discussed. This however, is not part of this blog, as I was not really involved in that discussion.

Let's talk about the work spent in Amarok land during the spring in Randa. We (mainly Mamarok and me) managed to close about 92 bugs according to her statistics. Of course most of them were duplicates or already fixed bugs by other commits. However, with a rough estimate: I think I managed to *fix* (as in: fix by committing something) about 10 more or less severe bugs and quite some other annoyances/glitches. Currently, our bug count in bugzilla (bugs.kde.org) is down to 210, an impressive good rate per LOC in open source software with a huge code base like Amarok has. This number refers to the currently open "malfunctions", e.g. no wishes or bugs marked with WAITINGFORINFO (see: https://bugs.kde.org/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=all%20open%20Amarok%20malfunctions&sharer_id=28959).

The Randa sprint has been an adventure this time which involved meeting new friends and meeting old ones. During the event Bart and me managed to work quite focussed on some issues regarding Amarok without being too distracted by other stuff. That was a really nice opportunity.

The list of commits that went into Amarok by me during the Randa sprint is listed here (42 commits during ~7days):

* e7666c2 - Minor: Fix typo in ChangeLog (2 days ago) <Kevin Funk>
* a4f56ea - Minor: Reduce header dependencies (4 days ago) <Kevin Funk>
* f716da8 - ChangeLog++ (Browser backgrounds) (4 days ago) <Kevin Funk>
* 7a39afb - Apply background images to the various browsers (4 days ago) <Kevin Funk>
* 3df0c45 - Minor: Collections: s/Counting/Counting.../ (4 days ago) <Kevin Funk>
* 83533cb - Add scripting interface for KNotify (4 days ago) <Kevin Funk>
* e43a711 - Use warning() for DEBUG_ASSERT (4 days ago) <Kevin Funk>
* 9320d5f - Pushing an example use of DEBUG_ASSERT (5 days ago) <Kevin Funk>
* 8737ace - Add another debug helper: DEBUG_ASSERT(cond, stmt) (5 days ago) <Kevin Funk>
* c8ef564 - Reset playlist error counter after match (5 days ago) <Kevin Funk>
* c4cceaf - Possible fix for crash in CV (5 days ago) <Kevin Funk>
* df9ec60 - Minor: Reformat code (5 days ago) <Kevin Funk>
* 01ed71d - Fix possible crash in VideoClipEngine (5 days ago) <Kevin Funk>
* fbbb47f - LyricsApplet: Disable scrolling when editing (5 days ago) <Kevin Funk>
* dfbf424 - Minor: Simplify some API in Albums applet (5 days ago) <Kevin Funk>
* 9aa81ce - Fix invokeMethod call to non-existent slot (5 days ago) <Kevin Funk>
* ed5448b - Minor: Remove annoying debug output (SqlRegistry) (5 days ago) <Kevin Funk>
* d21bab5 - Fix playlist tooltip getting too tall (5 days ago) <Kevin Funk>
* cb86a84 - Make equalizer keywords (dB, kHz, ..) translatable (5 days ago) <Kevin Funk>
* fbb54ff - Remove unused (+useless) PNGs from src/data (5 days ago) <Kevin Funk>
* 8098b22 - Unbreak Equalizer presets API a bit (5 days ago) <Kevin Funk>
* 471f0ac - Minor: Prettify ChangeLog (5 days ago) <Kevin Funk>
* 1170062 - Fix regression introduced by 34163f8 (5 days ago) <Kevin Funk>
* bb5c2f9 - Remove some outdated documents from docs/ (5 days ago) <Kevin Funk>
* 34163f8 - Make preset names translatable (5 days ago) <Kevin Funk>
* 66ef047 - Add script error reporting at runtime (6 days ago) <Kevin Funk>
* 34bbda9 - Minor: Improve debug output (6 days ago) <Kevin Funk>
* 82d102b - Fix "Happy" moodbar theme (6 days ago) <Kevin Funk>
* fcc420c - Fix crash by invalid scripts during stop phase (6 days ago) <Kevin Funk>
* 3157057 - Minor: Header/include cleanup (6 days ago) <Kevin Funk>
* 0406303 - Remove leftovers from a5628ac (6 days ago) <Kevin Funk>
* 6d93167 - Fix collection context menu items ordering (7 days ago) <Kevin Funk>
* f6799cd - Header cleanup starting from CollectionTreeView (7 days ago) <Kevin Funk>
* e902c44 - Minor: Rename hintlineedit(cpp|h) to HintLineEdit (7 days ago) <Kevin Funk>
* 76e9be8 - Fix strings in status bar (7 days ago) <Kevin Funk>
* 5eb2862 - Move the playlist length info into the playlist (7 days ago) <Kevin Funk>
* cae9d5a - Minor: Rearrange some code (8 days ago) <Kevin Funk>
* 8879afd - Remove outdated handbook/ directory (8 days ago) <Kevin Funk>
* 36ca680 - Remove stale OXYGEN file (8 days ago) <Kevin Funk>
* 48023de - Remove unused class ExpandingControlsWidget (8 days ago) <Kevin Funk>
* f524292 - Replace some other "LastFM" strings (8 days ago) <Kevin Funk>
* b72b933 - Fix crash when accessing The::statusBar() (9 days ago) <Kevin Funk>

PS: We (Team Amarok) also managed to win the Randa foosball cup 2011, by rocking all the other teams. Team Amarok consisted of Bart and me. Evidence can be found in the picture attached!

PPS: A nice picture collection of the event in Randa can be found here: https://picasaweb.google.com/valorie.zimmerman/RandaSwitzerlandKDESprint - Thanks to valorie for sharing and commenting all the pictures!

I just fell in love with vim ("the editor") after working for a very long time with nano. I love the way it highlights syntax, indents and copies/cuts/pastes visual blocks and stuff. But I don't like that it takes four+ key presses to save and quit a file. That has been the reason for not switching to it for me.
Now I added some key mapping to reflect nano's behaviour. If someone likes it, feel free to use it, too.

Put this in your /etc/vim/vimrc or ~/.vimrc:

" Make vim act like nano
map <C-O> <Esc>:w<CR>
imap <C-O> <Esc>:w<CR>
map <C-X> <Esc>:q<CR>
imap <C-X> <Esc>:q<CR>
map <C-X><C-X> <Esc>:q!<CR>
imap <C-X><C-X> <Esc>:q!<CR>
map <C-K> <Esc>dd
imap <C-K> <Esc>dd<Esc>i
map <C-U> <Esc>p
imap <C-U> <Esc>p<Esc>i


Save the file with ^O, leave it with ^X (leave it with ^X^X if you modified the file) and some other nice key mappings (^K for cut, ^U for uncut). Works quite well for me.
Have fun!

Just as a side note: I had to escape the HTML tags to show you this code block. http://www.accessify.com/tools-and-wizards/developer-tools/quick-escape/default.php is a nice choice for this.

An Amarok script which provides basic support for streaming your ALSA card output to Icecast (version 2 or later). It also features metadata update of the current playing track in Amarok.
Suggestions are welcome!

READ THE DOCUMENTATION FOR REQUIREMENTS, ETC.

Thank you.

I recently had enough of all the "* GMX Antispam *" lines in my kmail junk folder and tried to get rid off it. (It also marked false positivies in my incoming folder which also annoyed me).

Here's a small guide to strip the "* GMX Antispam *" string from your mail's subject (notice: this won't sort your mails in your junk folder, it only strips the subject line):

• Fire up kontact/kmail
• Go to Settings -> Configure Filters...
• Move it to the top of the list
• Rename it to something like "Rewrite-GMX-Antispam-Header"
• Now have a look at the general tab, add "X-GMX-Antispam" to the first field
• Then choose "matches reg. exp." in the drop down box
• Enter "^[2345]" in the following field (kmail will now match all mails which have been marked by the GMX Antispam service)
• In "Filter actions" choose "Rewrite header" and choose "Subject" in the next field
• In "Replace" enter "\*\*\* GMX Spamverdacht \*\*\*\ "
• The last edit field must be blank.

If you don't know how to sort mails marked as GMX Antispam into your junk mail folder:

• Add a new filter (Filter must be listed below the above filter rule)
• Rename it to something like "GMX-Antispam"
• Now have a look at the general tab, add "X-GMX-Antispam" to the first field
• Then choose "matches reg. exp." in the drop down box
• Enter "^[2345]" in the following field (kmail will now match all mails which have been marked by the GMX Antispam service)
• In "Filter actions" choose "Move into folder" and select your junk folder in the next field.
• If you like, you can also mark the mails as read immediately

I've just found a nice article about enabling DNS-Cache for Konqueror at fedorawiki.de. It's very useful, because Konqueror doesn't provide this feature. If you take e.g. the german freemail provider http://gmx.net, Konqueror sends a huge amount of dns queries to load all the pictures and stuff. You really notice the performance gain if you cache these queries with a local DNS server, for example dnsmasq.

Here are the steps to install and configure dnsmasq:

Install dnsmasq
# emerge -av dnsmasq

Then insert 'nameserver 127.0.0.1' into the first (important!) line in /etc/resolv.conf

nameserver 127.0.0.1
...

Then start dnsmasq
# /etc/init.d/dnsmasq start

You can test your local DNS cache by typing
dig google.de

Have a look at the query time (must be something higher than 50ms in most cases). Query google again.
Now that's amazing, isn't it? 0msec!

Let dnsmasq start at boot (otherwise you can't resolve any DNS names because you've edited the /etc/resolv.conf)
# rc-update add dnsmasq default

Full package name: kde-misc/kio-sysinfo

Hey, here is a new ebuild. I performed some updates (translations, etc.) on the original package. This is a testing version.

Note