Video Tutorials Learning C++ (in German)

I just stumbled over a really good tutorial on youtube that teaches C++ from the very beginning (in German). The tutorial is split into lots of small episodes, each about 10 to 15 minutes. The quality of these tutorials is very good in terms of video, voice and also contents. Subject is mostly “pure” C++ and later a bit of Qt is used, so it does not cover C nor lots of additional libraries. Still, if you want to understand the details, you might want to give it a try :-)

PS: The tutorials use Kate Part, just look at the code folding bar on the left. So the author is definitely doing something right :-p

Multiple Keyboard Layouts and Shortcuts

KDE has a very handy feature to switch keyboard layouts on the fly. This is for instance useful if you use the German keyboard layout by default, and the US layout for programming. To enable keyboard layout switching, go into System Settings > Input Devices (category Hardware) > Keyboard item > Layouts tab:

Here, ‘[x] Configure layouts‘ is checked, enabling the list view. I added the German keyboard layout, and then the English (US) layout. Notice also, that the shortcut is set to ‘Ctrl+Alt+K‘. Clicking apply, a tiny little indicator appears in the panel:

You now can quickly switch with Ctrl+Alt+K between the German and the US layout. Quite efficient, especially since the keyboard layout config page allows to switch the language on application basis.

Unchanged Keyboard Shortcuts

Switching the keyboard layout has one potential issue, though: The shortcuts remain unchanged. So if undo is mapped to Ctrl+z in the German layout, it is still mapped to Ctrl+z in the US layout. Note that by ‘z’ we refer to the hardware key on the keyboard. As a consequence, in the US layout, hitting the hardware key ‘y’ on the German keyboard inserts the character ‘z’, but the z in Ctrl+z is still on the hardware key ‘z’. This behavior may or may not be wanted.

Getting more into detail reveals that the order of the keyboard layouts in the first screen shot is of importance: If you first add the German ‘de‘ layout, and then the English ‘us‘ layout, then the shortcuts will always use the Germany keyboard layout, independent of what keyboard layout is chosen.

Reversely, if you first add the English ‘us’ layout, and then the German ‘de‘ layout, then the shortcuts will always use the English ‘us‘ keyboard layout.

So it seems that the order defines a priority, and the shortcuts always use the first entry in the list.

The correct solution to fix this would (in my humble opinion) be to add an option ‘[x] Shorcuts follow keyboard layout‘ or similar. But since this option does not exist, let’s do a quick hack to still get what we want here.

A Workaround

First we reset the shortcut in the settings of the keyboard layout options:

Click apply and close the dialog. Now, the shortcut ‘Ctrl+Alt+K‘ is unbound. Our idea is now to create a script that toggles the keyboard layout by calling setxkbmap with the appropriate parameters and bind this script via a global shortcut to ‘Ctrl+Alt+K‘.

To this end, we first have to create the script. So let’s first type `setxkbmap -query` in the console and check the output. For me, this results in:

$ setxkbmap -query
rules: evdev
model: pc101
layout: de,us
variant: nodeadkeys,

From this, we can follow that the current xkb layout is achieved with:

setxkbmap -model pc101 -layout de,us -variant nodeadkeys

Now, let’s switch the de,us to us,de and try the following:

setxkbmap -model pc101 -layout us,de -variant nodeadkeys

Notice, that the keyboard layout indicator in the panel switched to ‘us‘. Calling the first variant with de,us again, we get back to the German layout.

This discovery leads us to the following script switch-keyboard-layout.sh:

#!/bin/sh

# query xkb map: us,de -> us is primary; de,us -> de is primary
dummy=`setxkbmap -query | grep us,de`

# return value 0: us,de; return value != 0, de,us
if [ $? -ne 0 ]; then
  # de is primary, now make us primary in list
  setxkbmap -model pc101 -layout us,de -variant nodeadkeys
else
  # us is primary, now make de primary in list
  setxkbmap -model pc101 -layout de,us -variant nodeadkeys
fi

Save this script somewhere to switch-keyboard-layout.sh and make it executable with

chmod 755 switch-keyboard-layout.sh

Each time we execute this script, the keyboard layout is toggled.

Next, we go into System Settings again and navigate to Shortcuts and Gestures (Common Appearance and Behavior), there in the Custom Shortcuts we add a new Command/URL item named ‘SwitchKeyboardLayout’ as follows:

As a comment for this new item, we write ‘Switch Keyboard Layout‘, in the ‘Trigger‘ tab, bind the global shortcut to ‘Ctrl+Alt+K‘, and in the ‘Action‘ tab, choose the switch-keyboard-layout.sh script. Finally click Apply, and close the dialog.

Now, hitting Ctrl+Alt+K calls our script and correctly toggles the keyboard layout including the shortcuts.

Unfortunately, this approach does not support e.g. switching the keyboard layout on application basis as the switching policy of the Keyboard settings (first screen shot) allows. Still it works.

A final remark, though: For GTK applications this works out of the box. So is there any real reason why this is not the case for KDE / Qt applications? A real fix would be very much appreciated, I’d be also fine with an option. But not providing this feature at all is very thin ice…

Update: This issue was reported as KDE bug #197552 in 2009, and resolved as an upstream issue. However, it never was reported to Qt upstream. If I may say so, this is not how resolving bugs in KDE usually works. Grrr…

Kate in 4.11

Another release cycle gone, and the KDE Software Compilation 4.11 is out in the open (well, for quite some time already), and with that it is time to talk about what changed in Kate the last half year since the 4.10 release. Besides the usual bug fixing (~50 bugs since 4.10), the following sections present some major improvements and features of Kate in 4.11.

Python Plugins

Since KDE 4.10, Kate features the Python »Pâté« plugin. This plugin basically wraps the API of all Kate application interfaces. Therewith, together with the Python KDE (PyKDE) bindings you can develop full-featured Kate plugins in Python. Being relatively new, there are quite some Python plugins available already now (see this blog, this blog, or this blog).

@Python community: You can interpret this as an invitation for writing lots of cool addons for the Kate text editor in python. All contributions are usually very much welcome!

Vi Input Mode

Enabling the vi input mode turns Kate into a full-fleged vim compatible editor: modal editing exactly like in vim. This mode is especially suited for vim users who want a fully KDE integrated text editor with all the beloved vim features. Started as GSoC project in 2010, the vi input mode evolved over the years to become a very mature alternative to vim itself. However, there is always room for improvements. The good news is, that Kate Part’s vi input mode gained a lot of attention thanks to Simon, mostly in the form of small “papercuts” that fixed small bugs and annoyances and made behaviour more compatible with Vim, including:

  • Yank highlighting, which helps you to see what text you just yanked;
  • “Yank to clipboard” (courtesy of Fabian Kosmale!);
  • The “last edit” markers, “.”, “[" and "]“;
  • Recursive vs non-recursive mappings, for if you want to e.g. map “j” to “gj” …
  • … plus plenty of fixes to gj and gk;
  • and countless other small tweaks to things like the “inner block” text object; cursor position after paste; fixes to ctrl-a/x (add to/ subtract from number under cursor); making more motions available in Visual Mode and more motions counted, etc!

One fairly major change is the introduction of an experimental Emulated Vim Command Bar. This, as you will probably have guessed, is a replacement for the current Search dialog that behaves more like Vim’s, allowing one to e.g. insert the contents of registers via ctrl-r; dismiss via ctrl-c/ ctrl-[ as well as ESC; work properly with both forward (“/”) and backward (“?”) incremental searches; use smart case for case-sensitivity; allow the use of Vim-style regex’s etc. As an extension to Vim, I’ve also added the ability to auto-complete words from the document via ctrl-space: not that useful for searching, but very useful for when you want to do a search+replace command (command mode (“:”) did not make it into 4.11, alas).

In 4.11, it is disabled by default as it is not yet ready for primetime, but may be enabled by setting the hidden config option “Vi Input Mode Emulate Command Bar” to “true”. It is much more powerful and featureful in current master (see the blog here!) and will likely be the default in 4.12.

New Text Folding

Back in KDE SC 4.8, Kate got a new code folding implementation as part of the yearly GSoC project. Compared to the previous implementation, the amount of bugs indeed reduced, but during the 4.9 and 4.10 release it became apparent, that the code folding was still not where it should be. Maybe writing a good code folding implementation was also a bit too much in terms of a newby developer in a GSoC project.

So Christoph sat down and wrote it completely new from scratch, this time very clean and simple. And as a new feature, the text folding is now per view, so the folded parts can be different in each view of a document. And as another feature for those who do not use text folding at all: Not using text folding means you have zero overhead, no matter how large the file. Besides that, code folding in Python works now better than ever before, in fact, it should be bug-free.

Passive Notifications & KTextEditor Interfaces

Passive notifications are meant to provide a non-intrusive way showing notifications (replacing KPassivePopup). Used e.g. by the data recovery, these notifications were also introduced for the search & replace feature (most of this is already available in KDE SC 4.10.3). In KDE SC 4.11, the interface for showing these passive notifications got officially included into the KTextEditor interfaces, meaning that applications like Kile or KDevelop can show notifications as well. (Issues in KDE 4.11.0 should be fixed for 4.11.1).

Next to the KTextEditor::MessageInterface, Kate has a so-called TextHintInterface since year 2003, but it seems its implementation never got finished. For 4.11, Sven Brauch stepped up and finally fixed the text hint interface. So showing tool tips for text under the mouse (section Text tooltips) is as easy as it was never before:

Saving Files

When saving files, Kate uses the class KSaveFile (in Qt5 available as QSaveFile thanks to David Faure). In short, to avoid data loss, KSaveFile saves the file to a temporary file in the same directory as the target file, and on successful write finally moves the temporary file to the target filename. If the folder of the file does not allow creating new files, KSaveFile automatically falls back to writing the file directly. In this case, data loss could happen if e.g. the system crashes in this moment, but saving the file would otherwise be not possible at all.

What Comes Next?

Announced just a few days ago, the KDE community prepares for KDE Frameworks 5 and much more: The KDE libraries and the KDE Plasma Workspace are now in long term support mode, meaning that bugs will get fixed for another two years. That means that the KTextEditor interfaces are frozen as well, there will not be any feature updates at all in the KTextEditor interfaces itself. Since Kate Part and the Kate Application are developed outside of kdelibs, Kate Part and Kate will most certainly see another feature release. Especially, since there are already a lot of improvements for the vi input mode in the pipe for Kate in KDE SC 4.12.

After that, we plan to port Kate to Qt5 and the new frameworks 5 libraries. We already added a lot of “KDE 5″ todo-markers to the Kate source code, meaning that we will probably work on a 5 port rather sooner than later. We will address this schedule in a separate post later this year, so stay tuned!