Closing program gracefully on receiving signal & version control on config files.
gunter.schelfhout at telenet.be
Fri Dec 5 13:47:59 GMT 2008
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:
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
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
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
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.
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
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.
More information about the kde-core-devel