[ggo-discussion] Re: problems viewing sgf files

On 25.02.2005, at 21:35, Robert Kleemann wrote:
       ^^^^^^^^^^^  !!!!!

Heck, I completely overlooked this mail. My apologies. I usually try to 
reply within few days. Mailbox overflow error...


> 1) Old markup commands are not supported.  e.g.
> L[lc][kc]

Fixed in 1.2, though only for the old parser. Guess I should check this 
before 1.2 final for the new parser as well. I actually thought the old 
"L" marks worked, but somehow never got a SGF file in my hands which 
had one.


> 2) I thought the above problem might be a problem with the parser.  I
> selected the old parser and loaded the file and received a bunch of the
> following messages in the console window:
> Exception exceptions.TypeError: 'expected string or Unicode object, int
> found' in 'sgf.parseNode' ignored

I can't reproduce that at the moment. I loaded all 19 files from your 
tgz using the old parser, no problem. I gather you are using Linux from 
your email header (Thunderbird X11). I havn't compiled the recent 
version of glGo 1.2 on Linux yet. I will test your SGF files on Linux 
later today when I prepare 1.2 on it.
Other than that, on my Linux box the old parser had no trouble. I wrote 
the thing on my Linux box. But on Linux it's quite hard to tell if 
something works on another box. The old parser is written in Python, 
and there are too many Python versions on the various Linux distros out 
there. That's one of the reasons I rewrote the SGF parser. Not in 
Python. The old one is scheduled for removal somewhen, but I kept it 
for now.


> 3) Opening the tree via the menu View.Tree hangs the program.  I can
> open the Tree List on the side with no problem.

Again I cannot reproduce this. It pretty much freezes my computer when 
I open that Tree with Kogos Joseki dict loaded (that thing has 28,000 
nodes), but at some point it indeed finishes painting the tree.
On normal files (normal = ~500 nodes or so) the tree opens on all my 
box in about 1-2 seconds.


> a) On my screen (with large fonts) having both the tree list and the
> sidebar open at the same time squeezed the board such that not all of
> the board was visible.  It would be great if the board automatically
> scaled itself such that it was always completely visible in whatever
> client space was available.

Try the 2D board if you use treelist and sidebar. That scales better 
than the 3D board. Yes, the 3D scaling needs improvement.


> i) I figured out that right arrow meant next move and left arrow meant
> previous move.  Some ui that showed these key bindings would be great.

Complete list is here: glGo Manual, Chapter Usage - Keyboard Control


> ii) The current move in the tree view is indicated by the small circle
> in the stone.  This is difficult for me to see.  Perhaps have the entry
> listed in reverse video such as when the mouse clicks on it?

I am currently not sure what sort of tricks are exactly supported by 
the wxWidgets ListView class. Inverse colors should work, otherwise I 
could underlay it with a red background. I need to experiment with 
this.


> I haven't figured out how to close a variation branch with the 
> keyboard.

Insert key brings you back to the node of the main branch where the 
current variation branched off.


> When there are several variation branches open the keyboard controls 
> are
> very confusing:
>
> The right arrow moves you down
> The left arrow moves you up
> The up arrow opens a branch moving you right and down.
> The down arrow takes you out of a branch moving you up and left.

I personally think it makes some sense:

Right arrow moves you forward
Left arrow moves you backward
Up/down moves through variations

Up/down could be exchanged, but IMO one makes as much sense as the 
other. However, I feel that right-left for forward/backward makes 
sense.


> I think the reason this may be a bit confusing is that most go viewers
> use this same keyboard configuration but display the information with
> the progressive moves moving towards the left with branches going down.
> If the tree view were placed at the bottom of the screen (short and
> wide) it could follow this layout.

That's exactly how the Tree (F7) works: Root is on top-left and the 
branch grows from left to right. I guess that's the tree which you 
couldn't open (note to self: Check this on Linux...)
Now, glGo has two trees. One left-right and one top-down. So I could 
argue either way. However, I won't remove one of the trees because the 
keyboard layout doesn't fit. Which tree concept is better had been a 
quite lengthly discussion on this list, so I settled doing both. 
Another, admittedly poor argument: The keyboard layout existed long 
before the trees. I'm not sure it's a good idea when I change it now. 
*That* will confuse people. However, allowing the user to customize 
these keys would be a good idea.


> iv) It would also be handy if the current locked, variation path were
> highlighted.  cgoban2 does this by greying out stones that are not in
> the current path.  This also gives you feedback when you press the up 
> or
> down arrow to change the current path.

That would be an idea for the Tree (F7). Not sure if it's a good idea 
for the TreeList (F8).


To sum it up:
* Thanks for the detailed feedback!
* Sorry for the late reply.
* I will fix the old L thing for the new parser, too. Old one is 
already fixed.
* I will check old parser and the tree display on Linux. Both work on 
my Windows and Mac.
* I need to think over the other suggestions. None will make it into 
1.2 as want to release it soon.


Peter

Other related posts: