First of all, Geany is a totally volunteer project, people work on it in their own time, and cover a wide spectrum of knowledge and experience. I am likely older and have more coding experience than you (and I like to think capable of being grumpier than most 😁) so there is no need for reports that appear to be rants with bolded text demanding people do things. Volunteer projects don't work that way, it just turns people off helping you.

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.

Of course, but this is irrelevant if Geany is closed and restarted, the value is reset, it is not stored and restored. Since you "know these systems very well" you will therefore know that any state in memory is not restored when a process is closed and started again unless the program stores it and reloads it. Since Geany does not store and reload it the only reasonable solution I can think of at the moment is that it was being restored from hibernation.

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.

WFM, in Geany 1.36 to 1.38 that I have available, if it doesn't work perhaps it was a bug back in 1.32 although I don't remember such a fix. Or whatever terminal you are using has unusual behaviour (see below).

that in my view is a bad design choice and is actually a deal breaker for me using your software

That is of course your personal view and choice, but before you throw your toys out the cot, did you try my suggested workaround, although from your description below it seems the misbehaving terminal application is doing what you want already.

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.

Then you are not spawning xterm, which is the default Geany setting, but some other terminal window application, which is combining multiple invocations into one detached process instead of running separate processes. So this is why it returns immediately to Geany and the icon changes back.

This is information that has been missing from your previous descriptions, although you still havn't actually named which terminal application it is running. Remember I can't see your machine, I don't know anything about it except what you tell me.

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.

This contradicts your statement above, does the terminal application run multiple processes or one process with multiple windows?

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.

So clearly didn't try the workaround, nor (from your description of "waste time detaching shells") even understood it, but clearly the errant behaviour of your terminal application is suitable for you, so that means Geany can keep the behaviour it has always had, and you are also "happy". But it does mean you have a non-standard setup and need to provide additional information when reporting problems.

So having dealt with several rabbit holes, back to the original problem.

Second of all, I am talking about a complete power failure, intentionally induced. This is not suspension or hibernation.

My Linux laptop automatically hibernates if the battery gets low before it shuts down, and since Geany does not store and restore execute icon state, I therefore look for alternatives that can restore state, such as a hibernate.

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

and the likely answer is:

d) the icon is changed at the initial activation and cleared after the terminal application has spawned and created its window and started a shell and started Python, and reported its terminated even if it isn't, all of which will cause a delay and steal cpu cycles from Geany and the X server that does the displaying of the icon and add to the poll loops that exist (IIUC) in the GTK/Glib toolkit communication with the X server and the signal handlers. So the icon being visible for a short time is pretty likely without any explicit coding.

After coming up cold, geany clearly loads state information from geany.conf ... Mistakes happen. That is reality.

Yes, which does not include the state of the execute icon, that is initialized with g_new0() which returns cleared memory. Sure everybody makes mistakes, but unless someone manages to point out where the code can avoid starting with the state value 0 then something else is going on (like weird terminal apps above), see build.c.

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.

I hear you but until either somebody replicates it, or points to the code path (see above) its impossible to know whats happening.

So pending that I am working on the basis that "something else" is happening, however from the information provided its not possible to say what.

remedied by twiddling with the execute command in the Set Build Commands dialog.

Yes if "something" causes the execute state to be out of sync it needs to be "tricked" into changing state since the process its monitoring no longer exists and so its state will never change. Just lucky the code clears the state on an error, even though theoretically its doesn't need to. That does not help finding the cause though.

By examining those code blocks you can quickly determine what to look for in the startup code and remedy the problem.

Thank you for volunteering.

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.

As noted above, the remedy is understood, its how it gets it out of sync that is interesting and useful. I doubt anyone else is going to flatten their laptop batteries to try to replicate the exact conditions, so yes its only you who will reproduce it. Try to provide as much information as possible when it happens.

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