Now I’m getting up to speed with Windows testing/fixing etc. I start to notice a few small things:
- Some applications do not set an application icon: on Windows the icon has to be ‘baked’ into the .exe file to be shown. I fixed that for JuK and this morning I switched KWrite over to it’s Oxygen icon too.
The macro’s:
KDE4_ADD_APP_ICON(sources “${CMAKE_CURRENT_SOURCE_DIR}/<iconname>.png”
or
KDE4_ADD_APP_ICON(sources “${KDE4_INSTALL_DIR}/share/icons/oxygen/*/apps/<appname>.png”
work perfect for this!
- Some applications cannot open/save: on Windows /C:/ maps to http://C:/ because of a global OS shortcut. Last week there was a fix in Ark for that and just now me & Christoph Feck fixed it for Kolourpaint.
There is an easy way to fix the second bug with not being able to save/extract files in code: switch from KUrl::path() to KUrl::toLocalFile(). This should work on Linux too.
Christoph did a grep on path() ( http://kde.pastebin.com/m7752230f ) which returns 1917 LOC’s in KDE. So if you are an application developer and know for sure that it will always only get local content: please change it to toLocalFile()…
P.S. if you need both online & offline content: this works now in trunk/KDE/kdegraphics/kolourpaint/document/kpDocument_Save.cpp get inspiration from there 
Generally, simply using KUrl based functions is preferred, because it handles both local and remote files transparently. The toLocalFile() is only needed for applications that must work on local files, or must handle the local/remote differences themself.
KSaveFile should probably enhanced to also work with (remote) KUrl, so that the problem in Kolourpaint would be void.
how can an application know for certain that it will only be dealing with local files? Seems beyond the capability of a normal human dev:)