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