25 December 2020 Noon

First of all, the sub-process state is irrelevant as is suspension and hibernation. What is relevant is the state of the geany user interface, and surely there is state storage of that if only in RAM.

Second of all, I am talking about a complete power failure, intentionally induced. This is not suspension or hibernation. It is the same thing that would happen if you pulled out the battery while your machine is running only on the battery. The only remedy is a cold reboot with wall power, and that is my underlying intention. In fact, when I do reboot, it is very clear it is a cold reboot. I am not naive or a noob. I understand these systems down to the device level, and have programmed them at the device level. I know the difference between these various power states very well.

Thirdly, I do not understand the meaning of your second paragraph, but if I infer correctly, you are reasserting the incorrect idea that the circle slash persists during execution during normal behavior and the x-terminal can be killed by clicking. Manifestly, empirically, this is not the case, and never has been in my experience, at least with python code which is all I use geany for. The only way to kill an execution is with ^C, closing the window, or any key entry after the sub-sub-process has finished, which closes the window. If it is the developer's intention that the gear icon not be restored immediately (after the x-terminal spawn), that in my view is a bad design choice and is actually a deal breaker for me using your software, should your software actually change to behave that way. Once again, it currently does not. It would be an utterly useless feature to kill a sub-process with an icon click. The existing mechanisms are perfectly fine.

To be clear, the circle slash appears to be only briefly visible during x-terminal spawning (an X-window application not a shell), which itself spawns a shell which spawns the actual program being executed. There are three processes spawned. These three processes are clearly visible in the task manager. If there is already an x-terminal instance running somewhere else, only the shell and the actual program processes are spawned. This is empirical observation and is indisputable.

FourthIy, running multiple x-terminals is not a problem. That is normal behavior and it is still normal behavior after I fixed the issue with my workaround. I'm not going to waste time detaching shells when I have the behavior I want already, which is the behavior geany has always exhibited, and the fix persists across geany restarts.

Finally, my "environment problem" is not a problem. I merely explained why my geany.conf is slightly different from the default. To be complete, I ran 'which sh' and get /bin/sh, which is perfectly fine with me (not a problem), and perfectly explains why I needed to alter geany.conf, which again, is not a problem. In fact, it is preferable to be using a lightweight shell in this context, so the distro packagers made a good design choice.

The geany failure I discovered was accidentally discovered and is very real.

Now with that out of the way, let us proceed rationally.

I am now making sure every night, when I force a power failure, that I am using geany and nothing else.

I can tell you this:

The problem occurs when I run a program and the power surge from that action forces the battery burn down over the edge. The machine shuts off immediately.
Since I ran a program, the geany user interface has momentarily changed the icon to the circle slash at the moment of power failure.
Since the circle slash is momentarily visible in any normal case, at least one of three things must be happening:

a) there is a programmed delay of perhaps half a second before returning to the event loop
b) geany is noting the user interface state change to a disk file, which takes a little time
c) the process spawning is not as fast as it might be for some reason

I do not know which is true, but at least one must be true, for otherwise the circle slash would never be visible in the user interface, because even the slowest decade old machine is truly very fast.

Any of those three possibilities is interrupted by the power fail, possibly signaled to geany by a kernel signal, but with little or no time to do anything about it.
After coming up cold, geany clearly loads state information from geany.conf, and doubtless sets various internal defaults. All complex programs do that. It is common enough that the complexity obscures some of this and some state settings are overlooked, either because they are not in the .conf file or because they are overlooked due to the myriad other concerns that a programmer has to deal with. Mistakes happen. That is reality.
The bad behavior is not remedied by closing geany and restarting it. That is the first thing I tried. There is therefore some user interface state setting somewhere that is reloaded.
The bad behavior is remedied by twiddling with the execute command in the Set Build Commands dialog.
My memory of the sequence of events leading to realization that I had a remedy is muddied, but it is clear that it results from the sequence of programmed actions executed either by clicking 'OK' in the build settings dialog, or by the error processing events that occur when when the gear icon is clicked and the build settings execute command is faulty. This greatly limits the code blocks that need to be examined to determine what user interface state setting is being missed during startup. Those two code blocks are changing settings, one because of a user request. The error processing is not necessarily altering settings, but it certainly might be, and that would seem logical - when you encounter a fault, you usually want to flag it. If so, it may not be the flagging that remedies, but the existence of the flag when the build settings are next saved with 'OK'.
By examining those code blocks you can quickly determine what to look for in the startup code and remedy the problem.

All of this is assuming geany is well designed, and I think it is.

In the meantime, I will continue to burn my battery down every night, and at some point, I will reproduce the error, pay closer attention to the remedy sequence, and report it here.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.