Replacing KTempFile with QTemporarFile

[Friedrich W. H. Kossebau]

Am Sonntag, 4. September 2005 13:16, schrieb Andras Mantia:
> On Sunday 04 September 2005 14:09, Albert Astals Cid wrote:
> > The new QTemporaryFile in class seems a good replacement to
> > KTempFile, but with the problem that it uses QDir::tempPath() as path
> > to create the temp file so it can not be used to create files like
> > KTempFile does in $KDEHOME/tmp-$HOST/appname/
>
> Speaking of tempfiles, I have an idea for KDE4, which I'm actually use
> already in Quanta.Some applications create temporary files whose names
> are user visible. Even if they set some name for the files it's still
> ugly as it looks like:
> quantaSOMERANDOMSTRING.extension
>
> where SOMERANDOMSTRING is very ugly. So instead of that I create a
> temporary directory (with a random name) and a file inside which has
> the name and the extension exactly how I want.

One step into a good direction, good idea I think. :) 

May I add another idea? What about piping such temporary files directly e.g. 
via kioslaves? We do not really need to store the data in the filesystem 
(within KDE), do we? I once got this idea when looking at the treatment of 
attachments within KMail. Instead of some temporary file with a cryptic path 
I feel something which also tells about the source of the data would be a 
little better. Like "protocolname://dcop-id/app-id-for-bunch-of-data". But 
all those ids usually are cryptic, too:
"lafp://kmail/Local 
folder/KDE/Core-Devel/200509041417.01264.amantia at kde.org/nextPart2336858.90l8VcQNhB" 
is not too understandable. :( Perhaps someone could improve this idea?

This (and all the other protocols, like system:/) makes me think we need an 
extension to the url concept, adding user understandable, localized names in 
parallel to the technical names. Those names will not be editable, only used 
for display (most people don't type in the url bar anyway), in an alternative 
beautyful-name bar. Problem is how to ensure unique names and avoid faked 
names...

Another idea would be to treat such piped files as freshly created files, like 
one gets e.g. with starting KWrite and typing into the empty buffer or a 
KWord document from a template. Only difference to those would be that these 
files are already given a file name but no location.

Piping between kde/gui apps seems to be rather unused. Is there a reason for 
this?

Regards
Friedrich
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20050904/afb9f2da/attachment.sig>