KPrinter available for KDE 4

KDE logoOne 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.

Advertisements

[Howto] Share Ethernet via Wifi with NetworkManager in KDE

KDE logoI 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:
Share-Wireless
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:
Plasma-Connection-Established
Plasma-Applet-Conncetions

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.

Short Tip: Fix qdbus problems during a Kubuntu upgrade to 13.04

135712502612
I just performed an upgrade of my Kubuntu installation from 12.10 to 13.04 and had problems with the starting KDE seesion: it wasn’t able to bring up dbus, asked if I were able to call qdbus and quit afterwards.

A short test on the command line calling qdbus brought up a strange error: the binary was there and could be called, but looked for another binary called qdbus in /usr/lib/x86_64-linux-gnu/qt4/bin/qdbus which wasn’t there. However, there was a binary called /usr/lib/i386-linux-gnu/qt4/bin/qdbus, and thus I realized that the i386 version of qdbus was installed, rather than the x86_64 version I needed. Thus the fix was easy:

apt-get install qdbus

The i386 version was automatically removed, the x86_64 bit version was installed, and KDE was able to start up properly.

Small Gems: KMail attachment notification

PIA16218

Once in a while I run into really nice and well crafted features in software which are hardly known – or at least not advertised enough. I call these small but shiny features “little gems”. One of those struck me in a recent KMail release.

Everyone who has ever used e-mails has at least once gotten or sent an e-mail which was intended to have an attachment, but didn’t have it. KMail has the possibility to check a written mail for certain, user configurable key words: if there is a word match in the mail without it having an attachment, the user is asked if he/she hasn’t forgotten the attachment when he/she hits the send button.

With recent KMail versions, the check is done on the fly, and the notion about a possible forgotten attachment is integrated much better into the entire interface:
Kmail-attachments
Pretty neat =)

Howto: Extracting entire mails in mbox format from Zarafa [link]

Tux
A Zarafa groupware does workin complex setup you most likely have spam filtering software like Spamassassin running on the main MTA in front of Zarafa. Modern spam filters however need to be trained with ham and spam examples – and Zarafa has no simple way to export stored mails in a txt or mbox format, and the database does not store mails but mapi objects.

Luckily, a coworker of mine here at credativ has written a script to extract mails from a Zarafa to mbox as long as some header information are known: [Howto] Zarafa mail extraction.

Open Source Groupware checklists

TuxIn the last months and years I had to deal with various requirements people have regarding groupware ecosystems. Open Source solutions have matured in this area and this article highlights some needs, but also some common pitfalls.

Preface

In these days there are many excellent Open Source groupware solutions out there. Two well developed solutions I saw in several productive environments are Zarafa and Open-XChange. Both of them are ready to replace Exchange in various productive setups, and I have seen both being deployed successfully as either Exchange replacement or even as a fresh groupware installation for growing offices and working groups.

Also the connection to the mobile world is common as well these days – thanks to z-push and the likes. Yes, there are some licence issues and I would prefer to use a CalDav solution. But ActiveSync works with open source tools pretty well.

However, there are still weaknesses in the Open Source groupware ecosystem. A big one is the Open Source fat client. Most of the clients (Evolution, Thunderbird and Kmail) do not work flawlessly with the currently available Open Source groupwares. Most of the services these days move to web clients anyway, but it is sad to see that there is hardly a well working groupware server fat client setup out there.

For example, in my personal working spaces I do need to sync Evolution with Zarafa, and KMail with OX. And in both setups there are components which do not work at all.

The needs

To better estimate the quality of a groupware solution here is a list of what such a solution should be able to provide:

  • Multiple address books and their synchronisation.
  • Multiple calendars and their synchronisation.
  • Different user rights per calendar.
  • The ability to overlay different calendars on the client side.
  • E-Mail-Invitations for appointments.
  • Free/Busy lists for other users, visible in the calendar view.
  • Collision handling whenever the problem comes up.
  • Centralized web interface for all components,
  • Support for sync of ToDos.

There is no need that one server does that all on its own. The address book could be delivered by ldap, and there are good calendar servers out there like DAViCal.

But even if this list does look pretty normal, some of the points are not covered by the solutions out there. For example: You cannot share multiple calendars with your Zarafa server and your mobile phone without using some ugly hacks. Also, the collision handling is often automatically, the user does not even notice any problems. Another problem is that hardly any solution can sync ToDos properly. And, of course, hardly any of the solutions out there supports Linux based fat clients properly.

Some common tests and problems

But even if a groupware solutions states on paper that it fulfills all the mentioned needs, it might fail in the day-to-day routine. Thus here are some quick tests and common problems which can be checked on demo or test installations to get a first impression:

  • Are multiple-day, recurring events synced correctly?
  • Are multiple-day, recurring events still correct after changed again and again on both sides?
  • Create a calendar with 40k entries, and sync it. How long does the re-sync take after some changes?
  • Are ToDos synced together with their due dates?
  • Let user B alter calendar entries of user A and check if these changes are properly synced.
  • Create a collision on purpose: is the problem solved or is the entry doubled? Is the user notified of the collision?

As mentioned, this list is just to get a first impression. If you are going to become serious about a new groupware, you have to analyze your workflows, and test the groupware ecosystem against these. I must say that most often the biggest challenge actually was to comprehensively identify all workflows! So don’t underestimate the importance of that, and how much time that task takes.

And, with all these tests: keep in mind that sometimes flaws only begin to show under heavy load. Don’t test with two calendar entries and one address book entry and be happy because that minimum setup works!

The solution

As with most real world setups, you should work two-fold: first, check what features you really need, and compare them against the stated features of each groupware ecosystem. Afterwards, pick the survivors and test them against the workflows you have in your daily routine. Don’t trust and hope.