Martin S. Tignor wrote: >>The [Restore] button in the Find Tool dialog collapses the whole app, loosing >>all unsaved data. > > Thanks. I'll fix the bug. > > >>BTW: why do DX apps not catch signals to do some emergency work when an >>unexpected >>signal has been delivered (f. ex. emergency saving data when aborting). > > Hmmm. It always has. It still does on my platform. It won't > attempt to save anything if the net isn't dirty, though. When it saves > it saves (usually) in /tmp and reports the filename to stdout.
Ok, saw that now. I usually do not start DX from a terminal, but with a preset-command in my window manager (Xfce in my case) and stdout is rather hidden that way. Also, what about following: start vpe in terminal window (dx -edit), make a new network without saving it and then press ctrl-C (SIGINT) in the terminal. Boom, vpe gone. No message and nothing saved. Everthing gone! Since SIGINT is not a fatal interrupt, this is not an emergency. The vpe, or dx in general, should pop up a window whether the user indeed wants to quit without saving the data. If the anwswer is "no", vpe and dx should continue without quiting. This holds not only for SIGINT, but for several other non-fatal interrupts. I haven't looked into detail, but briefly noticed that signal catching is scattered over a whole bunch of files in src/exec/dpexec src/exec/hwrender src/exec/libdx etc. It uses "signal(SIGno, handler)" style, but according to the GNU glibc library this is not an optimum way of platform independent signal catching: http://www.gnu.org/manual/glibc-2.2.5/html_node/Basic-Signal-Handling.html says on the use of signal(): ========================================================================= Compatibility Note: A problem encountered when working with the signal function is that it has different semantics on BSD and SVID systems. The difference is that on SVID systems the signal handler is deinstalled after signal delivery. On BSD systems the handler must be explicitly deinstalled. In the GNU C Library we use the BSD version by default. [...] In general, use of these functions should be avoided because of compatibility problems. It is better to use sigaction if it is available since the results are much more reliable. ========================================================================= For my own project I use a C++ class as "SignalHandler.[Ch]", which allows me to say setSignalHandlers(function1, function2); where function1/function2 are pointers to functions for bailout/rescue; bailout handles the non-fatal signals and rescue the fatal ones. Which signals are (non)fatal is also listed and modifiable in these two files. The above function args can either be of "handler signature" or "sigaction signature" (see man sigaction for details on this). This way, signal handling is localized in only two files in the code and not scattered all over the place. Moreover, the code uses sigaction, instead of signal to set signals, which is according to glib manual recommendation. If this sounds appealing, please let me know. My signalhandler code is freely available. Regards, Rob.
