KPrinter available for KDE 4

One of the missing features of KDE 4 compared to KDE 3 was the not longer available KPrinter, a tool to print Postscript documents even out of non-KDE programs.

In KDE 3 KPrinter was responsible for printing of KDE applications, but other programs used it as well: if they had no own printing configuration but the possibility to add a generic command (like lp/lpr) they were often configured to print against the KPrinter command. KPrinter took the printed file and provided the the user a modern and flexible graphical user interface dialog to pick the preferred printer, change the printer configuration and so on.

With the transition to KDE 4 KPrinter vanished in favor of the Qt print dialog options, which worked only for Qt/KDE programs. All other programs outside Qt/KDE which relied on KPrinter as a drop-in command line tool were at a loss.

Now Marco Nelles – a co-worker of mine here at credativ – published KPrinter for KDE 4. As the (German) blog post shows the new Kprinter provides what we already know from the KDE 3 times: a drop in replacement for other command line printing tools but with the usability and flexibility of the KDE printing dialog. The two screenshots of the post give you an idea of the new interface. For example, the new KPrinter offers to scale the pages to various sizes and even print posters.

This development is incredibly useful if you have legacy software or software which does not offer for example a cups interface. It also helps in case you need to print Postscript files with your own applications but do not want to hook on to Cups yourself.

As the blog post mentions, the future of the kprinter code, hosted at Github, is open for everyone to participate. It might be worth a thought for example to extend the code to also process PDFs. If you want to track the development of kprinter you also might want to follow kprinter’s kde-apps page.

[Howto] Share Ethernet via Wifi with NetworkManager in KDE

I recently was taking part in a training at a place which had poor cellular reception, no wifi and only one single ethernet connection. Thus we had to the ethernet via wifi. I tried to do just that with my laptop via NetworkManager – and it worked out of the box.

The basic situation is rather common: you have one single network connection, and want to share it to other people or devices via wifi. If you want to do that manually you have to set up the wifi network on your own, including encryption, need to bring up a dhcp server, configure the routing and NATing, and so on. That can take quite some time, and is nothing you want to do during some precious training hours.

Thus I simply tried to bring up a shared wifi via the NetworkManager applet in KDE:

After providing a SSID name and configuring some security credentials the process was already done, and I was notified that the network was set up and ready. It was also shown in the plasma applet besides the ethernet connection:

And that was it already: everyone was able to connect to the network without any problems – and it didn’t even took me a minute to bring it all up. Since I know how much trouble it can be to bring such a connection up manually I was really impressed!

In case you want to give it a try, make sure that your wifi hardware and thus the appropriate driver; do support Access Point (AP) mode which is needed to bring up the wifi. If it says “for some devices only” you have no choice but give it a try.

By the way, in case you wonder about DNS and DHCP: both is done via dnsmasq as a local server, offering both. The DNS queries are forwarded to the DNS servers you got via DHCP from the ethernet connection (or, presumably the one you configured in NetworkManager).
However, I was not able to find any temporary configuration in /run or /var/ which showed the actual DNS servers – I had to call nm-tool to figure that one out:

$ nm-tool
- Device: eth0  [Standard-Ethernet] --------------------------------------------
[...]

  IPv4 Settings:
    Address:         192.168.3.27
    Prefix:          24 (255.255.255.0)
    Gateway:         192.168.3.1

    DNS:             192.168.2.4
    DNS:             192.168.2.3

If you know of any other way to find out these information, or even better simply the entire configuration of dnsmasq for that purpose please let me know =)

Besides, while the Plasma applet gave me the option to shut down the shared wifi network, I wasn’t able to bring it up again. There simply is no option in the network overview to fire up again such a network, thus I filled a bug report.

But, besides these two smaller issues, the plasma-nm applet and thus NetworkManager did a great job making sharing networks very easy.

[Howto] Using sks key server pool for managing GPG signatures

GPG/PGP needs key servers to work properly. However, some of the servers announced on the web only react slowly – or not at all. The solution is to access a pool of servers which maintains itself.

GPG/PGP works within a web of trust: you trust people you know by signing their keys. If you meet someone you don’t know, you can check if someone you trusted signed the key of the unknown person.

To look up such signatures you however need the infrastructure of such a web of trust: key servers, which store and deliver keys and signatures.

However, many key servers are really slow or do not work properly although they are still listed in programs like KDE’s kgpg. The solution is to use a round robin based pool of servers like the sks key servers. The advantage of such a pool is that even if one server does not respond, next time you query the pool another server will respond most likely. Also, the pool checks itself if the servers are working and removes them from the pool if not. One new child of the family of pool servers is by the way a server provided by the Fedora Project.

The sks pool can be used just like any other key server, for example on the command line:

$ gpg --keyserver keys.fedoraproject.org --recv-keys 449FA3AB
gpg: requesting key 449FA3AB from hkp server keys.fedoraproject.org
gpg: key 449FA3AB: public key "Linus Torvalds <torvalds@transmeta.com>" imported
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   2  signed:  12  trust: 0-, 0q, 0n, 0m, 0f, 2u
gpg: depth: 1  valid:  12  signed: 123  trust: 6-, 0q, 0n, 0m, 6f, 0u
gpg: depth: 2  valid: 122  signed: 177  trust: 119-, 0q, 0n, 0m, 3f, 0u
gpg: depth: 3  valid:  63  signed: 113  trust: 63-, 0q, 0n, 0m, 0f, 0u
gpg: next trustdb check due at 2014-05-10
gpg: Total number processed: 1
gpg:               imported: 1

You can also add the key server to GUI programs like kgpg, or add it as default server to your ~/.gnupg/gpg.conf:

$ grep keyserver .gnupg/gpg.conf
keyserver  hkp://pool.sks-keyservers.net

[Howto] Remapping buttons with xbindkeys and xte

Sometimes you buy devices like a mouse or a keyboard which provide additional buttons for special functions. Or which have buttons which do not behave as expected. In such cases the button actions can be mapped to other functions, or even to other buttons.

I recently bought a Logitech M705 mouse which works almost perfectly. However, there is one nagging bug: the middle mouse button does not trigger the usual event “mouseclick two” which is interpreted as pressing the middle button, the scroll wheel which is crucial for example browsing the web. Nothing happens.

In such cases the first step is to see if the operating system receives any input at all. Fire up a shell and start the program xev. It opens a small, white window where you can move your cursor to. As soon as the cursor enters the window, you will see a lot of log data on the shell: xev shows you all X events, thus all data you enter via keyboard or mouse.

In my case I pressed the middle button, and saw:

ButtonPress event, serial 40, synthetic NO, window 0x5800001,
    root 0xc7, subw 0x5800002, time 19610234, (46,38), root:(1784,61),
    state 0x10, button 6, same_screen YES
[...]
ButtonRelease event, serial 40, synthetic NO, window 0x5800001,
    root 0xc7, subw 0x5800002, time 19610234, (46,38), root:(1784,61),
    state 0x210, button 6, same_screen YES

The interesting part is that the button was not interpreted as “button 2” as I would have expected, but as “button 6”. That’s not what I expected, and thus the button must be remapped to the event “button 2”.

Mapping of keys and buttons can be done via xbindkeys: in case of KDE I created a symlink to start the program at each startup:

ls -la ~/.kde/env/xbindkeys 
lrwxrwxrwx 1 liquidat users 18 Aug  1 10:56 .kde/env/xbindkeys -> /usr/bin/xbindkeys

xbindkeys reads its configuration from ~/.xbindkeysrc, so that’s the place where we need to configure the actual mapping. The syntax is:

#    "command to start"
#       associated key

The most interesting part of the mapping is: how to trigger the action “button 2”? That is done by the program xte which generates fake input. Thus the final configuration is:

"xte 'mouseclick 2'"                                                                                                                                                                                           
  b:6  

And you are done. Pressing the mouse button 6 on the Logitech M705 now launches the mouseclick 2.

However, as stated correctly by the comments below, this is just an intermediate solution! A long time solution is to fix the mapping in evdev, the Linux input handling.

Short Tip: Extract attachments from multipart messages

Sometimes e-mails are stored as a plain text file. This might be due to backup solutions or as in my case, sometimes I have to save e-mails in text format because the client has issues with more complicated S/MIME mails with attachments.

In such cases the text file itself contains the multipart message body of the e-mail, so the attachments are provided as base64 streams:

--------------060903090608060502040600
Content-Type: application/x-gzip;
 name="liquidat.tar.gz"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="liquidat.tar.gz"

qrsIAstukk4AA+17Wa+jSpZuPfMrrK6Hvi1qJ4OxsfuodQU2YLDBUJDGrvqBeR7MaPj1N7D3
OEmSxO8Wq7+3Y48dTWvXi8XvvKj8od6vPf9vKjWIv1v7nt3G/d8rEX5D/FdrDIxj2IrUPeE/
j5Dv4g9+fPnTRcX006T++LdYYw7w+i...

These data can be extracted manually, but that’s a wearisome task. It’s easier to use munpack, which can easily extract attachment(s) out of such text files and write them into a proper named files.

$ munpack -f mail.txt
liquidat.tar.gz (application/x-gzip)