question about win32 related patched

[Ralf Habacker]

Am Dienstag, 18. Oktober 2005 18:12 schrieb David Faure:
> On Tuesday 18 October 2005 17:58, Ralf Habacker wrote:
> > Unfortunally kdecore/fakes.c, where
> > such functions could  live  is located in kdecore and not lower in the
> > hierachy.
>
> Well it's in the kdecore subdir, but it's a separate lib (libkdefakes)
> So we could very well move it out of there if you need it in lower level
> libs, like, hmm, dcop. If KDE-4.0 uses dbus instead of dcop, I'm not sure
> we'll still have lower-level-than-kdecore libs, but well, moving it out is
> probably a good idea in any case.
>
> > This let me think if in future KDE should have an os extension
> > library (as the win dir for win32 now), which contains all the missing
> > functions and fixes the os related flawing, so that all kde libs can work
> > with a unique set of lowlevel functions.
>
> Well, to me that's not the ideal solution. The ideal solution is to have
> ONE class in kdecore which encapsulates a given low-level function, and
> offer a C++ API for the rest of kdelibs and the rest of KDE as a whole.
> See for instance KMountPoint which encapsulates the whole mess of
> mountpoints (3 or 4 completely different lowlevel APIs).
>
> getHomePath() should be QDir::home() anyway, no?
I saw a casse in dcopserver.cpp where QT's win32 home implementation does not 
fit the recent implementation
 > What else do you have in mind?
KDElibs is very much based on posix systems, which isn't full supported on 
windows. For example the opendir/readdir/closedir() stuff, which is hardcoded 
into several places. On windows the relating functions are named 
FindFirstFile(), FindeNextfile(). 

There are several way to solve this problem. 
	- Use QDir -> platform independent,
        - write a c level wrapper  -> introduce new api level, don't blow up 
code  
        - implement conditional code using Q_OS_...  -> hard to read, blows up 
code 

-> the  best solution seems to uses Qt related io functions as possible, which 
requires some rewriting of internal kde stuff. But what with the stuff where 
no Qt equivalent is there ? I assume that then the second  or third solution 
will be required. 

Unfortunally at now we have to deal with the places where this parts are 
implemented unix like and that is why the win dir exist. 


> > The win dir is currently designed as a set of source files and compiler
> > specific system header in include/<compiler>/... (for example mingw
> > missed some network header), which structure may be used for additional
> > platforms and or compiler.
>
> Actually I'm still hoping that this sort of mess is only needed for win32
> ;) We'll see.
As far as I see this will be true for all os which only supports a posix 
subset. 

Regards
 Ralf