question about win32 related patched
ralf.habacker at freenet.de
Wed Oct 19 10:51:29 BST 2005
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
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
- implement conditional code using Q_OS_... -> hard to read, blows up
-> 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
More information about the kde-core-devel