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.

FOSSCamp

This weekend I was invited by Jonathan Riddell of Kubuntu fame to attend a completely unscheduled conference in Cambridge, MA called FOSSCamp. Most of the attendees were Canonical employees but there were many representatives from other projects and companies (such as gnome, Red Hat, Samba, the FSF) as well. I was joined by Troy from KDE's publicity machine and Leo, Jeff from Amarok. Thank-you to Canonical (Jonathan and Claire in particular) for inviting us.

I have never been to an 'unconference' before, but there were many interesting sessions going. Unfortunately given that there were 3-5 happening at any one time on the first day, I missed a few that I would have liked to attend. Here is a summary of the sessions which I was able to participate in.

Suspend and Resume

The first session I attended was a whistle-stop tour through the seedy and hack-filled world of what happens when your laptop goes to sleep and wakes up again, led by Matt Garratt. After a basic introduction to how suspend and resume are supposed to work, Matt explained why it doesn't always. The next few sentences allude to terrifying hacks and should not be read by young children and people of a nervous disposition.
The main problem faced at the moment is getting the video hardware programmed correctly on resume. Currently the BIOS is tricked into running its own video setup code on resume which may or may not work. Better documentation from the manufacturers should help but it is slow to appear. Debugging suspend and resume (using the system clock as a debug data store!) was also covered. The need for more public details on the process was raised and they will probably appear in the Ubuntu wiki soon.

HotWire

HotWire is a replacement for the standard shell. It is both a text-driven graphical user interface and an object-orientated command line written in Python. The front-end is designed to greatly improve the accessibility of the shell with better auto-completion and history preservation. It can also use a modern graphical UI to visualize the output of commands. For example, typing "ls" produces a list of files in the current directory with appropriate icons and columns which can be resized and arranged. Commands are executed asynchronously so that multiple commands can be executed simultaneously and their output switched between much more easily than a conventional terminal. The downside when I last tried HotWire is that it didn't feel as responsive as a normal terminal. There are also quite a few bugs to fix and polishing required to make it feel slicker and a more natural experience.

The other aspect of HotWire, the object orientated shell, was the one which garnered much more interest. Current UNIX shells pass simple byte streams between applications. Like Microsoft's PowerShell, the idea is that passing objects between commands could allow for much more powerful command lines and less error-prone text processing. Quite a few attendees at the session were interested in having a better object shell but still wanted to use it from within their existing terminals (which include the Linux terminal on machines without X, emacs and text editors or IDEs with shell plugins).

GNOME Online Desktop

Like Hotwire, there are several aspects to Gnome's online desktop, some more interesting than others. One aspect is re-engineering applications to sync with online services and make use of data from them out of the box with minimal effort on the part of the user. This is something which would probably be very valueble to many KDE users as well since they could use their favorite KDE applications for work and communication and still share the results easily with friends or get access to the information regardless of the PC or other device they are using. Another aspect is 'Big Board' which, from what I saw at the demo, provides a summary view of information of interest to the user across various local and online services. It also brings the concept of an online identity more prominently onto the desktop and provides facilities to sign into various online services without having to go to their website. Plasma has a few applets which do similar things with regards to providing status snippets and updates for online and local services so it would be possible, if Plasma was working as it should be, to create something that looked like Big Board. What 'Big Board' has in its favor is a much more cohesive design from the end user's perspective such that the various parts fit together out of the box in a way which is useful. The downside is that at the moment it does not appear to be all that flexible and is limited in the range of services that it can talk to. One of the attendees suggested that it should use Evolution Data Server to get its calendar, TODO, status updates and other data. In the KDE world, the equivalent would be Akonadi. Having a side-panel which displayed aggregated summary updates from my various mail sources, calendars and so on which are spread across multiple web sites, local and remote files would certainly be quite useful. With Qt 4 eye candy it could look very pretty. At one point during the demonstration the internet connection failed and 'Big Board' became a big white empty space at the side of the screen. Better off-line support is obviously a requirement.

Looking at the web-site there are parts of the system (such as the web sign in daemon) which seem like good candidates for cross-desktop collaboration.

The other major aspect of the OD project is the server which stores a subset of users' settings (including desktop setup and I guess personal information and passwords etc.) online.

There is lots to think about as far as KDE and online services are concerned. KDE's libraries (new and old) provide a good technical foundation on which some really neat applications could be built. The question is how to approach this from the user experience perspective, that is not something which I have seen a big discussion on yet.

Freedom for Web Services

Brett Smith of the Free Software Foundation lead a discussion on what 'free' means in the context of online services and how the advantages of online services might be provided in a way which preserves this freedom. Apparently the FSF's position is that no centralized online service can meet their definition of free because the users of such a service cannot modify the code which is run when the service is used, even if the service provider makes the code available (which most do not). In this view, even something like Wikipedia does not qualify as free and the problem becomes a technological rather than legal one to invent a new means of delivering such services.

There was some discussion around the distinction between freedom as it relates to software which an online service uses to process data and the freedoms users have over the data they create and store in the service. The need for an easy way to convey these data freedoms was raised. My personal view is that large centralized online services (as opposed to the FSF's theoretical alternatives) will be a reality for the foreseeable future and therefore companies need more incentives to provide users with freedom over their data. An example might be a simple labeling system. In the UK food now comes with 'traffic light' labels on the packaging to indicate in simple terms how good or bad it is for you (in terms of fats, salt, sugar, proteins etc.) which has had some success in encouraging sales of healthier food and discouraging sales of unhealthy food. Perhaps the same idea could work for online services. The idea being that if a user Mike has a choice of "Larry's Calendar Service" or "Sergey's Calendar Service" he would be able to see a simple 'freedom rating' for the service and factor that into his decision. The problem of course is that the choice might largely be determined by the service which Mike's friends use rather than the service's features.

KDE 4 Libraries and Technologies

This was quite a busy session lead by Troy with discussion of the new libraries in KDE 4 and how they relate to other parts of the Linux platform. The usual topics of Qt 4 and KDE's new libraries for multimedia, hardware, search and the semantic desktop were also discussed. Leo and Jeff from Amarok were on hand to discuss the implications of these libraries in real, working applications.

* WebKit was probably the topic which attracted the most interest as it is relevant for both Gnome and KDE developers. WebKit/KHTML's CSS 3 support was trumpeted by other developers present.
* The problem of the multitude of indexers available including Strigi,Tracker etc. attracted some attention. I mentioned XESAM as a specification which allows client applications to be indexer-independent for queries. Mark Shuttleworth noted that this left the problem of how applications can provide information to indexers. I didn't know this at the time, but according to the XESAM website the specification is being developed incrementally and that facilities to do this might form part of the second iteration.

One of the participants mentioned the need for a demo KDE 4 application (like Qt's qt-demo) which shows off KDE 4's new features and provides simple working code which new developers can make use of in their own applications. I agreed but pointed to the applications in kdegames and kdeedu as the best place to start until such an application is written.

I mentioned Akonadi briefly which generated some interest. Unfortunately at the moment it is difficult to demonstrate in a really meaningful way.

Education

This session became a demonstration of KDE 4's educational applications. Marble in particular attracted attention from the participants. One point that did come up in the discussion was the usefulness of being able to adjust an educational product to fit in with different cultures and environments. An example given was an educational authority which wanted to remove smoking-related items from KTuberling. In KDE 4 this should be much easier to do given the use of SVG objects which allows individual items in scenes to be adapted and removed. I attempted to given an impromptu demonstration with Inkscape, but it wasn't quite as easy as I hoped since I picked the wrong file to edit. More documentation for distributors on how to edit or create new resources for applications would be useful.

The importance of making educational applications and games which work well on thin client systems was also raised. Firefox was cited as a problematic application because of the memory used for X pixmaps. There was hope that a WebKit browser would help in this area. For KDE, it is not easy to judge the problems until someone actually attempts to use the applications in such an environment.

Upstream Patch Flow

This session was a debate and discussion on how we (upstream) can discover and manage patches produced by distributions. Ubuntu hackers pointed to a few resources such as Ubuntu Merges which can help upstreams keep track of patches. Unfortunately both upstream and downstream have the same problem in that they have a large number of suppliers and consumers respectively which all have different systems for managing and accepting patches. Something which Ubuntu can do in the short term is automated emails to upstream maintainers about patches which are added. A quick review of patches to kdebase/kdelibs showed that much of what is patched or added are changes to the build system which is less interesting than changes to the code itself.

KDE 4 Applications

This session took part on the second day which was considerably quieter. I demonstrated a wide range of KDE 4 applications from various KDE projects to a small audience of about 15. There was appreciation for many of the new features, although in order to really impress people the front-end needs to be much slicker. The colour scheme which ships with the Oxygen style does not work very well on projectors or lighter flat screens at the moment, adjustments are definitely required in this area. Leo and Jeff lead a demonstration of the new features which Amarok 2 will provide including more online services, a new playlist, a much more prominent canvas for displaying contextual information and better plug-and-play support for a variety of media devices.

I was also asked about PIM applications afterwards. As many readers will know, the PIM applications shipped with KDE 4.0 will be fairly similar to their KDE 3.5 counterparts. Akonadi should make much more exciting things possible.

Kickoff redux

As Sebas' mentioned recently, I have been working on a new implementation of the Kickoff start menu/application launcher. It is currently functional, although I have not started work on some of the presentational aspects yet (such as the background and tab styling). Hence no screenshots in this post. If you are testing KDE 4 on a system with KDE 3 installed, then in the case of applications for which both KDE 3 and KDE 4 versions are available, only the KDE 4 version will be shown. The search view is currently limited to application searches, but I hope to have Strigi searching working soon. Ideally query handlers will be shared between the launcher and the run dialog.

The new Kickoff can be found in trunk/playground/base/kickoff-rewrite-kde4/ and it currently builds both as a standalone application ('kickoff') and a Plasma applet ('Application Launcher' in the 'Windows and Tasks' category). The Plasma applet is a simple KDE logo button which pops up the menu when clicked on.

Hopefully Kickoff will ship with Beta 3 next week.

This new implementation is being done from scratch using Qt 4 / KDE 4 frameworks. This is the first time I have made any real use of some of the new KDE 4 libraries; they are great to work with and a few little extras have been added as a result. For example, one minor detail I added compared to KDE 3's Kickoff is that in KDE 3, the 'My Computer' tab always has an icon of a tower desktop system. In the new KDE 4 Kickoff the icon will change to a laptop or a tower depending on what kind of system it is being run on - and that is done with a couple of lines of code.

Finally, feedback is always welcome. If you are an OpenSuSE/KDE user who uses the Kickoff menu on a regular basis, feel free to add your thoughts to this post's comments :)

Funny languages in the terminal

When I look at Arabic, Chinese or Japanese text all I see are some odd squiggles. Some text that used to produce square-looking squiggles in KDE 3 now produces more curvy squiggles in KDE 4. Apparently this is a good thing. Most of this is down to Qt 4. But I still don't know whether it is readable to people who normally see something other than squiggles.

I had a stab at adding input method event support to Konsole in trunk recently, but I am very limited in my ability to test it. There is a bug report to file comments against.

If you can read and write in these languages, or even better, understand the mysterious world of Unicode - please help me to find bugs in Konsole's language support so that I can fix them.

Quick updates and Akademy thanks

First, some terminal updates:

• In the past, terminal programs running in Konsole had no idea about the color scheme being used, although some tried to guess based on the value of the TERM environment variable. I found out that the rxvt terminal sets a COLORFGBG variable which is recognised by Vim and others.
  The upshot of this is that when a color scheme with a dark background is used by Konsole , Vim will automatically pick appropriate colors for syntax highlighting. The same is true for a light background. Thanks to Robert Scott for bringing the problem to my attention.


• I added a handy "hidden" feature to the color schemes. Per-session random colors. This is commonly used for the background color in a color scheme so that you can tell different sessions apart at a glance - especially when you are working with thumbnails of the terminal. KDE 3 had a random hue feature, but it was random per Konsole process, which is not so useful. I say this feature is hidden because the option is not yet exposed in the GUI and requires manually editing the .colorscheme files. Adding this feature to the UI without cluttering what is currently a nice tidy dialog will require some careful thought.


• There was much tweaking in response to feedback from other hackers at Akademy. Cheers for the feedback :)

But the main point of this post was to thank everyone, especially the organizers, for a great Akademy. As always, the best part of this kind of conference is the people met, the discussions had and the general feeling of fraternity. KDE 4 itself still needs a lot of work before the final tarballs can be rolled, but I am confident we'll do Konqui proud.

Plain English

Everyone has their pet hates. It might be an annoying personal habit, anonymous callers or Paris Hilton. One of mine is the use of geek English in software. Aside from being a barrier to new users, it also undermines an application's status as a high quality piece of software, software that a contributor can be proud of. A few words quite widely seen in KDE circles that I find irritating are "Configure", "Initialize" and "Schema". Configure' and 'Configuration' are bad in particular because:

• It is a longer and less commonly used word than the shorter alternatives ("Edit","Settings"). This appears to be true of translations into various European languages as well. I have a hypothesis that shorter, more commonly used words are quicker for us to parse when reading user interface elements and enable us to make decisions more rapidly, thereby saving time.


• It is an unpleasant sounding word. This might sound odd, but I feel that the choice of words or phrases contributes to how polished and attractive an application is.

Obvious suggested replacements:

• Configure -> Edit, Settings, Preferences


• Configuration -> Setup, Settings


• Intialize -> Start, Starting, Loading

As an example, on startup KNetworkManager displays some progress information when connecting to a wireless station. The labels go something like this:

"Activation stage: Preparing device"
"IP configuration started"
"Commit IP configuration"
"Device activated"

Good grief. The only information I really needed to know is:

"Preparing"
"Connecting"
"Connected"

A week or so ago I became sufficiently frustrated that I went and patched the most visible uses of these words out of KDE's libraries and Konqueror's various settings dialogs. Patches as always:

kdelibs patch
konqueror patch

Incidentally, the reason this is being posted here and not initially to the KDE development mailing lists is to inspire users to complain more about the use of overly technical and/or geeky language in their applications.

konsoleprofile

I added a handy little tool to Konsole recently.

konsoleprofile allows any profile options to be set from the command line. This means that it is possible to change the color scheme, font, tab titles, menu bar mode, scrollback size, icon, key bindings, cursor options and others without resorting to the GUI.

For example, running:

konsoleprofile colors=GreenOnBlack

Inside the shell will change the active tab to use the green-text-on-a-black-background color scheme.

konsoleprofile icon=kde

Will set the icon for the active tab to the KDE icon.

konsoleprofile showmenubar=false

Will hide the menu bar.

The actual parsing of the commands are done inside konsole. konsoleprofile is just a trivial shell script which puts some magic markers around the command so that Konsole interprets it as a profile change request. Aside from simplicity, this has an advantage over the D-COP days of old because it doesn't matter when it is being run locally or on another computer being accessed via SSH. The tool currently affects every tab using the same profile as the current tab, that is clearly not always desirable, but I plan to fix that shortly.

New Konsole lands & kdegames/edu fun

I have moved the new Konsole front-end back to trunk. It wasn't quite ready for the tagging of the first KDE 4 alpha release, and there are a few notable items still to implement ( eg. key bindings editor, composite transparency ) but if you are building KDE 4 from sources, please test.

The past two weeks saw some handy additions, the most useful of which are probably the live tab titles. This allows tab titles to contain a mixture of normal text and dynamic elements which update as you navigate around directories, run different programs or connect to remote computers in the shell. The tab title defaults to a combination of the last part of the path and the running program name, but can be customised either for a specific terminal session or for a particular profile. You can specify separate formats for local activities and remote activities (ie. SSH), and Konsole will switch between them automatically.

I finally got into sorting out Konsole's profile management as well. In KDE 3 times, these were referred to as "Sessions". A profile is a saved terminal setup which can be used as the basis for new tabs or windows. One of the profiles is set as the default and is used when you start a new Konsole. In KDE 3, some terminal options were global and others could be changed in each "session" - and this distinction was slightly arbitrary. In KDE 4, every setting is handled on a per-Profile basis. In addition to the default profile, there are a number of favorite profiles, for which a menu item is displayed in the file menu which creates a new tab with that profile when clicked. In KDE 3, every "session" type had a menu item, which caused problems for sysadmins who had 30 different types for connections to various machines - so the profiles shown on the File menu can now be specified by marking them with a star in the "Manage Profiles" dialog.
One often-requested feature is the ability to preview color schemes. This is implemented in the color scheme page of the dialog used to edit profiles. As you move the mouse over a color scheme, all open terminal displays using the edited profile will be redrawn in that color scheme. Fonts can also be previewed in a similar fashion.
In addition to profiles, a select number of options can be changed for a particular tab as before - such as character encoding, text size, history options, and in the future color scheme as well. Users who need to change the character encoding should now find it easier as Konsole now uses KDE 4's new character encoding menu which divides the encodings up nicely into groups instead of the loooong list which was there before.

The problem with all these dialogs however is that they require use of the mouse, which is really not the point of a terminal, so next on my list of things to do is the ability to control profile options in a completely keyboard orientated fashion.

In non-Konsole news, I saw the kde.dot complaining about excess frames etc. in kdegames and went round and fixed each of the games. This fit and finish work is really pretty easy, so it makes a great way to contribute to KDE if you have not done so before, even if you know little in the way of C++. Along the way I got round to playing quite a few of the games. They are good fun and look great thanks to the new artwork. I also played around with the latest and greatest in the kdeedu module - some of the applications ( kmplot and kalzium to name two ) have changed quite radically from KDE 3 to 4. So even though there is no new desktop shell to be seen in KDE 4.0, much has happened elsewhere.

Cheers to the kdeedu and kdegames teams :)

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.