We're hiring Qt developers

I'm currently working for Mendeley, a startup based in London. We're building software for organising, reading, annotating and collaborating on research papers (mostly in PDF format) which integrates with an online network for researchers. We're currently looking for developers to join the team working on our Qt-based desktop application for Windows, Mac and Linux.

Essential skills are:

• Knowledge of C++ and experience debugging, testing and profiling C++ applications.


• Experience with Qt. If you're the kind of person who likes delving into the internals of Qt that's even better.


• Solid computer science basics.

Knowledge of any of the following would be particularly useful:

• Model/view frameworks (especially Qt's implementation). An interest in or experience with some of the upcoming Qt technologies (eg. Qt Quick) would also be a plus.


• Databases (in particular, SQLite)


• Search/indexing frameworks (eg. Lucene)


• Scripting languages (eg. Python, Ruby)


• Version control (SVN, git).


• Automated testing tools (eg. QtTest).


• Knowledge of platform-specific APIs such as Cocoa on Mac*.

Involvement with open source projects is a big plus. Dog fooding your own software is always helpful, so if you have a background in research or even just like reading papers to find out how things work, that would also be useful.

If you're interested, please get in touch.

* Though Qt abstracts away most platform details, there are times when using native APIs is necessary.

Konsole under Jaunty

As noted in several places, some applications feel somewhat sluggish in Ubuntu Jaunty compared with Intrepid if your system has an Intel graphics card.

There isn't a great solution for X in general yet - some options involving X.org tweaks and replacement X packages are discussed here

Applications which render a lot of text seem to be affected quite a bit. For Qt applications there is a simple workaround, in Konsole the workaround makes tab-switching much more snappy. Start Konsole with the raster graphics mode:

konsole -graphicssystem raster

This also works wonders on the Mendeley Desktop research management software which I work on.

Konsole scrolling weirdness

Some users are experiencing weird visual glitches when scrolling in Konsole. The problem isn't trivial to debug but until it gets fixed there are a couple of workarounds:

• Un-hide the menu bar if it is hidden
• Set the QT_USE_NATIVE_WINDOWS environment variable to '1' before starting Konsole (export QT_USE_NATIVE_WINDOWS=1)

Slow on NVidia?

If you have an NVidia graphics card and Konsole in trunk seems very slow in a composited desktop (eg. KWin 'desktop effects' or compiz are enabled) then start Konsole with the --notransparency option. Intel/ATI are not affected.

I do not know the cause of the problem, I'll post an update when I find out.

Singing in tune

Sebas, Tom and Aaron discuss a regular 6 month release cycle. This was first brought up in Mark Shuttleworth's keynote at Akademy 2007. The relevant section starts around 30:00 and in the questions at 42:00. There was more to his argument than just "release every 6 months". The exact time delay was a detail, albeit an important one. For the benefit of those who weren't there and perhaps also those who were, I'll summarize his points:

• Regular, predictable releases which are synced with appropriate other projects provide a sense of rhythm and structure. It allows projects up/down and across-stream to plan better and co-operate more efficiently.
• If distributors believe they can trust KDE's release schedule and release quality then they will allow a smaller safety margin between the time KDE makes a release and the time when distributors need to ship their next release. Consequently, new releases will get to users faster and hence feedback from recent developments will get back to developers faster. Gnome already benefits from this trust.
• Getting the release out is the most important feature.
• It would be wrong for KDE to specifically pick a distribution to sync with. Instead pick a date which 'conveniently' matches that of other software at the same level in the stack. This synchronization may be explicit or it may be "coincidental" (if arranging and publicly announcing such co-operation is unpalatable for whatever reason)
• Regular time-based releases are much easier if features can be landed when they are complete, so that the primary work going on in trunk is integration, as opposed to dividing up the 6 months into slots of X months feature development, Y months bug fixing, Z weeks releasing. The kernel developers have proved that this approach can work.
• The regular cycle may have to be suspended for big backwards-compatibility breaking upgrades (KDE 4)
• The value of synchronization is sufficiently high that it may justify re-arranging the structure of a big project to accommodate it.
• The time delay is subject to debate. Ubuntu found that 6 months works well for them because, for example, it divides evenly into a year so holidays etc. can be planned around it. The appropriate delay depends on where a project is in the stack and what its up/down and across-stream are doing. Further upstream projects can generally get away with a shorter delay because there is of the buffer provided by downstream.

From what I recall, there was a general consensus amongst attendees in favor of the idea - which left the details to sort out. My personal experience with large projects is limited but I think the above arguments are good, particularly the key first point and the evidence from projects which have tried to follow this approach is positive on the whole.

Magic Trick

Magic trick for Kubuntu users:

1. Make an empty new directory ~/.compose-cache
2. Start a KDE application which has a text input widget (anything with a line edit or editable combo box will do)
3. Check ~/.compose-cache, it should now have a file in it whoose name is a long string of numbers

All being well, your Qt/KDE/Gtk applications should now start up 50-150ms faster.

Users of other distros are welcome to give it a try, I have only been able to test directly on Kubuntu. If you have a non-empty /var/cache/libx11/compose folder (eg. SuSE users) then this optimization is already enabled so you don't need to do anything.

For those curious about what is going on here, this enables an optimization which Lubos (of general KDE speediness fame) came up with some time ago and was then rewritten and integrated into libx11. Ordinarily on startup applications read input method information from /usr/share/X11/locale/<your locale>/Compose. This Compose file is quite long (>5000 lines for the en_US.UTF-8 one) and takes some time to process. libX11 can create a cache of the parsed information which is much quicker to read subsequently, but it will only re-use an existing cache in /var/cache/libx11/compose or create a new one in ~/.compose-cache if the directory already exists.

Relevant freedesktop.org bug report

Konsole - KDE 4.1 Changes

I had a few emails recently asking for a summary of changes in the terminal and in particular 'Send Input to All' which was missing from KDE 4.0. So here are the changes in 4.1, in addition to the many bug fixes and tweaks.

• Copy Input To dialog allows input to one session to be copied to all or a subset of other sessions. (Like 'Send Input to All' in KDE 3 but more flexible)


• Drag and drop re-arrangement of tabs and movement of tabs between windows.


• Better warnings and fallbacks if starting the shell fails (due to missing binary or crash).


• Transparency is available by default (with an option to forcibly disable it)


• Support for bi-directional text rendering. (Diego Iastrubni)


• New 'Dark Pastels' colour scheme (adapted from one by Christoffer Sawicki)


• Mouse-wheel scrolling in less and other non-mouse enabled terminal applications

Nothing ground breaking here but it should make KDE 4.1 a nice step forwards from KDE 3.5 for those who have stayed away from KDE 4.0.

In other news, like several other KDE developers I have started using git and git-svn locally. It is a huge improvement over SVN, especially when developing experimental features that touch many parts of the code alongside bug fixes to the current trunk. It does make you wonder how you ever managed before. A quick "git branch" on my current local checkout shows 10 branches for various little features in progress, for example:

custom-pty-fd
image-background
inheritance-ui
* master
port-to-mono
profile-editor-binding
profile-editor-improvements
window-tab-settings

Interestingly though and perhaps paradoxically given the open nature of the project, one of the most useful benefits is the ability to create branches to work on features without telling the whole world. There is much emphasis on the benefits of incremental development but at the same time I think it is important to be able to do some things in private so that they can arrive on the scene with a bang that gets attention. Compiz or git being good examples.