[QWK] Proposal: paths notation

David Faure dfaure at klaralvdalens-datakonsult.se
Wed May 7 12:34:18 BST 2003

Hash: SHA1

On Wednesday 07 May 2003 12:29, Jarosław Staniek wrote:
> - it is not used inside places like in 
> QPixmap::QPixmap( const QString & fileName, ...)
> QImage::QImage( const QString & fileName, ...)
> and most notable:
> QFileInfo::QFileInfo(  const QString & file )
> QDir::QDir( const QString & path, ...)

On Unix all those methods _do_ call QFile::encodeName().

But you're talking about the commercial Qt on Windows, maybe that one doesn't....
What sense does QFile::encodeName() has on Windows then?

> while it is expected that these functions can properly encode paths names 
> and will load files.

They do, on Unix at least.

> QFileInfo info( QFile::encodeName(fname) );
>                  ^^^^^^^^^^^^^^^

That's definitely wrong. QFile::encodeName returns an 8-bit cstring, whereas
QFileInfo takes a QString. And takes care of calling encodeName already,
on Unix at least.

> There are many places there I had to put it. More, QFile::encodeName is just 
> empty call on non-win32, at least today, 

Ah, that's why. So IMHO the proper fix would be to get TT to add
QFile::encodeName() calls in the Windows version, so that it's possible
to implement such a "conversion method" that works there too?
Did you try contacting qt-bugs about that?

> so it seems to be redundant in the
> code for many free software programmers.

You mean for Qt-on-Windows programmers (*not* free software then).
It's not a redundant call on Unix.

(I think the other solution, introducing new conversion methods, is very confusing
and unnecessary).

- -- 
David Faure -- faure at kde.org, dfaure at klaralvdalens-datakonsult.se
Qt/KDE/KOffice developer
Klarälvdalens Datakonsult AB, Platform-independent software solutions
Version: GnuPG v1.2.1 (GNU/Linux)


More information about the kde-core-devel mailing list