Problems with KDE_stat on systems where the default locale is not utf-8

[Christian Ehrlicher]

> Von: Thiago Macieira
> Christian Ehrlicher wrote:
> >Thiago Macieira schrieb:
> >> Christian Ehrlicher wrote:
> >>> Hi,
> >>>
> >>> When QFile::encodeName() can't convert an unicode character into the
> >>> system locale (== all locales except utf-8), the non-convertable
> >>> character is replaced by a question mark. Now that the filename is
> >>> broken, KDE_stat() can't do anything usefull and fails.
> >>> For me looks like KDE_stat() and others are broken by design (when
> >>> system locale is not utf-8) and we need a unicode version of
> >>> KDE_stat().
> >>>
> >>> Any ideas how to fix this issue? Maybe a new class KLocalFile which
> >>> wraps all KDE_foo functions?
> >>
> >> We don't fix that issue. We only support KDE 4 in systems where the
> >> locale is UTF-8. We've announced and told the public about this for 3
> >> years now.
> >
> >The problem is that you don't support plain utf-16 systems like windows
> >at all and rely on an encoded pathname for many low-level functions.
> >If we can't find a fix I would suggest to drop windows support.
> 
> Ah, sorry.
> 
> I thought you meant Unix systems.
> 
No :)
> I recommend we don't use the KDE_xxx functions and we don't use 
> QFile::encodeName(). That won't work on Windows, like you said.
> 
> The Qt API will. Or, alternatively, the Win32 API will (the *W functions).
> 
How fast is QFileInfo in Qt4.5? If it's too slow I'm still for a new small wrapper class for local files inside KDE to handle stat() and others.
Adding ifdefs everywhere isn't a nice solution at all.


Christian
-- 
Sensationsangebot nur bis 30.11: GMX FreeDSL - Telefonanschluss + DSL 
für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a