Randa Report: Hacking on KDE and meeting friends

Hey there,

I'm already back home and now like to you let you know what I've been doing the last week during the Randa Sprint in the Swiss Alps.

Quick summay: It has been an immense event!

View from our hacking room, in Randa, Switzerland

Last week I've been mostly occupied with porting KDevelop to KF5 and, part of that, succeeded in making it compile and run on Windows as well. In between the hacking sessions, we had a lot of fruitful discussions which concerned the future of KDevelop and the whole KDE SDK itself. Let me break that down into the individiual tasks accomplished throughout the week.

Report

Day 1 (Sat, 9th August)

Arriving to Randa, Switzerland at around afternoon. Meetup with all the KDE fellows scattered all around in the house.

Clang integration: C++ Macro navigation support

In the afternoon I was working a bit on tasks from kdev-clang (my GSoC project this year), which I wanted to get fixed first. So, I managed to bring back basic C++ Macro navigation support in our plugin (I'll explain the implementation details / shortcomings in another blog post).

KDevelop screenshot
KDevelop showing the uses of a macro definition when hovering the macro identifier and pressing "Show Uses"

Resolving inter-library dependencies in kdevplatform

Another largish patch landed in kdevplatform.git this evening: Splitting up the huge kdevplatformlanguage library (which contains all the language agnostic Definition-Use-Chain logic) into more managable parts. I've factored out the part that provides the infrastructure for serializing the DUChain items, and created kdevplatformserialization, which now contains all the classes required for writing your own (serializable) item repository.

This change resolved a few issues with inter-library dependencies we had in kdevplatform. This also helped making kdevplatform compile on Windows in the end.

Day 2 (Sun, 10th August)

More porting of kdevplatform to KDE Frameworks. Mostly fixing up CMake-related code in order to be able to compile tests using new CMake macros (ecm_add_test). Pushing a few compilation fixes for Windows for both GCC and MSVC.

Day 3 (Mon, 11th August)

Fixing up unit tests in kdevelop/kdevplatform using the frameworks branch. Also fixing a few crashes that popped due to changed behavior in Qt5 (mostly event-handling related).

Day 4 (Tue, 12th August)

Switch Declaration/Definition feature in kdevplatform

Moving support of the "Switch Declaration/Definition" feature (something you can trigger via the menu or via the "Ctrl+Shift+C" shortcut) to kdevplatform. That in turn means, that any language (well, any language which disambiguates between definitions and declarations) can make use of this feature without further work. Of course, the main motivation was to get this working for kdev-clang. Review-request here: https://git.reviewboard.kde.org/r/119648/

Basic Objective-C support in kdev-clang

Later that night, Alex Fiestas and me got into philosophical discussions about the Clang integration in KDevelop and suddenly the question about Objective-C support popped up. Realizing that we didn't ever look into that (despite being very well aware that Clang supports it), I decided to spent an hour on it in kdev-clang to see some first-hand results.

You can see the patch here. As you can see, this is mostly about making our Clang integration aware of Objective-C entities in the Clang AST. It's that trivial.

And here the result:

KDevelop screenshot
KDevelop providing basic support for the Objective-C language"

Note: If someone is interested in driving this further, that'd be greatly appreciated. Personally I won't have time in the near future to extend the Objective-C support (also, I don't do Objective-C these days, so I don't have a use for it)

Day 5 (Wed, 13th August)

Fixing up the Grep Dialog in KDevelop (frameworks branch). There were some issues with event-handling in KComboBox and default selection inside the dialog button box. In the end, I decided to port this over to QDialog and QComboBox right away and fixed up both issues during that.

Another major issue for KDevelop on Windows got fixed this day: Windows path handling in our custom QUrl-replacement class KDevelop::Path: We now also support Window's single-drive letter based file schemes (e.g. C:\tmp) here. That fixed include path / include lookup on Windows.

Day 6 (Thu, 14th August)

Attempting to fix hang-on-exit issue in KDevelop

This day, I was mostly spending (read: wasting) time attempting to fix the most apparent issue in KDevelop (frameworks branch): KDevelop not exiting cleanly when asked to be shutdown. I'm still not exactly sure what's wrong, but it seems like some object is not calling QCoreApplicationPrivate::deref, and hence the event loop is not being quit when the last window is closed (because QCA still assumes to be in use, i.e. the refcount being non-zero)

tl;dr: I'll keep you posted as soon as I find out what's wrong here.

Daytrip time

Thursday afternoon a whole bunch of the KDE fellows made a great day trip to get a closer look at the wonderful Matterhorn. For this, we got to Randa by taxi and got the chance to walk around in the (admittedly very touristy) town Zermatt. After a few minutes of walk, we got to see this amazing view of the Matterhorn:

View to Matterhorn from Zermatt, Switzerland

Day 7 (Fri, 15th August)

After a good week of productive hacking and meeting friends in the Swiss Alps, I left Randa very early in the morning by train towards Zurich, for my flight back to Berlin.

Discussions

It has been a highly productive week this time. The team had a lot to discuss about future ideas that concern both KDevelop and the KDE SDK as a whole.

Interesting topics we've mentioned, which were directly related to KDevelop:

Improving the dashboards inside KDevelop: We'd like to introduce a session-specific dashboard that shows information about the currently loaded projects, such as recent commits, recent bug entries, latest mailing list entries, etc.

Reducing the ramp-up time needed for newcomers: We want to make it easier to download/build/run applications, and make it easier to contribute back patches to reviewboard for newcomers. Part of that we'd like make it easier to fetch dependencies of a particular KDE project, so the developer really doesn't need to worry too much about setting up his/her environment. We (the KDE SDK team) planned to improve kdesrc-build in a way it can be used as a backend for handling all this.

We also had a bunch of non-KDevelop related discussions, let me briefly summarize them:

  • The KF5 book is coming along nicely, and lots of people have been involved into making it shine
  • The KDE apidocs site got some love and looks much better now
  • (a lot more)

Summary

Thanks for making the event happen, thanks to all the donors for this year's Randa fundraiser! As always, it's been an terrific event, a super productive week altogether.

Thanks a lot to Mario Fux and his family/friends for organizing and keeping us happy during the event.

GSoC Status Report: Code Completion features

Context: I'm currently working on getting Clang integration in KDevelop into usable shape as part of this year's Google Summer of Code. See the initial blog post for my road map.

While we had basic support for code completion provided by Clang from the beginning (thanks to David Stevens for the initial) work, it still didn't really feel that useful in most cases. In the last two weeks I've spent my time streamlining the code completion features provided by Clang.

This blog post is going to be full of screenshots showing the various features we've been working on lately.

Task recap: Code completion

  • Code completion: Implement “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 attempting to #include some file, port this to clangcpp.

Achievements

Virtual override completion

Simple case

When in a class context, we can now show completion items for methods that are declared virtual in the base class.

KDevelop screenshot
KDevelop showing the "virtual override helper". By pressing Ctrl+Space inside the derived class, KDevelop will propose overriding virtual functions from the base class

By pressing Enter now, KDevelop automatically inserts the following code at the current cursor position:

virtual void foo()

Oh, no! Templates!

We've spent a bit of work to make this feature work with templated base classes, too. Have a look at this:

KDevelop screenshot
KDevelop showing the "virtual override helper". KDevelop knows the specialized version of the virtual method in the base-class and proposes to reimplement it

Nice, right?

Implement function helper

When encountering an undefined method which is reachable from within the current context, KDevelop offers to implement those via a tooltip

KDevelop screenshot
KDevelop showing the "implement function helper". By pressing Ctrl+Space in an appropriate place, KDevelop offers to implement undefined functions (this also works for free functions, of course)

By pressing Enter now, KDevelop automatically inserts the following code at the current cursor position:

void Foo::foo()
{
}

This works for all types of functions, be it class member functions or free member functions and/or functions in namespaces. Since this is mostly the same code path as the "virtual override helper" feature, this plays nicely with templated functions, too.

"Switch to Definition/Declaration” feature

Sorry, no pictures here, but be assured: It works!

Pressing Ctrl+, ("Jump to Definition") while having the cursor on some declaration will bring you to the definition. Consecutively, pressing Ctrl+. ("Jump to Declaration") on some definition will bring you to the declaration of that definition.

Show viable expressions for current context

Best matches

KDevelop screenshot
KDevelop showing completion items when calling a function. KDevelop offers all declarations that are reachable from and useful for the current context. In addition to that, best matching results are put to the front. As you can see variable str gets a higher "match" than variable i.

This is some of the features we actually get for free when using Clang. We get the completion results by invoking clang_codeCompleteAt(...) on the current translation unit and iterating through the results libclang is offering us. Clang gives highly useful completion results, the LLVM team did an amazing job here.

Another example: Enum-case completion

KDevelop screenshot
KDevelop showing completion items when in a switch-context and after a 'case' token. KDevelop is just offering declarations that match the current context. Only enumerators from SomeEnum are shown here.

You can play around with Clang's code completion ability from the command-line. Consider the following code in some file test.cpp:

enum SomeEnum { aaa, bbb };

int main()
{
    SomeEnum e;
    switch (e) {
    case 
    //   ^- cursor here
    }
}

Now do clang++ -cc1 -x c++ -fsyntax-only -code-completion-at -:7:9 - < test.cpp and you'll get:

COMPLETION: aaa : [#SomeEnum#]aaa  
COMPLETION: bbb : [#SomeEnum#]bbb  

Awesome, right?

Issues: Too many code completion result from Clang

One thing I've found a bit annoying about the results we're getting is that Clang also proposes to explicitly call the constructors/destructors or assignment operators in some cases. Or in other words: It proposes too many items

Consider the following code snippet:

struct S
{
    void foo();
};

int main()
{
    S s;
    s. 
    //^- cursor here
}

Now doing clang++ -cc1 -x c++ -fsyntax-only -code-completion-at -:8:7 - < test.cc results in:

COMPLETION: foo : [#void#]foo()  
COMPLETION: operator= : [#S &#]operator=(<#const S &#>)  
COMPLETION: S : S::  
COMPLETION: ~S : [#void#]~S()  

Using one of the last three completion results would encourage Clang to generate code such as s.S, s.~S or s.operator=. While these constructs point to valid symbols, this is likely undesired.
Solution: We filter out everything that looks like a constructor, destructor or operator declaration by hand.

So, in fact, what we end up showing the user inside KDevelop is:

KDevelop screenshot
KDevelop showing completion items after a dot member access on the variable s. KDevelop is just offering useful declarations, hiding all undesired results from Clang.

Just what you'd expect.

Wrap-Up

Code completion features are mostly done (at least from the point-of-view of what Clang can give us here).

Still, there other interesting completion helpers that could^Wshould be ported over from oldcpp to kdev-clang, such as Olivier's lookahead-completion feature (which I find quite handy). This is not yet done.

I'm writing up yet another blog post which is going to highlight some of the other bits and pieces I've been busy with during the last weeks.

Thanks!

Wrap-Up: Issues with QExplicitlySharedDataPointer (KSharedPtr successor)

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

GSoC Status Report (Week 2): Moving Assistants Infrastructure

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:

KDevelop screenshot
KDevelop showing the rename assistant when attempting to modify some identifier. By pressing Alt+1, the first action is selected and foo in line 4 will be changed to foo1

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:

KDevelop screenshot
KDevelop showing a hint provided by Clang diagnostics (problem here: missing semicolon at the end of the line)

or this little guy here:

KDevelop screenshot
KDevelop showing a hint provided by the missing-include-resolver assistant (problem here: unknown type)

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!

Here's the link: http://www.kde.org/fundraisers/randameetings2014/

Thanks!

GSoC 2014: Improving the Clang Integration in KDevelop

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

KDE's Konqi and Clang's wyvern -- best buddies?

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
KDevelop screenshot
KDevelop showing code completion items for a `std::string` inside a `std::vector`
  • Support for Clang diagnostics [implemented by me]
  • Support for Clang fixits (they are the solution approaches to common errors) [implemented by me]
KDevelop screenshot
KDevelop showing a Clang diagnostic and fixit when encountering a parse error

Open Tasks

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.

Other tasks

  • 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!

I'm going^W^W I went to Randa

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!

Make vim act like nano

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.

Amarok ices script interface

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.

Get it here: http://kde-apps.org/content/show.php?content=72434

Thank you.

HOWTO Remove GMX Antispam Header from mails in kmail

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...
  • Add a new filter
  • 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

Enabling DNS cache with dnsmasq on Gentoo

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

Further reading
http://ubuntu.wordpress.com/2006/08/02/local-dns-cache-for-faster-browsing/