Lizzie cannot remember Panel -> GtpConsole detached window is checked

[NTUST-MITLAB]

Normally I'd detached the Gtp Console so it can be resized and moved to a convenient location as a separate window.

After updating to 0.7.4, Lizzie cannot remember it has been opened, and have to check View -> Panel -> Gtp -> GtpConsole (or use hotkey alt+E) every time opening Lizzie.

[hope366]

There are the following eight types of "panel display", but only "status" and "Toolbar" are memorized for changes, and others are not memorized.
・Sub board
・Win rate graph
・comment
・Change chart graph
・Agehama
・status
・GTP console
・Toolbar
I think it would be more convenient if lizzie remembers "display ⇔ hide" and the size of the window for all these 8 items.
In addition to this, you can now switch the scaling of the sub board by clicking the center, but it would be convenient if this function could also be used in the winning percentage graph.
It may be useful for lizzie to remember about resizing with a center click as well.

[NTUST-MITLAB]

There are the following eight types of "panel display", but only "status" and "Toolbar" are memorized for changes, and others are not memorized.
・Sub board
・Win rate graph
・comment
・Change chart graph
・Agehama
・status
・GTP console
・Toolbar
I think it would be more convenient if lizzie remembers "display ⇔ hide" and the size of the window for all these 8 items.
In addition to this, you can now switch the scaling of the sub board by clicking the center, but it would be convenient if this function could also be used in the winning percentage graph.
It may be useful for lizzie to remember about resizing with a center click as well.

Gtp Panel display used to be default true (IIRC before 0.7x?) when print_comms config can still be set, but was turned off to speed up the loading, and again a toggle function is added, and it would be toggled on showing the Tuning initialization instead of just a long "Engine Loading" waiting. Also when the Gtp Concole window reopened, Lizzie still remembers its previous location and resizing, hence some of the information of the window is kept already. All the components are there to make it a full-on panel (maybe an additional flag? and make Gtp Console visible at the right moment). Sometimes I can trick it to "keep the window" when Lizzie was hanged, and I process killed it without normal exit, which I believe bypasses the toggle in some earlier version.

The Panel UI with LizzieMain can have more improved layout management and make customization better and more intuitive.

[kaorahi]

You can check Settings > Engine > Print Engine Log so that GTP console is opened at startup. I think Lizzie never remembers the visibility of GTP console in the current and the past versions. See also #778.

[NTUST-MITLAB]

I've applied these changes, now they are remembered via recording their flags in the persist file. And I might remember incorrectly about the GTP console visibility was retained in the past (maybe those times I just happened to have config with the Print Engine Log set to true, sometimes I used diff and edit them between various test builds with different config files)

BTW, when I regenerated new config.txt and persist files with these fixes, checking Settings > Engine > Print Engine Log doesn't automatically open the GTP console at startup. It is now only controlled by settings in View > Panel.

[hope366]

Toggle large winrate graph by center-click for #777 #779
After applying this, It is now noticeable that lizzie fails to start. The exact frequency of occurrence is unknown as we have not done many experiments yet. Also, it is difficult to identify the conditions of occurrence.
It is sensuously about 4 to 5 times with dozens of activations. It is unlikely to occur when lizzie is turned on and off frequently, and it is likely to occur when it is started after a certain period of time.
How it fails ... Running lizzie puts a heavy load on the computer, so it seems that analysis is turned on internally, but the suggested movements are displayed on the board. not.
No operation will be accepted, and you will have to forcibly terminate it with the task manager.

This bug is ...
Fix issues in #772 (click in panel UI, etc.) #773
This has been applied before.
So ...

I dare to use slightly unnatural coding styles for avoiding conflicts with #773.

I'm curious about this statement by @kaorahi.

[kaorahi]

@NTUST-MITLAB
After my patch, "Print Engine Log" is independent of the visibility of GTP console. If you check it, you see both the inputs and the outputs of the engine. Otherwise you see only the outputs.

BTW, have you also experienced similar freezes as #777 (comment) ?

@hope366
My words "unnatural coding styles" are only on the "style". They do not affect the "meaning" of the code. The added lines in #779 should never run until you click the center mouse button. So I have no idea at present.

Does #779 really cause the hang-up? Have you tried the same operations sufficient times without #779? What are your settings (Panel UI, etc.) and operations? Can you read console outputs when Lizzie freezes? I mean both GTP console and Windows console (a.k.a. "command prompt") where you typed java -jar "target/lizzie-*-shaded.jar".

I would like to know any hints.

[hope366]

Since Lizzie-v0.7.2 was released, I have started lizzie in countless numbers, v0.7.3 and v0.7.4, but I have never failed to start it except for a setting error.
I don't know if # 779 is the cause, but it's clearly more frequent after applying # 779 (from yesterday to today).
I started it about 100 times from yesterday to today, but I got the same error about 4 to 5 times.
It may occur at intervals of about 10 times, or it may not occur even after 50 times or more.
I've tried about the same number of times in normal mode and panel UI mode, but so far all the errors have occurred in panel UI mode.

The screenshot below shows what happened when this bug occurred, but the GTP console and command prompt display looks the same as when it started normally.However, lizzie does not accept any operation.

By the way, while testing for this bug, I ran into another first-time bug. Below is a screenshot. The GTP console was set to show, but it doesn't seem to show due to this bug.
It failed to start, and the following display was displayed. When I operate the menu bar, they appear to overlap and do not work at all.

The error statements displayed on the command prompt are actually much larger. Every time I grabbed lizzie with the mouse and moved it, it seemed that a lot of similar displays were added.

[kaorahi]

Thanks for the report! It gave me useful hints. Something will be wrong about EDT. I'll try to debug it.

https://stackoverflow.com/questions/3435994/buffers-have-not-been-created-whilst-creating-buffers#comment3583777_3435994

[kaorahi]

@hope366, would you show the line 245 in your BoardRenderer.java? I guess it is this.

    int width = Lizzie.frame.getWidth();

[hope366]

Yes, as you say, line 245 of BoardRenderer.java is
int width = Lizzie.frame.getWidth();
It has become.

[NTUST-MITLAB]

@NTUST-MITLAB
After my patch, "Print Engine Log" is independent of the visibility of GTP console. If you check it, you see both the inputs and the outputs of the engine. Otherwise you see only the outputs.

ok, this makes sense that the event log and console window are controlled independently.

BTW, have you also experienced similar freezes as #777 (comment) ?

Not actually, at least not failed to start. I've applied to #780 to this point, but also one of my own "fix" (the reversion of 6a339f0, but it shouldn't affect anything else, but just an extra drawstring).

I did notice something after 0.7.3, that it sometimes lagged or temporarily froze and doesn't refresh the mainboard immediately using right-click and left-click to navigate the Variation Tree, but it worked fine and reacted immediately if the mouse clicked on the mainboard. Not sure what caused it and it only occurred occasionally.

[kaorahi]

Would you try https://github.com/kaorahi/lizzie/tree/for777_EDT (a628068)? It may or may not fix the hang-up.

[hope366]

I tried a628068.
Before applying this PR, it hung-up with a probability of 50% or more, but after applying it, it succeeded in starting 10 times in a row. It is estimated that the startup will be successful with a probability close to 100%.
What an amazing piece of technology to be able to bug-fix so quickly!

[hope366]

#777 (comment)Thank you for creating a PR to solve this.
However, I'm sorry that this bug has an extremely low incidence rate (probably), so it's hard to be sure that this PR is valid.