Proposal: another window layout

I wonder if it would be better to change layout. I've tried to look at the code, but, unfortunately, I don't know Tk (I even tried - but it was terrible at the moment). And since the window creation is hardcoded - and not a UI res - I don't know if it will break logic. Of course it is doable but will take a significant amount of time.

We usually have 16:9 monitors, so if one want to open both goban and graphs, he should minimize it, overlap, continuously switch etc. May be it will be better to place text with comments to the right making the main window very narrow. In this way it will be possible to move graphs below.

Buttons will be below to minimize mouse movement to graphs and back.

Oh, and may be it will be good to formalize text in comments, make it shorter, they just don't fit in the box. And scrolling is not good when evaluating different options. Since words are always the same it will be rather easy to understand, and may be even easier, since attention will be focused directly on numbers .

Hi!

Thanks for your comments. I agree that the comment parts is really not good / not satisfying at the moment.

In the development version, I started implementing a "table" popup similar to what Leela GUI shows (a table with data for all variations). This might replace completely the two comments boxes in the future.

Also, I started to separate "values" and "text formatting of the values" (values are now all stored as RSGF properties) so that it is easier to display those values in a efficient way.

One of my objectives is to make it easy to create a "RSGF viewer only" software without the analysis part. I am considering making one for android in python/kivy. One could also imagine an online viewer in javascript.

But regarding the current tkinter interface, yes it sucks, and in fact, it would not be too difficult for me to adjust to your proposal. But I would like to wait until no more features (especially visualization features) are added to GRP. The currently terrible UI is a result of me rushing to build this UI without really knowing where I was heading :)

When GRP will be stable in term of features, we will know the big picture, then it will be time to adjust the interface.

Anyway, your suggestions and proposals are welcomed!

Hi!

I see, to make a modularized app is always a good idea. If you can push RSGF for "standartization"... Using an android application to review a game on a tablet after server-based analysis would be great!

Anyway, it was easier than I thought, take a look at this? https://gist.github.com/BorisNA/20cac069bd16c1142d177252df950478 I dont't know how to use all this push/pull/git things - yet - since I've last coded an eon ago, when there were CVSes and SVNs.

As I have said, usually I place graph window below the main one and use it to navigate to my most serious errors, or points of no return, when probability dropped below 50%. With this layout it works better.

As for ideas, I don't know if it is a good place to discuss them here - may be reddit or somewhere else?

I believe we need some option to select level of the bot. If, say, you are 25k, then the "best move" from a 5d bot has a little relevance - you wouldn't ever be able to implement all this stratagems and tricks. It would be better to use a lower rank for review - say 10k or 5k. So, we will need different options for the same bot, to select rank (weights for leelaz, some other ways for other bots - don't know if it possible)
It would be interesting to have both best moves from max rank and low rank bots shown simultaneously. It definitely will give some food for thought.
Also it would be interesting to highlight the best network move and the best monte-carlo move (that is, "human" and "computer" ones). Don't know if it is 100% correct, but this is how I understand these probabilities.
Now I just browse through the table in leela UI to find the max network move. Luckily I can press on this move and it will be shown - I belive it is not coded into your table yet.

Hi!

Thanks for taking the time to dig into my code and coming with a concrete proposal!

I like this layout, I think it is better than the current one. I see two things that could make it even better:

To have only on comment box instead of two boxes:
- When displaying a move position, the comment box shows the content currently displayed in the left side comment (Move 2, White to play, in the game, white played q4...)
- When moving the mouse pointer over one of the variation, the comment box content is replaced by the data related to that variation (Black/White win rate for this variation...).
- When the mouse pointer get out of the variation, the comment content box is reinitialized to the position comment. This is an easy way to double the available space to display comments
For the graph, to have it in a "lower pane", as in you previous layout, and that pane can be opened or hidden easily via a button or something like this.

As for ideas, I don't know if it is a good place to discuss them here - may be reddit or somewhere else?

If this is OK for you, I think L19 is a good place. This is where I picked most of the idea for GRP. I will put a screen shot of your proposal there to get feedback.

I believe we need some option to select level of the bot. If, say, you are 25k, then the "best move" from a 5d bot has a little relevance - you wouldn't ever be able to implement all this stratagems and tricks. It would be better to use a lower rank for review - say 10k or 5k. So, we will need different options for the same bot, to select rank (weights for leelaz, some other ways for other bots - don't know if it possible) It would be interesting to have both best moves from max rank and low rank bots shown simultaneously. It definitely will give some food for thought.

I agree that for a 25kuy player, being presented with 5d bot plays and 15 moves variations is of little interest! For 15kyu and weaker players, the best option at the moment is probably GnuGo. But my opinion is that providing different levels is more the job of bots developers than GTP, it is outside of GRP scope. At least for the time being. If in the future, the GTP protocol is updated to allow querying the bot for good plays and "not so good play", GRP will follow and take advantage of those features.

Also it would be interesting to highlight the best network move and the best monte-carlo move (that is, "human" and "computer" ones). Don't know if it is 100% correct, but this is how I understand these probabilities.

I am not so sure if one can say "network move ~ human move". At least this is not true for Zero type bots likes Leela Zero anymore. Do you mean value network or policy network? Anyway, what can be done is to implement a way to sort the variations: the user clicks on the "value network" column header, and the moves are sorted according to "value network" value.

Now I just browse through the table in leela UI to find the max network move. Luckily I can press on this move and it will be shown - I belive it is not coded into your table yet.

It's in my TODO list already (moving the mouse pointer on the data display the variation)

Could you look at the https://github.com/BorisNA/goreviewpartner/tree/dockt ? I've coded some number of GUI - cough - changes. Do you think that any should be pulled to the mainstream?

horizontal UI as was in the previous iteration
docked table (I have tried to code it responsibly, so implementing docking toggle or config option should be easy). You can switch table<->comment window with the "Table/Comment" button
compactified table to fit in the window - removed wordy comment, added colored delta, compactified columns. My main motive was that when reviewing usually I don't read words, it is very time-consuming, but look at the numbers. This can differ though
changed some words on buttons to compactify and made them stay in the UI but enable/disable as needed (as opposed to hiding)

My next goals are

refactor table to get rid of falshing due to killing and creating table labels
decrease font size in graph (it takes too much space IMO) and may be move graph selector from the top to the vertical button bar on the left (I want to make it fit under the main window, so I try to maximize useful graph size vertically)
maybe (?) add font and font size to the config - I have 150% font scaling at my work computer under Windows. some parts do look funny as compared to the default font size
add "config file" switch to simplify launching from the git folder

P.S. If it is accessible - https://github.com/BorisNA/goreviewpartner/projects/1

Hi!

I've coded some number of GUI - cough - changes. Do you think that any should be pulled to the mainstream?

TLDR: yes! I like the changes, and want them include in the next GRP release :)

So, in details, now:

horizontal UI as was in the previous iteration

This work very well now, with the only one box modification :)

docked table (I have tried to code it responsibly, so implementing docking toggle or config option should be easy). You can switch table<->comment window with the "Table/Comment" button

It's not really what I had in mind when I though "dockable" (what I had in mind would not work anyway) and I think your solution is good (see other comment below).

compactified table to fit in the window - removed wordy comment, added colored delta, compactified columns. My main motive was that when reviewing usually I don't read words, it is very time-consuming, but look at the numbers. This can differ though

So I think this will help differentiate two use cases:

On one side, some user will need the "wordy comments" (mainly new users)
On the other side (after the user got some experience with reviewing games with bots) then compacted information is best

My opinion is we should keep being very wordy with comments, and try to be as much "to the point" as possible with the table.

I the past (last year), I would receive a lot of messages of Reddit/L19 users that would ask for clarifications about the data (win rate, and meaning of delta graph) so I decided to make it extra clear by being very wordy. It was also useful to me, because at some point I got myself confused with my own calculations :D (the python code making that calculation is heavily commented for that reason).

It is like GRP is a tool for gamers, with those gamers frequently being over forty years old, so for them, plain word explanation is best. But then, some of the users will turn into "hardcore gamers" that can play and review several games per day. And for them, definitively, a condensed display of data is best, and the table can 100% fulfill that job. And then, it becomes clear one only need either the first one, either the second one, so "toggle" mode is good idea.

With that in mind, we should:

make sure at least all info currently in comments is also available in the table mode (except for first move info, like command line, player names...), I think it is the case now
make it short, with renaming the column header with acronym as you did (maybe with the header meaning detailed in status bar when mouse pointer over the header). But maybe the acronyms I used as SGF properties are not so good, so maybe only WR, VN, MC, PN and PO is enough (I wanted at least 3 letters long for those acronyms, to make them stand out as non standard properties).

Maybe there is a way to only keep the table, because it already indicates the game move, and the bot best move. Maybe we could add a second line in the table below the bot best choice to indicate the delta. Sort of:

MOVE		WR	MC	VN	PN
A	q17	48%	47%	49%	34
A	c4	50%	62%	45%	52
ΔA		-2pp	-15pp	-4pp
B	q4	44%	43%	44%	14

changed some words on buttons to compactify and made them stay in the UI but enable/disable as needed (as opposed to hiding)

Yes, hiding the buttons is just a bad idea, I don't remember why I chose that in the first place.

For your next goals:

refactor table to get rid of falshing due to killing and creating table labels

That could be hard to achieve. One way could be implement a "excel like" table (made of plenty of Entry widgets) whose content is changed. Or maybe there is an already existing tkinter widget somewhere on the internet for that.

decrease font size in graph (it takes too much space IMO)

It's hard to decide for what would be the good font size. Apparently, there is no reliable way to get a pixel to mm ratio. If we had that info, we would set for example, 3mm per letter, or even let the user decide in the settings.

may be move graph selector from the top to the vertical button bar on the left (I want to make it fit under the main window, so I try to maximize useful graph size vertically)

Oh? I fact, I tried to maximize the horizontal space available for the graph to be displayed. Because with one game having ~300 moves, the columns get very thin. My display is 1600pixel/39cm wide, so the column for one move is around 5px/1.3mm, and it's hard to get the mouse pointer right on it. And most laptops have display smaller than mine. What would be a killer feature is the possibility to zoom in/out using the mouse wheel :D

add "config file" switch to simplify launching from the git folder

Definitively yes for this one. Would be useful not only for debug, but also for batch analysis

But there is one single thing I don't like with the proposal: I think we should keep the tool bar at the top:

that's what most people are used to (like in all web browser, gogui, image gallery viewers, file explore, microsoft office...). Having in mind the average of Go players, I try to keep things usual for them.
it's reducing the space available for the status bar, so when moving the mouse pointer around, quite frequently, it triggers displaying a status message that won't fit on one line, and because the cut between first and second line does not appears always at the same place, the interface resize itself horizontally. On my setting (with status message in french longer than the English ones) displaying the sequences from the table is almost impossible. (plus sometime, the interface try to expand/shrink in-definitively to the point I can only close it, but it must be something unrelated that can be fixed).

Here is a small proof of concept of what I would like to implement:

from Tkinter import *
app=Tk()
Label(app, text="tool bar").pack()
paned = PanedWindow(app,relief=SUNKEN, orient=HORIZONTAL)
paned.pack(fill=BOTH, expand=1)
paned.add(Label(paned, text="Goban1",relief=SUNKEN,width=50,height=20))
paned.add(Label(paned, text="Goban2",relief=SUNKEN,width=50))
paned.add(Label(paned, text="Comment/table",relief=SUNKEN,width=20))
Label(app, text="status bar").pack()
app.mainloop()

It creates 3 areas that are re-sizable using mouse pointer, it can be re-sizable to the point where the first goban just completely disappears (some user wishes they could totally hide that left side goban).

Can I modify your code then make a PR to your branch? then we keep making UI modifications on your branch before merging everything back to the main branch?

Hi!

I somehow imported your branch on my project (I am not sure how I did...) and then made the modification to use PanedWindows. The result is there: https://github.com/pnprog/goreviewpartner/tree/dockt

I think it is pretty good already!

Sp I ended using two panedwindows, so that the goban shrink/extend keeping the same ratio (when the left panel is extended/shrinked) and that all three part shrink/extend keeping the same ratio when the whole windows is shrinked/extended.

The table flashing is a bit annoying (it is slow). I think one workaround will be to re-use all the labels that constitute the table.

Hi!

decrease font size in graph (it takes too much space IMO)

It's hard to decide for what would be the good font size. Apparently, there is no reliable way to get a pixel to mm ratio. If we had that info, we would set for example, 3mm per letter, or even let the user decide in the settings.

I was able to improve on that, by adjusting to the same font size as the tkinter widget. So now the border width is fixed at a size equivalent to 4.5 characters and we can be confident it is reasonnably small. Maybe I will decrease again for top and bottom borders.

pnprog / goreviewpartner

Proposal: another window layout #28