how not to save temporary data

yesterday i drew up a diagram of kapplication's methods and how they interact. it looks something like this:

the three groups you see there are session management, focus stealing prevention (mis-labeled "startup notification" in the diagram) and x11 event filter management. that is essentially what kapplication adds to qapplication now. there are a few black and grey boxes at the top. the grey ones are methods don't belong in kapplication and the black ones are deprecated by other classes.

in that category comes KApplication::tempSaveName. this returns a path to which one might autosave a file to. well, we now have KAutoSaveFile for that. however, several applications were abusing it to save data in general. this is a bad idea because there is no guarantee that those files will be there on reboot and it isn't safe against temp file races. in fact, the names are probably easily known as there is no file name substitution at all.

what i saw in several places was essentially a call to doc->save(kapp->tempSaveName(filename)). the intention often seems to be to save the document in a temporary state; in that case i highly recommend creating a MyDocument::autosave() method which uses a KAutoSaveFile internally to do this rather than try and manage it from the outside. you also get, as a free bonus, document recovery so that if something goes bad (crash, power outage, etc) the next time the app starts up you'll have easy and reliable access to the last saved state much like how kmail manages to not lose email drafts in this manner.

anyways, in all of the cases where tempSaveName is used the developer should be using one of:

• KSaveFile
• KAutoSaveFile
• KTemporaryFile

and yes, we need a nice tutorial on using these classes on developernew.kde.org. feel free to join us on friday to author it =) i'll be doing another dbus tutorial and a tutorial on another topic (i've got about 4 lined up to choose from) ...

in other good news it looks like we can get rid of KApplication::notify which was process every single event passed to the application. this should provide some additional speed up to kde4. whether its user visible or not remains to be seen as i haven't done any benchmarking, but it's certainly an easy pick. there's also code in the x11EventFilter than will be dieing soon making that method much faster as well. hooray.