Easter holiday terminal update

Quite a bit of progress in Konsole over the Easter holiday, summary of the best bits:

• Began a re-write of the Konsole Part. Under KDE 3.x, the Konsole part and the main application duplicate a lot of code, and much of the functionality in the main application is not available in the part. The goal is to keep the Part and application specific portions of the code much smaller in KDE 4. This should make maintenance easier and also make many/most of Konsole's KDE 4 enhancements and new features available in Kate, KDevelop, Dolphin, Yakuake etc. using the part.


• Implemented a Yakuake-style 'background mode' for Konsole. This means that a shell session is started in the background, which can be displayed or hidden instantly from anywhere by pressing a global shortcut ( currently hardcoded to F12, but eventually customisable ).


• Improved the bookmark system. When creating a new bookmark, Konsole now chooses the working directory of the foreground program instead of just using that of the main shell (Useful if you nest shells or are running any interactive program in the shell) If the foreground program is SSH, this saves the current user and host as a special SSH bookmark. Oh, and I added 'Bookmark Tabs as Folders' support.


• Allow the user to choose which custom sessions are shown in the main menu.


• Allow the user to split the view left/right ( in addition to top/bottom ) and support as many views open at once as the user wants. Screenshot


• Began work on the Konsole settings replacement.

So getting closer to merging the branch back into trunk for everyone to play with. I will do that once it is capable of creating new custom sessions and saving / loading the settings of session types.

Thanks also to everyone, all 8000+ of you, who took the time to complete the Konsole survey. Your feedback is much appreciated. I have summarised about 2/3rds of the results ( available here ) so far, and already this week I implemented a number of changes based on the results ( Background mode, SSH bookmarks ). There were many kind words for the developers ( past and present ), always appreciated :)

Konsole Survey

One of the areas of Konsole which I really want to give a little love for KDE 4 is the terminal setup ( terminal features, colour schemes, display options, character encoding etc. ) and creation of profiles for different types of terminal.
To get a better idea of what users need from their terminal, I have set up a survey. There are 28 questions, all optional, and opportunities for additional comments at the end. Aside from helping me to understand how you use and set up your terminal, this also gives you a chance to prioritize a few features for KDE 4.
Please help improve Konsole by telling us about your needs and preferences. Completing the survey should only take 5-10 minutes of your time. Thank-you in advance.

Konsole Usage and Preferences Survey

On the subject of surveys, I had difficulty finding a good PHP-based survey system to use. I used phpESP in the end, but recommendations about alternatives would be welcomed.

Thanks to seele for checking the questions and spotting a few problems.

The current roadmap is to implement the new terminal setup facilities in the next month or so, and then merge the development branch into the main KDE 4 trunk. After much tidying up of loose ends, it will be ready for the feature freeze in June.

Konsole progress - Searching the history

The "Search History" feature has undergone some changes for Konsole / KDE 4. It now uses an incremental search bar in the same vein as Firefox.
Pressing Ctrl+Shift+F ( or using the menu item ) brings up the search bar. Typing in a search term jumps to the first match and highlights all matches in the currently active window. I have seen similar features introduced or improved in other KDE applications for KDE 4. Currently I believe they all use different implementations of the search bar. Ideally we could unify at least some of them.

As well as searching large blocks of text, this is a convenient way to highlight blocks of text on screen matching given patterns. Typical examples include highlighting errors in compiler output or matches for part of a file name.

Under the hood, the searching of large histories ( particularly when using unlimited history ) has been optimized. History saving now uses the ioslaves mechanism which allows saving over SSH, to remote FTP servers amongst others.

Screenshot of new history search (Please note there are some problems in this shot that I am aware of: Main menu items in the wrong order, 'Debug' menu item, not using the session name in the window title etc.)

It has been suggested that "History" should be renamed to "Scrollback" in KDE 4 to avoid confusion with the command history which is maintained by the shell program and typically accessed via the Up/Down arrows. Opinions on this would be welcome.

Other notes, in no particular order:
- Having received much feedback on my first Konsole post, I am using tabs as the navigation mechanism for the time being, unless I can resolve the problems with the other approaches. I also received some help on getting information about the foreground process in the session which I hope to use to enable more helpful tab titles by default.
- This work is being done in a separate branch as I mentioned earlier. Before merging back into trunk, I need to research/design/implement the new Konsole settings system and fix some outstanding issues with split views.

Making KDE 'cleaner' - Removing frames

The recent Linus-Gnome scuffle has resulted in some interesting comments by various users about the reasons behind their preference of Gnome or KDE as their main desktop. One of the opinions which seems to be common amongst gnomes is that the user interfaces of KDE applications tend to feel more cluttered in comparison to their Gnome counterparts.

I can think of several reasons for this, but there are some aesthetic problems in KDE applications which are fairly easy to deal with, and they do make a noticeable difference. So it is worth fixing them.

Something that was picked up in comments to various kde-look.org mockups for KDE 4 is that they look clean in part because they don't have many of the ugly frames and borders which litter KDE applications at present.
The majority of these frames and borders are not deliberately put there by application developers, they arise as a by-product of the way in which the user interfaces are constructed. For example, a tab widget is created, which is filled by a list box. Both the tab and the list box have borders by default, and so the on-screen effect is an unpleasant double-thick pinstripe border. KDE 3's default Plastik style makes this worse because it uses thickish 3D borders for quite a number of user interface elements. Gnome's aptly-titled Cleanlooks has thinner, less visually pronounced borders for many elements, which helps somewhat.

Removing these borders is, for the most part, easy to do.

Below are a couple of screenshots of Akregator. The first is the KDE 3.5.5 out-of-the-box screenshot. Both the list box containing the list of feeds and the article viewing area have borders around them. The second has both of these removed.

Akregator (KDE 3.5.5)
Akregator (patched to remove frames)

One persistant offender is Qt's tab widget. It has a border around it which I have not yet been able to turn off. This is the fellow responsible for the 3 or 4 pixels of dead space at the bottom of the Konqueror window, and also the reason why Konsole still has a border around the display widget if you hide the window decorations ( the associated bug report has > 200 votes, I really do want to fix it for KDE 4 ).

There are three things which can be done by various parties to improve matters:

• Developers: Take a closer look at your application and see if there are any unecessary visual borders which can be removed


• Users: Take a closer look at the applications you use and bring instances of excessive frames or poor spacing to the attention of developers


• Trolls: Please help me with the QTabWidget issue. Will sweeten the deal with beer at the next Akademy

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.