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.

Users and User Research

I'd like to second Celeste's recent posts about user-research. Having watched KDE development fairly closely for a couple of years now I agree that it is why, despite many man-hours of development, some projects just aren't as useful as they could be.

A classic example for me is the story of my first patch to KDE. KDE's education suite includes a tool called KMPlot which takes a mathematical expression and plots it as a graph. At secondary school my teachers used a similar program called OmniGraph heavily. Aside from looking and feeling somewhat dated it had a raft of minor irritations which could easily be fixed with access to the code.

I wanted something similar to help with assignments at home and I found KMPlot (KDE 3.4x). I fired it up and entered a simple equation:

y = sin(x)

I was met with a somewhat cryptic error. It turns out that KMPlot required equations to be defined as named functions ( name(x) = expression ). Children at secondary schools in England don't learn about these until A-Levels, 4 years after they start playing with graphs. Whoops! My first patch fixed this by accepting "y = expression" equations and then re-writing them internally.

A more signficant problem was the interface design. A common use of OmniGraph was for teachers to load it up on their PC in a classroom which was connected to a projector. They would then enter several related equations into OmniGraph and use laser-pointers, electronic white-board pens or wooden rulers to explain the relationships between the various equations and their graphs. This environment imposes a couple of major requirements:

• Projected images generally have poor contrast. The equations therefore need to be displayed in a big colorful font so that they can be read at a distance by pupils in a classroom.


• In order to compare multiple equations and their graphs, equations need to be displayed alongside their graphs.

In KDE 3.x KMPlot only showed the graphs in the main window. Equations were hidden in a separate window and were displayed only at ordinary text size. Not difficult to fix during the design stages but really hurts its use in a classroom environment. Happily KMPlot in KDE 4.x goes some way to addressing these problems - although the interface is not as clean and uncluttered as OmniGraph. On the plus side, the graph rendering is much more attractive in KMPlot.

Finishing touches and embedded terminal improvements

The KDE 4.0 release is now very close, so I have been concentrating on fixing bugs and tidying up loose ends. Many bugs and missing menu items in the embedded terminal have been fixed in recent days.

A number of features found in KDE 3's Konsole have not been implemented to acceptable standards yet and the UI for them has been removed. Konsole/KDE 4.0 will not have:

• Session management (ie. remembering the tabs open in Konsole windows when logging out)


• Sending input from one tab to all other tabs ("Send Input to All")


• Support for terminal programs resizing the terminal window

The good news is that the embedded Konsole part became much more flexible in recent days as I fixed the context menu in the part so that it exposes features which were not previously available from the embedded terminal (in KDE 3 or the KDE 4 betas)

• Profiles, including the default profile, are shared with the main Konsole application. They can be manipulated in the embedded terminal via 'Manage Profiles', 'Edit Current Profile' and 'Change Profile' on the context menu.


• Save output as plain text or HTML


• Scrollback options and clearing

If there are any particularly annoying bugs which you want to see fixed before the release, please make sure they are filed on bugs.kde.org and add votes to them to help me prioritise them. Thanks to everyone who has been testing the KDE 4 pre-releases and a happy new year to all :)

Memory-efficient KDE 4 debugging

The GNU Debugger (gdb) is the standard tool for debugging applications on Linux. Unfortunately starting a KDE 4 application using the gdb debugger as it comes "out of the box" takes a long time (over a minute on my laptop) and uses vast amounts of memory (> 500MB) due to the time required to load the debugging 'symbols' (class names, method names etc.). This a problem especially if you have built Qt, kdelibs and other important libraries with debugging information. If you are running on a machine with less than 1GB RAM (eg. my 512MB laptop used for development) then your system is likely to slow to a grinding halt for a while.

As I discovered talking to other KDE hackers at FOSSCamp 2007, this means that some people never use the debugger at all, relying solely on debugging messages printed by the program as it runs.

One solution to this is to only load debugging information for the code which you are interested in debugging. I wrote an email on the KDE developers list about how to do that here, which was written up more clearly by Constantin here (his blog does not appear to be syndicated on PlanetKDE, so hopefully this reaches a wider audience). One important thing to bear in mind is that you can only ask gdb to set breakpoints (ie. stop execution in) functions for which debugging information has been loaded.

Manually asking gdb to load the 3-6 libraries you need to debug a given problem can be quite a hassle. What I do is to define a few functions in my ~/.gdbinit file to load commonly used subsets of libraries. In order to debug most problems, you need the core Qt,KDE and C libraries loaded plus your application code. These all load relatively quickly and won't use too much memory, so it is usually useful to load them all together. If you need to examine the state of Qt widgets or other GUI-related things then you will need to load the QtGui library. This takes a few seconds and uses a fair amount of memory so it should be avoided otherwise.

Add the following to your ~/.gdbinit file,

def load-common-kde-libs
   shar libc
   shar glib
   shar QtCore
   shar kdecore
end

def load-gui-kde-libs
   shar QtGui
   shar kdeui
end

Then when debugging a KDE application, start the application with set auto-solib-add off (I put this command inside ~/.gdbinit as well, see the linked blog most and email above) and then interrupt it using Ctrl-C. Run load-common-kde-libs and then load any libraries specific to your application, usually shar <appname> will catch them. In many cases, this will be enough information to get useful backtraces (using bt) and examine the state of the application. If when you run the bt command the backtrace includes calls to functions inside the QtGui,kdeui or other libraries near the top before the calls to functions in your application's code then you will need to load those as well and then re-run bt in order to find out where in your code the problem is.

As mentioned on the KDE TechBase page, there is a script in SVN (trunk/KDE/kdesdk/scripts/kde-devel-gdb) which includes really useful gdb functions for debugging KDE applications, such as printq4string (prints the contents of QString objects) and identifyq4object (prints the class name of an object which inherits from QObject).

Other KDE debugging tricks

• Stepping through an application which was built with compile-time optimization enabled (the default) can produce some really weird results because during compilation, the structure of the code may be altered and variables or function calls can be removed ('optimised out') to improve performance. Optimizations can be disabled by passing -DCMAKE_BUILD_TYPE=Debug to cmake when setting up the build. The resulting programs will run more slowly, depending on how much of the Qt/KDE library stack is built without optimisations (in my case, everything from Qt and up is).


• Some applications in KDE (eg. dolphin, konsole) are single-instance, which means that there is only ever one process for that program. If you start a second copy of that program then it contacts the first, asks it to create a 'new instance' (usually this means a new window) and then immediately quits. Applications which are single-instance support the --nofork argument to prevent them from creating a new process on startup. You can find out whether an application supports this by looking at the output of appname --help-kde. If you are debugging such an application, you need to run it with the --nofork argument. In gdb you can do this by executing set args --nofork before running the program.


• Some KDE components (eg. plasma) have their own crash handlers to trigger an automatic restart or bring up a specialized bug reporting tool (eg. amarok) in case of a crash. These custom crash handlers interfere with normal debugging, and they can be disabled by passing the --nocrashhandler argument on startup (like the above --nofork).

Over the Christmas period I hope to find time to write this up on the KDE TechBase page. Please try out the above and reply to this post with any problems/comments/queries so I can include the answers when I get around to it.