the new version posted to the test site today has some major changes; the biggest in a long time, possibly ever.
first, the whole applet is now in Swing, which is a java UI toolkit. previously you could use the site with java 1.1. this is no longer the case. a scan of the logs showed that with almost no exceptions everyone is on java 1.3 at least, which is not surprising considering that it's been out for many years. it just got to be too much of a hassle trying to add cool new features but not breaking the 1.1 build, so i switched.
second, there's now a way to add comments directly in the applet instead of on a second page. "big deal," you say. well, you can add comments to _specific paths_ now. this means instead of typing "after b18 c18 d15 d16..." you can just play that path in the applet and type the comment there. there are some extra nifty features, like being able to see where the comments are on the tree, have genres of comments (like this is wrong, this is right, i have a question), color paths differently for comments, see which are most recent, and more.
hopefully with the help of the site users we can get this debugged and live in the near future. please let me know how it works.
adum
{Posted by admin}
New version: inline comments + Swing
"two issues"... :)
hi adum! your new applet seems really cool... =)
i too have encountered (and what i believe kaf meant,) the missing authors comments on the vars (at the rounded rectangle at the top).
the move to per-move comments also raised a few small issues -
- what will be of the old-comments (viewable on a separate page in the past)? and what will be of general comments or questions regarding the problem itself, it's sources etc. - if the old page is to be obsolete then perhaps they should be placed at the root position? *
- the "comments" button # of comments should be updated at the first look OR perhaps should be replaced with "browse" ("navigate solution") altogether? *
- this type of comments seem to me as a great tool when combined with the position-linking but what will be of older problems? (if this shall be a problem at all... maybe the entire go-wiki idea should be rethought, especially now that it seems a step closer, being able to mark branches and keeping change history)
ah and of course regarding the linking itself - maybe a new [block_forever] tag could be introduced for the applet to count a location as played out and enable linking of similar positions where less ("useless") forcing moves have been played out?
I'm also uncertain as for the possibility of commenting uncovered vars and use of "correct"/"wrong" marks - are they referring to the coverage of the problem or the vars themselves? if so shouldn't it be possible to mark an uncovered var as "correct" for example?
* UPDATE: ah, my mistake - the old comments do appear if you use the "READ COMMENTS" button at the main var as well as the "T" mark for "Talk" at the appropriate node. I used the "show solution" option out of habit to browse the vars.
UPDATE II: A few stones later in the graphical editor - Shift+Click no longer puts a white stone when setting a position. One is able to play a stone, switch back to the same color and play a stone again if it's done at the root of an empty tree (In my opinion stone color should always be "override-able"). Another interesting feature could be marking view-paths (unlike play-paths) so that it'd be obvious to the player that these paths only provide basic refutation and won't be played out and therefore aren't as throughly covered.
{Posted by santa c}
i too have encountered (and what i believe kaf meant,) the missing authors comments on the vars (at the rounded rectangle at the top).
the move to per-move comments also raised a few small issues -
- what will be of the old-comments (viewable on a separate page in the past)? and what will be of general comments or questions regarding the problem itself, it's sources etc. - if the old page is to be obsolete then perhaps they should be placed at the root position? *
- the "comments" button # of comments should be updated at the first look OR perhaps should be replaced with "browse" ("navigate solution") altogether? *
- this type of comments seem to me as a great tool when combined with the position-linking but what will be of older problems? (if this shall be a problem at all... maybe the entire go-wiki idea should be rethought, especially now that it seems a step closer, being able to mark branches and keeping change history)
ah and of course regarding the linking itself - maybe a new [block_forever] tag could be introduced for the applet to count a location as played out and enable linking of similar positions where less ("useless") forcing moves have been played out?
I'm also uncertain as for the possibility of commenting uncovered vars and use of "correct"/"wrong" marks - are they referring to the coverage of the problem or the vars themselves? if so shouldn't it be possible to mark an uncovered var as "correct" for example?
* UPDATE: ah, my mistake - the old comments do appear if you use the "READ COMMENTS" button at the main var as well as the "T" mark for "Talk" at the appropriate node. I used the "show solution" option out of habit to browse the vars.
UPDATE II: A few stones later in the graphical editor - Shift+Click no longer puts a white stone when setting a position. One is able to play a stone, switch back to the same color and play a stone again if it's done at the root of an empty tree (In my opinion stone color should always be "override-able"). Another interesting feature could be marking view-paths (unlike play-paths) so that it'd be obvious to the player that these paths only provide basic refutation and won't be played out and therefore aren't as throughly covered.
{Posted by santa c}
thanks for the comments, santa c =)
now i understand what you and kaf mean by the comments at the top -- i'll check that out.
i left the Add Comment button in because people are used to seeing it, so just removing it or changing the text i thought might be confusing. so i just changed the behavior =)
i think i'll keep the linking only between a terminal position and another -- otherwise things would get very confusing.
i think for using marking a comment as "wrong" or "right" it should probably be used in reference to the variation, not the coverage of the problem. otherwise if the problem gets edited the comments won't make any sense. so yeah, you should be able to mark an uncovered var as CORRECT.
thanks for the comments!
adum
{Posted by admin}
now i understand what you and kaf mean by the comments at the top -- i'll check that out.
i left the Add Comment button in because people are used to seeing it, so just removing it or changing the text i thought might be confusing. so i just changed the behavior =)
i think i'll keep the linking only between a terminal position and another -- otherwise things would get very confusing.
i think for using marking a comment as "wrong" or "right" it should probably be used in reference to the variation, not the coverage of the problem. otherwise if the problem gets edited the comments won't make any sense. so yeah, you should be able to mark an uncovered var as CORRECT.
thanks for the comments!
adum
{Posted by admin}
disabled html? @_@
ahh adum, i tried adding a link and it seems html is disabled in the comments... then a tag for links or perhaps http://, ftp:// etc recognition could be useful?
{Posted by santa c}
{Posted by santa c}
Inline comments
I like the inline comments. Only it would be nice to have them in a separate window because when trying to play out a line in the comments you lose the comments window since it moves when you make a move. The only way workaround I've found is to have two windows open one with the comment and another to play out the comments.
{Posted by LCZLAPINSKI}
{Posted by LCZLAPINSKI}