I second this. This is more intuitive and visually less taxing.

I've hacked together a quick implementation of this suggestion:



Left is the suggestion and right is current implementation. How is this intuitive?

Personally, I like the current implementation better. I don't feel that strongly about it, though.

_________________
be immersed

It isn't. There needs to be a line between two highlighted nodes. The left one doesn't have a line. Q.E.D.

Personally the only problem I have with the current tree is the spacing is too wide. In a heavily commented game, too much of the time I just see a set of horizontal lines running off the screen to the right. Is it possible to add an option to adjust the spacing between nodes?

_________________
Dave Sigaty
"Short-lived are both the praiser and the praised, and rememberer and the remembered..."
- Marcus Aurelius; Meditations, VIII 21

or a collapsible tree?

That would work! Actually, I think the heart of the problem really is how best to display a commented game with a large number of variations. There is no need to lay out the entire game tree all the time, but to only display the relevant variation as one scrolls to the move that has that variation.

This would solve all problems...

Left is better, provided that if you press the right arrow key, the alternate variation is highlighted and activated.

But, I'm not advocating an either-or approach. As I said before, it's just my personal preference. I'm sure there are plenty of others agree or disagree with me. However, it'd be nice to have the left implementation as an option.

There's a (not so) secret setting file (at '%APPDATA%\Sabaki\settings.json' on Windows, '~/.config/Sabaki/settings.json' on Linux, or '~/Library/Application Support/Sabaki/settings.json' on macOS) and the secret setting 'graph.grid_size'. You can set the value to a smaller number to decrease the spacing between nodes. Is this the option you want to include in the user interface?

Semi-related to the discussion on the move tree, I'd like to point out that I rarely use the move trees when I'm using CGoban or Multigo. I rely almost entirely on the navigation arrows - I like to focus on the board and not the tree. To switch between branches, I often just place a stone on the board where the alternate move is played, and the branch is automatically switched.

With Sabaki's design, I'm more inclined to focus on the game tree now since there are no arrow buttons to skip ahead a few moves.

So I guess it's more important that the game tree looks clean to navigate through a tree having several branches.

_________________
be immersed

Hi yishn,

Some ideas for consideration

CGoban, horizontal, non-collapsible, no-context-menu tree:MultiGo, vertical, collapsible, context-menu tree:Suggestions:

• Option to toggle between horizontal or vertical tree ( some people may prefer either one ) ;
• Option to display and stones in tree ( some people may prefer B & W stones to dots ) ;
• Option to display move number on each node ;
• Option to vary and stone sizes ( some people may prefer tiny dots, others not so ) ;
• Option to toggle between collapsible or 'fixed' tree ;
• Context menu (Right-click) on each node for the mouse ( maybe not available for one-finger-only devices ) ;

I regularly use the tree in MultiGo and CGoban -- different people have different preferences.

Yes, I know. I just saw this as another opportunity to express the fact that I'd like to see navigation buttons for this editor

My preference may not be that popular, I suppose.

_________________
be immersed

It's not very comfortable to use the game tree to navigate, I agree. I like to think that the game tree serves a similar purpose as a mini map in video games, you can see where you are and where you can go, but navigating is easier using, e.g. the keyboard or the game board. You can use the up/down arrow key to skip back/ahead a few moves or use the slider that comes with the game tree.



Dear EdLee, implementing a horizontal tree is a lot of work, keyboard shortcuts/menu labels need to be switched, making the code more complex and less maintainable, while having no or few benefits. This is a typical bikeshedding example.

Black and white stones in tree: That's funny on a black background. Also currently, Sabaki colors commented nodes and hotspot nodes in a different color. What do you propose to do with them? Also, IMHO it's good style (and it is almost always the case) to alternate between black and white moves in a SGF file, so displaying the move color in the tree is kinda unnecessary.

Option to display move number on each node: What is even a use case for this one? Also, it would make the nodes bigger and we have even less space for variations.

Option to vary node size is a good idea.

I haven't decided whether to make a collapsible tree or not.

Last but not least, game tree nodes in Sabaki do have a context menu.

SmartGo for Mac has an interesting way to show move numbers on nodes. It only shows them on branch points, and then only on the main line, and next to the nodes. It also collapses paths between "interesting" nodes. You can still click on the black and white "mini-nodes" that are in between numbered nodes.

I really like this very clean style.

Hi yishn,

We're here to suggest ideas, brainstorming ;
these are mere suggestions. If you or enough people like an idea,
and it's reasonable to implement, it's your choice to do it.
If an idea is not popular or very difficult to do,
it's also your choice to ignore it or shelf it for now.

These are all volunteer, 'free' ideas.

No need to 'dear' me.

I'm not crazy about the black background,
and I'm not crazy about 'extraneous', gratuitous use of colors, either.
( Feature-itis or color-itis. )

Good luck.

That's a very interesting idea and an elegant solution to showing move numbers without redundancy! I really like it, even if I can't say whether I like the mini-nodes or not... However, to implement something like this requires to rewrite the whole graph drawing logic myself, which I may or may not have plans for.

SmartGo's implementation of game trees is, in my opinion, absolutely the worst. It's visually far too busy and too complicated to look at, not helped by the fact that it's displayed horizontally on the bottom, which serves to constantly distract your attention from the board. To me, it's simply aesthetically appalling; just look at the huge jumble of lines going every which way. The damn thing looks like a destroyed spider web clinging to a three branch. No thanks.

After seeing this comment I went to try and see what smartgo on windows does (it's not as snazzy as the Mac version). I've had the program for perhaps ten years, and today was the first time I saw the move tree. Basically, I'm with Kirby, I like to navigate the variations with cursor keys and find the move tree irrelevant.

If anyone here is a talented graphics designer, I'd be willing to pay some money to have he/she design some stones for Sabaki. I'm thinking maybe a set of shell and slate and a set of Yunzi stones would be a nice addition.

Anyone else think this is a good idea and be willing to chip in?

P.S. I like the default stones very much; I simply like some more options.

First of all: Awesome work!

I like the ease of use and the look of the board. Good integration with Leela (which the stand alone application did always crashed on my mac).

Some bugs I found (mac osX 10.11.6): When closing the last Sabaki window, I can't use File>New nor File>New Window; I must use Window>New Window or select another application (web browser, desktop, or else...) then re-select Sabaki. This is not critical, as the program is usable, but not user friendly.

If I'm not mistaken, Leela, and probably other engines, are able to estimate winning probability, it possible to have the option to have that displayed somewhere (like Black 30% - White 70%, or Black (----------| 70% |ooooooo---)White ) ?

And, while suggesting stuff, maybe reviewing an existing sgf game? For exemple: You load your game, attach the engine, then choose "Review Game (white/black/both)". The engine would give the move it would have played on each moves for the selected color, indicate where the % of winning dropped the most, and give 5 or 10 follow-up moves at those places.

Btw, I also like that the software gives the name of the moves played. Nice addition! Are you using a shape library for that?

Continue the good work!