Closing program gracefully on receiving signal & version control on config files.

[Gunter Schelfhout]

Hello mailinglist,

A few days ago I posted a suggestion at the list 'kde-quality' but probably 
it wasn't the best list to post it to.
Here was my suggestion:

[quote]
Recently I had a spreadsheet open with Kspread when my X-server crashed. No 
input from keyboard or mouse was possible.
As mostly always is the case with our stable operating system, the kernel 
was doing just fine as I was able to login remotely from another computer.
But even then I was in a lose-lose situation.
I could close Kspread before killing and restarting X, or I could go to 
another init-level and go back to level 5.
But either way I would be losing my changes to my opened spreadsheet.

This could be handled better, I'm afraid.

I'm not a developer  but I know a little of system administration to come to 
the next proposal, although I don't know if it is correct, doable or even 
desirable.

Wouldn't it be a good thing that any program which has an open file in a 
dirty state to close gracefully upon receiving a certain and well documented 
signal?
Kspread, Kword, Kate, or any other program should then save the file to a 
default destination directory and set an option so the program knows upon 
next start that there was a saving of the document after receiving a signal 
and closing the application. (dirty bit/option)

Perhaps this could be programmed as central and low as possible (maybe 
kdeinit?), so that the developer of the application doesn't have to worry 
about it.
I know some applications have the autosave option, but even then you would 
lose some data and not all applications which have the opportunity to edit 
some data have this option.
[/quote]

Another thing I was thinking of is that it is a good thing that kde-
applications keep their settings in an plain config-file. It's easy 
accessible for one thing.
There are a lot of advantages which one can think of, but kde could take it 
further by putting every config-file in a transparant way under simple 
revision control.
Upon closing the setting-dialog or explicit confirming the changes, the 
program (via the central libs?) could then save the changes via ie. RCS.
RCS is too simple for advanced software projects, but is more than 
sufficient for revision control of configfiles.
This way, one has audit-possibilities (who still knows what he changed 2 
weeks ago?), a possibility to compare changes (diff's), and more important, 
one can easy undo any changes or revert back to even a much earlier setting.

Well, that was it.

Gunter Schelfhout