So, as looking that everyone is in the hiring mode...

Yes, Collabora is hiring. So if you are passionate for open source, want join a company that share the same passion as well, want to work from any place in the world and have at least some of these skills below, then we want to know you.

• KDE
• Qt
• Qml ( Qt Quick )
• C++
• WM and Graphics(3D, GL/GLES, X, Mesa) as a plus

Consider yourself a serious KDE hacker? Don't be shy, we want to know you too ! KDE is an important part of our lives now.

Then, what are you waiting for ?
Share your hacking ninja code skills contacting us at our hiring info channel, also known as email :-).

A couple of large commits changed the organization of the Strigi project. As you probably know, Strigi provides the code to extract data from files and also allows for fast searching for files. We have reorganized the project to be a meta project. It is now split into five projects that can be compiled independently: libstreams, libstreamanalyzer, strigidaemon, strigiclient and strigiutils. This move has been done to make it easier for other projects to use the library parts of Strigi. KDE, especially Nepomuk, depends on libstreamanalyzer, which in turn depends on libstreams.

This reorganization has brought along a big cleanup of build files in the project. The resulting libraries and executables are essentially the same as the are in last release: this reorganization just moves the files and changes the build system the libraries more pronounced. Especially the Tracker developers should benefit from this move. They have requested a way to use libstreams and libstreamanalyzer without needing to use the rest of Strigi.

The versioning and release schedule of the five Strigi components will stay the same. The next release will come as a big tarball and as five small tarballs. To get all five parts, run

svn co svn://svn.kde.org/home/kde/trunk/kdesupport/strigi

To get just the libraries run

svn co svn://svn.kde.org/home/kde/trunk/kdesupport/strigi/libstreams
svn co svn://svn.kde.org/home/kde/trunk/kdesupport/strigi/libstreamanalyzer


We are now considering how to best move the project to git.

I leave you with a picture of one of my chickens and a link to a nice Summer of Code idea.

Shocked by the title? So I am.

Would you like to see Qt supported on this platform? Just two days ago the answer was like "But it's close to impossible".
Now with NDK 1.6 the "little robot" OS opens more to C/C++ native code. I am eager to read some analysis on the topic.

Well it is officially the end of GSoC. This update brings you the wrap-up of what happened in the project, what got done, what didn't get done, and what is next on the wonderful world of automated code Refactoring in C++.

What Got Done

The week before last into GSoC, and this is how things are:

Sadly I had very little time to work on the project last week because I had to be out of town for the most part. Despite of this setback though, there was a significant improvement, which is the user review widget. What this means is: Screenshot time!

Here is another update on the progress of the KDevelop refactoring support SoC.

Last week was pretty hectic for me. Sadly I didn't have as much time as I would have liked to work on the project, and even less to blog about it. However with this update I will list things that have happened these past two weeks. Among things that happened:

Another week into SoC, and status update for anyone mildly interested :)

So what has happened in the last week? Well I worked in the KDE hacking rooms at Akademy :).

So what's the holdup? Where is all the cool stuff you promised?

Hello everybody, I should introduce myself first: I am Ramón Zarazúa, I am a GSOC student working on C++ refacoring support for KDevelop. I am very pleased to be contributing to KDE and the community, and want to make us the best we can be!

State of things:
To be honest things are not going good :( For lots of different reasons progress has been stagnant on the project. There have been changes in the plan, and now focus will switch to do refactoring on a more textual level (instead of the initially planned purely conceptual level). I am currently working on the refactor framework, and a refactoring concept to "make a class implementation private" or as it is known in QT and KDE: the 'd' pointer.

Yes, sounds strange. Why should i did it ?
Well, first is known among the distros that qt-creator in first release is not the most friendly to packaging.
Not only beacuse qmake, but because some distros rely on things like splitted packages or 32/64 bits coexistent libs and plugins.
Second, was quite a challenge for me do this, because i need to learn some new tricks ( thanks dfaure for automoc4 help ).
Third, dressing my packager hat, i would love to see qt-creator been in the main Mandriva distro, compliant with our policies, and been adopted as well i expect for kdevelop4 when be released. Qt Creator is one of the amazing IDE's around and i thought that worth the effort to give some love in buildsystem to have it in a full Mandriva way, including our flags and standard cmake build.
During the process, i could manage to fix all bugs open in our bugzilla about packaging, and at same time enable the "most wanted" feature here, the designer plugin, which for some reason was not enabled in our qmake previous compilation.

To summarize what i did:
- Write whole cmake buildsystem
- Backported icons and mime and desktop files from upstream binary Qt Software package ( as same as Kubuntu did )
- Make the plugin standard dir be the Qt plugins standard dir, which make possible have 64 and 32 bits plugins instalable
- Make qt-creator easily compliant to /usr linux install
- Splitted libraries in subpackages as usual, and installed in our standard libdir instead of a subdir
- Reenabled designer plugin.

So, now i'm totally happy with all the changes, barely minimal in code ( most moc include additions and add standard Qt plugin path ).

For who is interested, our svn repository is Qt Creator Package Repos
For who wants to try our marvelous distro, today we will be releasing RC1 from Mandriva 2009 Spring, so you will be able to see how hard we are working to make a better distro for you...

So, the last two days I've been concentrating on introducing locking into the definition-use chain which I've been writing for KDevelop. I've taken quite a coarse-grained approach, with one lock for each document's chain, and with separate object local locks each time that an object can reference another object that is on a different chain.

It took several hours yesterday to complete the basic scheme where the chains weren't referencing each other. I didn't even realise they weren't referencing each other until later, when I recognised that a speedup commit that Matt had contributed had removed some of my code which made this happen before. In fact, it was fortunate, because it allowed me to develop the code in two steps.

So today I've been trying to make the chains play nice while referencing each other. The going hasn't been easy. First I was confronted with some more unprotected accesses - these aren't too hard to fix, thanks to an extensive assert system that I've put in place to detect when locks aren't being held that should be. Second, there was a deadlock in the code completion code which took a little while to figure out - note to anyone using QReadWriteLock: if you ask for a second read lock while someone else is asking for a write lock, you'll deadlock. Third, I hit a race inside katepart where text edits and smart range updates could occur simultaneously, which was also bad. That wasn't too hard to fix. Now, I'm cleaning up some access of deleted memory with the help of Valgrind.

I'm not sure that this code can even be made to be reliable, given its complexity. Adam Treat pointed me at an article recently, The Problem with Threads, and I'm starting to agree. Having multithreaded definition-use parsing and manipulation would be a good goal, but perhaps not more than being stable. So, I plan to give it some time in svn to see if it can be made reliable enough for kdevelop's purposes.

In other news, my latest hardware purchase arrived today - a Dell 30" flat panel screen. At 2560x1600, when you combine it with another large screen (I have 2x 24" already, at 1920x1200), my graphics card can't handle them in xinerama mode, as the virtual screen size maximum is 4096x4096. So, I've been trying it in separate screen mode, but it's not a particularly pleasant setup - problems including the loss of ability to alt-tab between screens, kicker popping up on the other screen to the one that you're working on (and crashing), and of course not being able to drag apps between screens. Anyway, the 30" screen is excellent quality. I took a photo but it doesn't do it justice at night time...