This page covers topics related to the KDE PIM Suite on MS Windows NT.
To build KDE PIM for Windows use emerge. For documentation about emerge please see 
You should be able to get executables just by calling emerge kdepim.
|TO DO||Documentation of KDE||Due to meinproc4 crashes documentation build is turned off from all kde products.|| [mailto: < >]
|TO DO||LDAP Support||Enabling KLdap|| Andre Heinecke <firstname.lastname@example.org>
|TO DO||Akonadi Notifications||Akonadi Notifications are not communicated correctly to the GUI|| [mailto: <>]
|IN PROGRESS||Search||Provide a search backend|| Andre Heinecke <email@example.com>
|IN PROGRESS||Nepomuk||Provide a working Nepomuk|| Andre Heinecke <firstname.lastname@example.org>
Currently as of 22.2.2010 in all KDE builds for Windows Documentation build is turned off because of BUG263828 Meinproc4 crashes in the call of libxslt's transform function.
OpenLDAP does not build well for Windows on Windows, for this reason there is no working OpenLDAP-src target in emerge, if you want LDAP Support you have to manually install OpenLDAP into your KDE Enviornment before building kdepimlibs.
Since Windows has native LDAP support with winldap it is easily possible to use that, an Obstacle for this is that also kdepimlibs is built with -DUNICODE it expects all system LDAP calls to return ASCII so you would have to do some conversions mappings there. A bit code for that is already in kdepimlibs/kldap/w32ldaphelp.h but it is only finished for WinCE not for WinNT.
Strigideamon does not compile for Windows NT at the moment, so apart from Virtuoso/Nepomuk there is no Search for KDE PIM Software available. At least strigiclient we have to build though.
Nepomuk only supports Virtuoso as Database backend. 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. This might have implications wrt
When an item is added to akonadi it sends a notification to the GUI that an item was added. The collection this item belongs to is a QINT64, according to akonadiconsole and qdbusviewer the value of the collection id is completly bogous. This results in the proxymodel to throw away the documentation and not update the GUI.
|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...|
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.
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.
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. Example implementation of MAPI services is Thundebird's mozMapi32.dll (the key is usualle equal to C:\Program Files\Mozilla Thunderbird\mozMapi32.dll).