Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Proposal: another window layout #28
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 .
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.
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!
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?
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?
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:
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 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.
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?
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 ?
My next goals are
P.S. If it is accessible - https://github.com/BorisNA/goreviewpartner/projects/1
TLDR: yes! I like the changes, and want them include in the next GRP release :)
So, in details, now:
This work very well now, with the only one box modification :)
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).
So I think this will help differentiate two use cases:
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:
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:
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:
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.
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.
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
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:
Here is a small proof of concept of what I would like to implement:
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?
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.
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.