gCLI hopping about

Ethelred

Member
I run with the gCLI as a separate window from the main mafia window. After I start a new session, if I move the gCLI window to a new location, it hops back to the original location as soon as I execute a script. Not sure if this is being done by KoLmafia or by Mac OSX Monterey, as this is a fairly recent OS upgrade for me. Can anybody tell me how to prevent this, or even which program is doing it? Thanks in advance.

System Info:
OS: Mac OSX Monterey v12.4
Java: openjdk 17.0.2 2022-01-18
OpenJDK Runtime Environment Temurin-17.0.2+8 (build 17.0.2+8)
OpenJDK 64-Bit Server VM Temurin-17.0.2+8 (build 17.0.2+8, mixed mode)
KoLmafia: KoLmafia-26513-M.jar
 

fronobulax

Developer
Staff member
A change several weeks ago made it so that when you ran a script focus shifted to the gCLI window. That change was controversial but it has not been reverted. It is possible that is causing your problem. I have half-heartedly tried to revert that change and failed. maybe I should put more effort into doing so...
 

Ethelred

Member
A change several weeks ago made it so that when you ran a script focus shifted to the gCLI window. That change was controversial but it has not been reverted. It is possible that is causing your problem. I have half-heartedly tried to revert that change and failed. maybe I should put more effort into doing so...
A plus vote from me. I find the current behaviour somewhat distracting. Thanks for considering it.
 

Crowther

Active member
I'm not sure if this is related, but I can recreate a window moving unexpectedly. I've been having windows move for a while, but being able to create one on demand is new. I log out during a fight, then log back in with mafia. Then I move windows around. Any window it doesn't matter which. When I complete the fight, mafia finishes logging in and moves all the windows back to where they started.
 

Veracity

Developer
Staff member
A change several weeks ago made it so that when you ran a script focus shifted to the gCLI window. That change was controversial but it has not been reverted.
It was “controversial”? Can you link to the controversy, please? If I run a script, I WANT to see what it prints.

Now, switching focus to an already created window should not move it. For me, the gCLI is a tab, and I would like it to switch to that tab.

If it is not a tab for you (or has not yet been opened), sure - let it create it in the usual initial spot.

If you already have it open somewhere, “switching focus” should just bring it to the front without moving it. Moving it would be a bug. “Switching focus” is not the bug.
 

fronobulax

Developer
Staff member
It was “controversial”? Can you link to the controversy, please? If I run a script, I WANT to see what it prints.

Two previous discussions with comments.



Hola chose to revert the behavior change in PR 759 which is why I am interested in seeing that committed. I cannot find a clean way to just remove the change of focus.

In my case I want to see something else while some scripts are running. At the end of my day I move things out of inventory to my display case. I am not interested in what got moved and I am not expecting any errors. What I want to see is items being removed from Session Results and what remains. After a decade of running KoLmafia I have trained myself to switch to the gCLI before running a script if the output is of interest. So if I am not looking at the gCLI when I run a script that is a deliberate choice. I almost never run scripts by typing in the gCLI - rather I select them from a menu - which certainly effects my preferences for teh UI experience.

Switching focus is a new feature that some people don't consider an improvement.

Moving an already open window when KoLmafia switches focus is undesirable behavior.

My hypothesis, perhaps unwarranted, is that the recent change in switching focus exposed this behavior.
 

fronobulax

Developer
Staff member
The focus change on script run has been reverted as of r26558.

Is the hopping behavior still observed?

(I understand r26558 addresses the trigger and not necessarily the core problem).
 
Top