[rfc] Windows integration utilities - KDE::Windows namespace

[Jaroslaw Staniek]

Loïc Corbasson said the following, On 2008-03-28 12:11:
> Hi,
> 
> I have the same fears as Aaron, now some questions on the patch's content:

First, note that all these methods are already in kdelibs (previously in 
kdewin32 in kde3). So it's only question about reusing them instead of 
performing copy/paste.

> 
> 2008/3/27, Jarosław Staniek <js at iidea.pl>:
>>  /**
>>   * @short Windows-specific functions needed for Windows integration
>>   *
>>   * This file provides some Windows-specific functions which
>>   * Qt does not provide access to.
>>  */
>>
>>  /**
>>   \return a value from MS Windows native registry for shell folder \a folder.
>>  */
>>  KDECORE_EXPORT QString shellFoldersPath(const QString& folder);
> 
> I'm also wondering what we need this for, but you certainly know that
> better than I do :-). An explanation would be welcome.

It's already used for accessing "my documents" folder, among others.

KGlobalSettings::Private::initPaths():


     *s_documentPath = g.readPathEntry( "Documents",
#ifdef Q_WS_WIN
         getWin32ShellFoldersPath("Personal")
#else
         QDir::homePath()
#endif
     );

>>  /**
>>   Shows native MS Windows file property dialog for a file \a fileName.
>>   Return true on success. Only works for local absolute paths.
>>   Used by KPropertiesDialog, if possible.
>>  */
>>  KDECORE_EXPORT bool showFilePropertyDialog(const QString& fileName);
> 
> Now, this is maybe against "finer integration", but I do not see why
> we shouldn't use our own dialog, which is way more advanced, as some
> Windows applications also do?

This is pretty well known topic that generated many opinions on what'd be the 
color of our bikeshed ;).
But it's about defaults, and for defaults we use native dialogs where 
possible, e.g. file dialogs;

more interesting dialog is the file-associations dialog "open with", 
apparently from windows (yeah in KDE 2 or so), and now we have two.
But of course below the graphical shell, there is the whole file-associations 
database that already resides on Windows, and I am trying to integrate with 
it. (one of the example is getWin32ShellFoldersPath() as shown above)
Otherwise, from user's POV, it won't be reasonable to use KDE apps here and 
maintain two databases for this kind configuration.

The only unclear part would be why I wanted to export these symbols outside of 
  kdelibs.
As my approach is indeed the same as Aaron has noted - I am trying to hide 
specific APIs, so as a intermediate step I propose to export methods for 
supporting integration in order to make them uccessible within kdelibs, esp. 
from kio and kdeui, but not for apps.

>>  /**
>>   \return two-letter locale name (like "en" or "pl") taken from MS Windows native registry.
>>   Useful when we don't want to rely on KSyCoCa.
>>   Used e.g. by kbuildsycoca application.
>>  */
>>  KDECORE_EXPORT QString getLocaleName();
> 
> Would this be useful to apps other than KSyCoCa?

Again, this is already in kdelibs. And this is actually the same as 
QLocale().name().left(2).toLatin1().

Note, I am asking about location of such code, no about reasons for 
integration with native subsystem.

We have no Qt-based library in kdesupport for integration and I (and 
Christian, at least) cannot see a reason for adding such a small lib.
We have enough of complexity without that.

If we done so, X11 things as Aaron mentioned, including the 
KMacroExpander(discussed recently) or the huge kkeyserver_x11.cpp would go to 
kdesupport too as this is a not 100% crossplatform addition.

-- 
regards / pozdrawiam, Jaroslaw Staniek
  Sponsored by OpenOffice Polska (http://www.openoffice.com.pl/en) to work on
  Kexi & KOffice (http://www.kexi.pl/en, http://www.koffice.org/kexi)
  KDE Libraries for MS Windows (http://windows.kde.org)