KDE_ macros in kde_file.h

[David Faure]

On Monday 09 October 2006 20:35, Jaison Lee wrote:
> Most of the KDE_* macros defined in kde_file.h (KDE_mkdir, KDE_open,
> KDE_rename, KDE_stat, etc.) are not used at all, and those that are
> are used sparingly (sometimes by only one class/function). 

They are very much used AFAICS... E.g. KDE_open is used in the following files:

./kioslave/file/file.cc:280:    int fd = KDE_open( _path.data(), O_RDONLY);
./kioslave/file/file.cc:402:    int fd = KDE_open( _path.data(), flags);
./kioslave/file/file.cc:601:                    fd = KDE_open( _dest.data(), O_RDWR );  // append if resuming
./kioslave/file/file.cc:614:                    fd = KDE_open(_dest.data(), O_CREAT | O_TRUNC | O_WRONLY, initialMode);
./kioslave/file/file.cc:791:    int src_fd = KDE_open( _src.data(), O_RDONLY);
./kioslave/file/file.cc:808:    int dest_fd = KDE_open(_dest.data(), O_CREAT | O_TRUNC | O_WRONLY, initialMode);
./kioslave/ftp/ftp.cc:2265:  iCopyFile = KDE_open( sSrc.data(), O_RDONLY );
./kioslave/ftp/ftp.cc:2342:    iCopyFile = KDE_open( sPart.data(), O_RDWR );  // append if resuming
./kioslave/ftp/ftp.cc:2352:    iCopyFile = KDE_open(sPart.data(), O_CREAT | O_TRUNC | O_WRONLY, initialMode);
./kio/kio/kmimemagic.cpp:1375:  if ((fd = KDE_open(fileName.constData(), O_RDONLY)) < 0) {
./kio/kio/authinfo.cpp:203:  return KDE_open( ef, O_RDONLY );
./kdecore/kconfigbackend.cpp:1056:     int fd = KDE_open( QFile::encodeName(filename), O_WRONLY | O_TRUNC );
./kdecore/ksavefile.cpp:187:   int fd2 = KDE_open( copyname,
./kdecore/ksavefile.cpp:257:   int fd = KDE_open( filename, O_RDONLY );
./kdecore/ksavefile.cpp:304:        int fd = KDE_open( filename, O_RDONLY );
./kdecore/ksavefile.cpp:368:   int fd = KDE_open( filename, O_RDONLY );
./kdecore/fakes.c:28:#define KDE_open open
./kdecore/fakes.c:220:      fd = KDE_open (_template, O_RDWR|O_CREAT|O_EXCL, 0600);

Granted, some/most of those could use QFile instead, but I don't see the point;
don't fix it if it ain't broken as they say. KDE_foo is mostly for kdelibs itself, for
low-level performance-critical code. Applications can use QFile or KIO indeed.
We had a thread about this already iirc.

> Seeing as 
> how they all have Qt equivalents (not to mention KIO equivalents in
> some cases) is there any reason for keeping these around anymore?
Which KIO equivalents? KIO is asynchronous and delegates to slaves,
and we can't use that from kdecore or from kioslaves themselves.

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).