Introductions and the future of Konsole

Hello,

I have been maintaining KDE's terminal program ( Konsole ) since August last year. I'd like to give a brief overview of what is happening for KDE 4. I spent some time triaging bug reports, and talking to KDE users and developers at aKademy to get an idea of what people would like to see in the future. From this I have defined a few goals for the KDE 4.0 release:

- Make it easier to work with many terminal sessions open ( this means navigating between sessions, monitoring activity in sessions etc. )
- Better performance ( mainly when scrolling large screens of output, and also quick startup )
- Make the configuration of Konsole more intuitive

Good progress is being made on the first two of those goals, mostly in the branches/work/konsole-split-view branch in SVN.

As the branch name says, the major feature is the ability to split the view top/bottom so you can, for example, write code in Vim or Emacs in the bottom view and watch the result of a compilation in the top view. Views can be detached and reattached (via a "Merge Windows" option which merges all the open Konsole windows into one). In order to allow views to be moved between windows, I rewrote the front-end as a single-instance application. The KDE libraries make this extremely easy to do. This means that if you launch say, a couple of Konsole windows from the panel, another from the K-Menu, and perhaps another from a shell script, they will all be part of the same process ( plus secondary windows open instantly and less memory is used ).

Split-view screenshot (navigation area not shown)

A much more experimental feature I am playing around with is abandoning tabs and using a list at the side of the window. A little like Kate. The problem with tabs is that they are not very expressive, with only a small amount of text and a tiny icon. Web pages often have sensible titles and associated icons, so this isn't such a problem, but terminal sessions don't. Lists allow the possibility of providing arbitrary information to help users monitor activity in various sessions, and also perhaps using colours or images to make it easier to locate a particular session in the list quickly. The obvious downside is that they consume horizontal space. It is also important to avoid the temptation to go overboard and put too much distracting information there. I want Konsole to feel 'clean' and 'simple', despite its feature set.
It is easy (in the code) to switch between using a list or using tabs, so if the experiment does not work out, or users don't like the change, I can go back to tabs.

A number of backend changes have been made to improve performance. In KDE 3, every time Konsole scrolls the display up one line, it has to move 40KB of data in memory (for a default-sized window) because the screen image was held in one array. In KDE 4, lines of output are stored as reference-counted vectors, so moving the display up one line just involves adjusting the array which keeps track of which vector goes with which line. A side benefit of this is that if you resize the Konsole window to make it smaller, and then make it larger agan, output is not lost as it is in KDE 3. The change which makes the biggest difference for day-to-day usage on large displays is that in KDE 3, every time the display is scrolled, the entire terminal view is repainted from scratch - which involves lots of computationally expensive text rendering. In KDE 4, the emulation gives hints to the view about how the image has been transformed since the last display update, and the view can use this to achieve the same result in a cheaper fashion (eg. using the standard widget scrolling mechanism instead of repainting every line when you scroll up or down one or two lines).

KDE 4 is still a long way from release, so there is a "new" KDE 3 feature to keep the 'candy whores happy ;). KDE 3's Konsole has a compile-time option to enable true-transparency. This is not very convenient because you have to recompile the code yourself to get the effect. So for KDE 3.5.7 it has been made into a command-line option, accessible like so:

konsole --real-transparency

This is not enabled by default because I need to find a reasonably reliable test for a compositing manager, and also because UI changes are necessary to allow users to choose between fake and real transparency ( yes, there are plenty of users who prefer the "fake" system used at present ) - that will probably have to wait until KDE 4.