PIM/MS Windows

This page covers topics related to the KDE PIM Suite on MS Windows NT kernel (which means running on Windows Desktop versions NT or newer like XP, Vista or 7).

Building

To build KDE PIM for Windows use emerge. For documentation about emerge please see [1]

You should be able to get executables just by calling emerge kdepim.

Bugs

For a list of open, Windows specific, bugs please see: bugs.kde.org

Problem points

Status	Feature	Description	Contact
DONE	Documentation of KDE	Due to meinproc4 crashes documentation build is turned off from all kde products.
TO DO	LDAP Support	Enabling KLdap	Andre Heinecke <[email protected]>
DONE	Akonadi Notifications	Akonadi Notifications are not communicated correctly to the GUI
DONE	Search	Provide a search backend
DONE	Nepomuk	Provide a working Nepomuk
DONE	Akonadi startup/shutdown	Decide how akonadi should be started/stopped on Windows (There is now a Full Shudown button in Kontact that also kills akonadi
TO DO	Multiuser Support	Make it possible to deploy KDEPIM in multiuser environments
DONE	Image view in Mailviewer	Images in the Mailviewer are not shown correctly
TO DO	Configuration dialog asks for save every time	The configuration dialog asks the user to confirm his changes even if no changes were made
DONE	Design	Make KDEPIM feel native on Windows
TO DO	Integrate with GPG4Win	GnuPG is currently not supported	Andre Heinecke <[email protected]>

Multiuser Support

Kontact on Windows currently not able to handle multiple users running it in parallel because of several bugs.

Documentation of KDE

For more details about the problem check the bug report: BUG263828

There is a workaround and documentation can be built.

LDAP Support

There are two options to get LDAP support for PIM on Windows:

OpenLDAP

• Pro:
  • Would offer the same API as on GNU/Linux
  • Is proven to work on Windows with KDEPIM
  • If just a binary package is used, the effort is small.

• Contra:
  • Current Openldap is not ported to be buildable natively on Windows. So far it would need to be cross compiled, or cygwin compiled or the binaries taken.
  • More effort to do a good port to a decent buildsystem which fits the toolchain like cmake/emerge to be build with msvc or mingw-w64 on Windows.
  • Can not be debugged with msvc for above reasons
  • Is another dependency we have to take care of, which increasing code and complexety, more chance for security issues and the port needs to be maintained.

WinLDAP

Windows has native LDAP support with winldap:

• Pro:
  • Integrated into the platform, maintained by Microsoft
  • API differences should be Minimal so kldap calls could stay the same
  • Behaviour consistent with other LDAP client behaviour on Windows.

• Contra:
  • Efforts comparable to OpenLDAP with initally ported build system. In particular higher than the simple "take binary" approach.
  • kdepimlibs is build with -DUNICODE, but expects LDAP system calls o return ascii, so this needs conversion. There is a bit code in kdepimlibs/kldap/w32ldaphelp.h which works fo WindowsCE, but now Windows>=NT.
  • Is propietary we do not know the implementation details and cannot debug it.
  • Might show slightly different behavior than OpenLDAP, which raises potential testing and support costs when Kontact behaves differently here.
  • Might not implement all functions used by kldap so working around it in kldap would be necessary.

Search

Search is available over Nepomuk

Nepomuk

For a virtuoso installation to work regsvr32 has to be called on the virtuoso odbc driver at the moment. Soprano has to be fixed so that it checks if that driver is availble and if not registers it. The NSIS installer does this currently

Akonadi Notifications

DBus problem that has been fixed in newer versions of DBus > 1.4.1

Design

Oxygen Theme looks strange and alien on Windows 7 default style but ok on Windows XP style Currently the Packaged Style in the Enterprise 5 package is optimzed for XP and Vista/7 looks.

Best solution would be to check what the System Style is or package the KDE-Systemsettings to customize that style.

Akonadi Start Stop

Akonadi startup can take a while on slow systems which delays the first Kontact startup.

Once akonadi is running it can not be stopped from the UI

GPG4Win Integration

Currently crypto operations appearently corrupts the stack, causing Kontact to crash in unrelated operations. For this reason GnuPG support has been completly disabled since 2011.04.11. Crypto integration is one of the most important features of Kontact on Windows and we need a way to integrate it properly.

General Hints

Shutdown everything from KDE

Either run killkde.bat in your installation\bin directory or run kdeinit4 --terminate to shut down everything.

Delete all configuration

To delete all configuration files remove the folders .local .config .kde in your userdata directory. (e.g. c:\documents and settings\testuser\ on xp c:\users\testuser on win7) Also delete .kde in your application data directory (e.g. c:\documents and settings\testuser\Applicationdata on xp c:\users\testuser\Applicationdata\roaming on win7)

Switch to English

To change the application language of Kontact from German to English please use a text editor and change the locale settings in the file 'kdeglobals' to:

 Country=en
 Language=en_US

and restart all KDE processes (esp. logout, login). You'll find this file usually under the installed directory in 'Kontact\share\config' (e.g. c:\Program Files\Kontact\share\config\kdeglobals).

Or goto: help -> change application language

Backtrace for Crash reporting

If you encounter crashes, a backtrace might help the developers to find the defect faster. There are some hints doing a backtrace with gdb on windows in http://techbase.kde.org/Development/Tutorials/Debugging/Debugging_on_MS_Windows#MinGW_debugging_hints

Diagnostics

General debugging techniques of KDEPIM Software are also available on Windows. There is akonadiconsole installed as a tool to debug akonadi, as well as qdbusviewer.

DebugView and some other tools from the following URL can be useful to diagnose problems: http://techbase.kde.org/Projects/KDE_on_Windows/Tools

DebugView will let you see the message of the KDE runtime system, which on GNU/Linux you can see on stdout or stderr.

---

Some notes from the original porting project

Integration into the Windows Explorer & Desktop

Note

jstaniek 22:01, 14 January 2008 (CET): TortoiseSVN is GPLed SVN client which is nicely integrated with Windows Explorer. Perhaps we can use its source code as a reference...

Registry settings for default apps and services

Introduction: We can detect whether KMail is the default e-mail client. If set as default, KMail should act as a default mailer, and thus be invoked automatically for actions like RMB "Send To -> E-mail Recipient". This shall be also reused by others for KOrganizer and Konqueror. The solution is relatively simple modifications to the Windows Registry. See Mozilla's solution.

First, we can use HKLM node for system-global settings or HKCU node for current-user-only settings. If the attempt to set the value in HKLM fails, usually because of unsufficient permissions, HKCU should be used. As expected, HKCU overrides HKLM settings. See KB297878. Below we'll use HKCU.

• HKCU\Software\Clients\StartMenuInternet key is used to specify default web browser; could be set to Konqueror
• HKCU\Software\Clients\StartMenuInternet\app.exe\shell\open\command key is used for "Internet" start menu shortcut, can be set to Konqueror. Note from the KB - "The command might open the browser on the users home page, for example. However, it might launch some other introductory user interface that the ISV feels is appropriate." So this is not the same as 'default browser' setting.

• HKCU\Software\Clients\Mail\Appname - registered email client, there can be more entries within the 'Mail' node. Adding KMail here makes it available for users to select as a default browser using 'Set Default Programs' system window.
• HKCU\Software\Clients\Mail - default email client, 'Windows Mail' by default; could be set to KMail.

• HKCU\Software\Clients\Calendar\Appname - registered calendar application, there can be more entries within the 'Calendar' node. See the note for HKCU\Software\Clients\Mail\Appname.
• HKCU\Software\Clients\Calendar - default calendar application, 'Windows Calendar' on Vista; could be set to KOrganizer.

• HKCU\Software\Clients\Contacts\Appname - registered contacts client, there can be more entries within the 'Contacts' node. See the note for HKCU\Software\Clients\Mail\Appname.
• HKCU\Software\Clients\Contacts - default contacts application, 'Address Book' by default; could be set to KAddressBook.

• HKCU\Software\Clients\News\Appname - registered newsgroup client, there can be more entries within the 'News' node. See the note for HKCU\Software\Clients\Mail\Appname.
• HKCU\Software\Clients\News - default newsgroup application, 'Windows Mail' by default; could be set to KNode.

From the KB: After updating the registry keys, the application broadcasts the WM_SETTINGCHANGE message with wParam = 0 and lParam pointing to the null-terminated string "Software\Clients\StartMenuInternet" to notify the operating system that the default client has changed.

Using MAPI

HKLM\Software\Clients\AppName\DllPath points to a dll implementing MAPI interface. Internet Explorer uses Windows Messaging by default to invoke a mailer on a mailto: link. Only if the MAPI install is misconfigured will it resort to directly accessing the mailto association key.[2] Example implementation of MAPI services is Thundebird's mozMapi32.dll (the key is usualle equal to C:\Program Files\Mozilla Thunderbird\mozMapi32.dll).

KDE-related notes

• KDElibs execute default web browser or email client for protocols like http(s): and mailto: via QDesktopServices::openUrl(), which in turn uses ShellExecute(). openUrl() is widely used in Qt e.g. for hyperlinks in text boxes and label widgets.
• A general rule of KDE/win: not to duplicate registry settings in any rc file and use default applications if possible, to avoid changing behaviour expected by users.
• jstaniek 12:06, 18 June 2008 (CEST): Before LinuxTag I've performed some tests of setting default clients, and looks like it's is not possible to set onlt writing registry entries. Some API calls may be needed, especially because locked at least one registry key is locked for writing during the session.

Links

• The KDE on Windows Project
• Missing features of kdelibs on Windows - KDE PIM may depend on them