Jaison Lee lee.jaison at gmail.com
Sun Sep 17 18:04:42 BST 2006

OK, I've attached a candidate KTemporaryFile class. It should be
sufficient to start porting over KTempFile calls. I'm purposefully not
going to describe how it works here because I want to make sure the
apidox are descriptive enough. Please look it over if you are
interested and if you see anything alarming let me now as soon as
possible; I'd like to try and hit the Monday window so I can start
porting calls.

Remaining questions include:
1) Is it worth retaining KTempFile as K3TempFile or should we just get
rid of it? How long is the K3 stuff supposed to be around, anyway?
2) Should KTempDir be renamed to KTemporaryDir for consistency sake?

And since I know *someone* is going to notice and ask about it if I
don't clarify things here: the lack of getters for the
setPrefix()/setSuffix() calls is by design and not by mistake. Given
the following example:

KTemporaryFile temp;

there would be confusion as to whether a call to prefix() should
return "myfile" or "/tmp/kde-user/myfile". For this reason if the
programmer wishes to interrogate the template he should call
fileTemplate() and parse things on his own.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ktemporaryfile.h
Type: application/octet-stream
Size: 5239 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060917/6c716a04/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ktemporaryfile.cpp
Type: application/octet-stream
Size: 2139 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060917/6c716a04/attachment-0001.obj>

More information about the kde-core-devel mailing list