on cGoban's misuse of the SGF CR (circle marker) as focus marker
Alex D
It is obvious that I am unable to successfully defend my position in a
discussion that started on http://senseis.xmp.net/?KGS%2FSGFDetails .
After kindly but unsuccessfully suggesting to substitute cGoban's use of the
CR marker with a true focus marker, I there state that cGoban - an otherwise
very good KGS Go client and SGF editor/viewer - has no right to use the SGF CR
(circle) marker for its own purpose, namely as what I call a focus marker.
[wms]' (author of cGoban) point of view, however, is that cGoban uses CR to
indicate the current move, makes sure that every SGF editor/viewer shows the
symbol and thus ensures that viewers can see what reviewers are referring to.
However, cGoban overlooks the fact that this (mis)use of the CR marker is for
all purposes identical to the concept of a focus marker,
an-application-specific way to indicate/highlight the current/last move; the
fact that cGoban adds the property to every node in a SGF file should trigger
a thought about how useful such information must be: it is similar to adding
the word "page" next to page numbers in a book: a pure waste of ink, but it
indeed ensures that readers know exactly what the number stands for. However,
the word "page" becomes important if here is also a preface for example, as it
then carries new information.
I think that the majority of users, as well as the majority of people involved
in the SGF format, will agree that the use of CR in cGoban is no more than a
useless pollution of an SGF file (because of the systematic presence of the CR
marker in every node), and because this simply "hijacks" the CR marker by
imposing a meaning ("the current move" in this case), while - to my opinion -
there is no explicit agreed use of the CR marker. Some editors can inform the
user about the presence of markers, but this feature is neutralised in the
case of cGoban produced files because the CR marker is everywhere.
Because of [wms] persistence to kling to the evil way ;-) in this discussion,
while this will most probably not change his attitude, I would like to hear
from the Go/SGF community whether my remarks are to the point, or whether
[wms]
has a point.
Why do go this far? Because it seems to me [wms] is expressing a lack of
respect for objective, logical argumentation in this matter, that such
behaviour cannot be accepted. It has probably become (no more than...) an
academic discussion, but the essence of those discussions are a never ending
quest for a rational ordering of our world.
Maybe [wms] might reconsider his position if enough reactions can be collected
on this matter.
Thanks,
-alex-
Roy Schmidt
I am thankful that cGoban2 uses the circle to mark the current move,
rather than the annoying "blink-blink." In your long argument, you
say, "... while - to my opinion - there is no explicit agreed use of
the CR marker." This being the case, the author is simply making use
of a marker that does not have any reserved use. Why should anyone
insist this is a problem? If you don't like it in your SGF, just
write a little routine to remove it.
Cheers, Roy
--
my reply-to address is gostoned at insightbb dot com
-------------------------------------------------
Roy Schmidt
Part-time Translator for Yutopian
Full-time Professor of Business Computer Systems
Bradley University
Chris Lawrence
> Because of [wms] persistence to kling to the evil way ;-) in this
> discussion, while this will most probably not change his attitude, I
> would like to hear from the Go/SGF community whether my remarks are to
> the point, or whether [wms] has a point.
I feel that the use of explicit circles in SGF is poor form, in the same
way that jamming hard styles into hypertext markup is bad form. The use
of circle ensures that circles will always be shown, whether or not
circles are appropriate.
For example, when viewing such an SGF in at least one program (I think
it was Jago), the last move appears with a circle, courtesy of the SGF
markup, *and* a coloured square, courtesy of the application. I feel
that the SGF should contain SGF game content (eg, moves, timings,
comments) and the application should be left to render the SGF as it
chooses to (eg, last move markers, paths, trees).
Taking the circle idea to its logical extreme, we move from away from
markup into the realm of embedded styles and objects. I see a very
clear distinction between the markup of SGF and the application based
rendering of the markup. I would no more force circles into SGFs than I
would force red Arial hard italic fonts into level 1 headings. The
markup should simply say "level 1 heading" or "move" and leave the
application to render that in an appropriate way and work out which
elements need to be in big fonts and have markers overlaid on them.
The circle with superimposed square, and the converse problem of SGFs
from other sources having to have circles added (with the Mark Moves
button), are examples of why shifting last move rendering from the
application into the SGF markup itself is bad style.
I've chatted with wms about this in the past and he has different views
on the matter, which I ultimately respect because I find cgoban2 to be
excellent where it counts, for me at least.
Just my 0.02 Drogna.
--
Chris
Edgar Toernig
>
> After kindly but unsuccessfully suggesting to substitute cGoban's use of the
> CR marker with a true focus marker, I there state that cGoban - an otherwise
> very good KGS Go client and SGF editor/viewer - has no right to use the SGF CR
> (circle) marker for its own purpose, namely as what I call a focus marker.
I was annoyed enough by that "feature" that I changed CGoban*1* to
ignore those marks. [Skip to next/prev variation/comment/mark was not
working any more.]
IMHO, an SGF-file shouldn't enforce a presentation policy. That's the
job of the SGF-viewer/editor/printer/... (and all I know handle "last
move marking" very well). Additionally, editing such an SGF with
an editor which is not using this policy gives "mixed-mode" files.
Not nice.
> [wms]' (author of cGoban) point of view, however, is that cGoban uses CR to
> indicate the current move, makes sure that every SGF editor/viewer shows the
> symbol and thus ensures that viewers can see what reviewers are referring to.
Hmm... pretty weak argument. If a reviewer adds a comment to a node
he can also add a mark. Marking every single move "just in case some-
body adds a comment" sounds strange. Btw, what's wrong with: "This
move ..."? ;-)
Ciao, ET.
alex D
> rather than the annoying "blink-blink."
I agree with your idea. Just for my information - which application behaves
like that?
> In your long argument, you
> say, "... while - to my opinion - there is no explicit agreed use of
> the CR marker." This being the case, the author is simply making use
> of a marker that does not have any reserved use. Why should anyone
> insist this is a problem? If you don't like it in your SGF, just
> write a little routine to remove it.
because
a. the CR marker should remain unreserved as long as the SGF format does not
specify how applications should make use of it;
b. there is a better solution instead of hijacking the CR marker: just
implement a true focus marker (and "blinking" is not a true solution);
c1. it's not to me to write a little routine (though I have it at my
disposition) to remove cGoban's "droppings" from SGF files
c2. if I were the only one complaining about this, then I would have to find
a workaround; but I'm not the only one complaining, so it is far more
efficient for [wms] to tackle this issue.
Remember that my main argument is the observation that the CR mark is
present EVERYWHERE in a SGF file; this most certainly has never been the
intention of the SGF creators. Markers are free for the user of an
application to make use of, not for applications themselve, even if there is
no prior agreement about this.
-alex-
Warp
> I there state that cGoban - an otherwise
> very good KGS Go client and SGF editor/viewer - has no right to use the SGF CR
> (circle) marker for its own purpose, namely as what I call a focus marker.
By what authority do you state that?
If the CR marker has no defined use, then it can be used for whatever
purpose. Cgoban is using it for a purpose.
Are you implying that the SGF standard should say "the CR marker can be
used for whatever purpose except as a focus marker"?
For me the CR markers are not any problem. If I wanted to remove them,
it would be very easy for me:
sed 's/CR\[[a-z][a-z]\]//g' file.sgf
--
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// - Warp -
alex D
> on the matter, which I ultimately respect because I find cgoban2 to be
> excellent where it counts, for me at least.
OK. But if [wms] has a problem due to the fact that the use of CR is deeply
rooted in cGoban, then I can understand his reluctance to get rid of this;
at least he should confirm this, thereby definitively closing the
discussion. (Ain't I reaching an excuse here...)
However, if [wms] would have no problem in solving this issue, but is
opposing against it because of matters of (his) principle, then I cannot
supress this frustrating feeling that [wms] is just resting on his position
of superiority as author of cGoban, denying logical argumentations. If this
is [wms]'s position, the discussion will also end, leaving behind people
that thought that the Internet was a way to improve this world by allowing
anyone to express and defend ideas that are right (and we are not talking
about political, ideological etc issues...) in order to improve "things in
general", how vague that might be.
-alex-
alex D
news:cesr1s$1r9c$1...@news.cc.tut.fi...
> Alex D <an...@anon.anon> wrote:
> > I there state that cGoban - an otherwise
> > very good KGS Go client and SGF editor/viewer - has no right to use the
SGF CR
> > (circle) marker for its own purpose, namely as what I call a focus
marker.
>
> By what authority do you state that?
Because logic tells me that there is something wrong if an application puts
a CR property in EVERY node of a file, and because there are more efficient
ways to present a focus marker. Of course, we live in a free world, and
anyone can do anything (s)he likes. But if you want to live together with
other people, you must be open to rational arguments if those are meant to
improve things, and are based on common sens - even if common sense is not
always the best counselor.
> If the CR marker has no defined use, then it can be used for whatever
> purpose. Cgoban is using it for a purpose.
... forgetting that this way of using CR reduces its value in general and
can be a source of confusion; someone using cGoban cannot rely on a CR added
by a reviewer, because there is a big risk of confusion possible on the
reader side: suppose a reviewer is adding a CR, which circle is the reviewer
referring to: the last move CR, or the CR the reviewer added to the review?
So the reviewer has a reason not to use CR.
> Are you implying that the SGF standard should say "the CR marker can be
> used for whatever purpose except as a focus marker"?
No. I am saying that the CR marker should remain free for use by anyone who
wishes to use it for whatever need (s)he deems it necessary; where "(s)he"
is understood to be the user of an application (e.g. a reviewer), and not
the author behind that application.
>
> For me the CR markers are not any problem. If I wanted to remove them,
> it would be very easy for me:
>
> sed 's/CR\[[a-z][a-z]\]//g' file.sgf
Yes, but this is a workaround. And not everybody can do this as easily as
you; the bulk of the users even haven't a clue on how they should solve this
problem.
-alex-
gimpf
[...]
> For me the CR markers are not any problem. If I wanted to remove them,
> it would be very easy for me:
>
> sed 's/CR\[[a-z][a-z]\]//g' file.sgf
>
And how can you determine _absolutly surely_ if this marker is set from cGoban2 or from a reviewer?
sed is a great tool, but telepathy is currently not an widely spread application throughout every Unix or whatever shell...
And another thing: How many typical wei-ch'i players know, that sed exists (or any other kind of program that can use regexp or similar)?
And how many typical wei-ch'i players know how to handle this? There are even people who are surprised that SGF is text... or, better: they don't know, they don't care. The play Go instead...
BTW, redundancy which cannot be used for error-checking or correcting is usually NOT unnecesarily added to any kind of data (ok, MS Word likes to do this...). And the seperation of content and formatting has another advantage: anybody can see the style he wants. People may prefere circles, others maybe like the red cross of JaGo?
Just my 0.02€
Planar
"Alex D" <an...@anon.anon> wrote:
> Because of [wms] persistence to kling to the evil way ;-) in this discussion,
> while this will most probably not change his attitude, I would like to hear
> from the Go/SGF community whether my remarks are to the point, or whether
> [wms] has a point.
I think you have a point, but your argumentation is rather weak.
> Why do go this far? Because it seems to me [wms] is expressing a lack of
> respect for objective, logical argumentation in this matter, that such
> behaviour cannot be accepted.
Come on! Everyone tends to be stubborn, WMS maybe more than average,
but that seems to be a prerequisite for writing good software.
Here are my remarks on the subject, directly addressed to WMS:
You designed this circle feature as a help for people who use
other SGF viewers. A significant number of your users have told
you that, for a number of reasons, they find it a hindrance rather
than a help. Maybe you should consider making it optional?
You told us, "if you don't like it, don't use cgoban2". That is
not an option, because I want to go on playing on KGS. This circle
stuff is just a small bug of cgoban2. I'd be perfectly happy with
an option for saving my KGS games without CR markups. For example,
as a checkbox in user preferences.
After reading the whole discussion on SL, I think the sgf2misc issue
is the only serious problem. Since you provide a menu item to add
the circle marks to a SGF file, maybe you should also provide a way
to remove them easily. Otherwise, it looks like you are trying to
impose your own format by providing only one-way translation from
the more standard way of doing things.
--
Planar
remove the dash and .invalid from my address to send me mail
"Surprise. Then just use AGA rules and that's it." - Robert Jasiek
Warp
only for me.
--
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}// - Warp -
Frank de Groot
>
> After kindly but unsuccessfully suggesting to substitute cGoban's use of
the
> CR marker with a true focus marker, I there state that cGoban - an
otherwise
> very good KGS Go client and SGF editor/viewer - has no right to use the
SGF CR
> (circle) marker for its own purpose, namely as what I call a focus marker.
<snip>
> Maybe [wms] might reconsider his position if enough reactions can be
collected
> on this matter.
The first time I found a file that was "CR-ed" in such manner, I became
annoyed. I am against using automatically-added ("hardcoded") annotation in
SGF's because it breaks the "show last move as.." feature. I think a SGF
Reader is free to annotate every move with a circle but it should be up to
the user to save the CR's in the SGF.
Perhaps it should become an option in cGoban that is off on by default (if
it isn't already, if that's the case, ignore my remarks).
I can understand WMS's arguments though - he perhaps saw that many SGF
readers did not have a "show last move" feature and decided to fix it like
this. But I find it extremely annoying that when my user decides to do a
"show last move as triangle", that a long time ago, cGoban decided that this
should not be possible..
Because, of course any ANNOTATION should override a "show last move as.."
feature, as annotation is important, there usually is a comment: "The stone
with the circle is..". And a "show last move as.." feature should not
destroy - override that legitimate annotation.
To sum it up, I am against putting CR on every move because it is abusing an
"annotation" mark to implement a universal "show last move" feature that is
causing more harm than good.
alex D
> is the only serious problem. Since you provide a menu item to add
> the circle marks to a SGF file, maybe you should also provide a way
> to remove them easily.
... bearing in mind that the typical KGS user will not feel concerned about
stripping CR markers for the benefit of (e.g.) sgf2misc users, therefore
this option should preferrably be off by default. But I admit this is not
the solution, because that same typical KGS user needs those CR markers for
HIS (her) benefit :-)
-alex-
alex D
able to refer to objects such as moves (nodes), branches etc... in an SGF
file, while at the same time avoid those references becoming obsolete when
variations are added - reshuffled - comments are merged from different SGF
files (yes, that's not yet available, I know)
Maybe the SGF standard should be extended to incorporate the idea of
referring to objects.
And even further OT: the SGF standard should provide for the possibility to
have several comment nodes linked to different contributors, which are added
as new setup node properties. Sorry for this drifting...
-alex-
Frank de Groot
news:10917149...@ecw.eurocontrol.be...
>
> And even further OT: the SGF standard should provide for the possibility
to
> have several comment nodes linked to different contributors, which are
added
> as new setup node properties. Sorry for this drifting...
I think that this will be implemented (perhaps) on a non-standard,
individual basis, as extending the SGF standard is a slow process and some
developers will prefer their own solutions.
I use a method of embedding RTF in comments. This allows me to nicely merge
comments, where each comment becomes a row in a table, each comment having
an "attributing"- header in a tiny font, and a different color.
Another advantage of RTF in comments is the following:
Automatic Fuseki, Joseki & pattern analysis as diagrams embedded into
comments.
When you play a game (on a Go server or you replay SGF etc.) the software
looks positions up in a database and inserts comment boxes like: "This
Fuseki has been played by <most recent game> of <highest ranking players>
(where this Fuseki resulted in a win for the one playing it). All this (with
Joseki's and patterns as well) would become quite messy with just plain
text, if it has to have ordinary- and "merged" comments as well, and there
would be no way to insert graphics or to change the font.
I think this is a good solution, as it would be complex and a long-winded,
straght-jacketed approach to have rigid SGF standards for such
functionality.
When comments can contain "anything" (my product will have the ability to
paste an Excel sheet, a web page or a Word document into the comments
section), it becomes easier to do such things without having to go through 2
years of discussions about standardisation.
Then we have what you alluded to, an "object oriented" approach. (Microsoft
oriented in this case, but having RTF embedded is a platform-independent OO
feature, where the chunks of RTF are the "objects"). What is inside the RTF
can be tables,formatted text (like fixed-width font diagrams mixed with
proportional text) images, converted HTML etc.
Nacho Facello
> purpose. Cgoban is using it for a purpose.
I think it should not be the program the one to decide for what
purpose to use a markup element. That is the task of the SGF author.
JVT
> The first time I found a file that was "CR-ed" in such manner, I became
> annoyed. I am against using automatically-added ("hardcoded") annotation
in
> SGF's because it breaks the "show last move as.." feature. I think a SGF
> Reader is free to annotate every move with a circle but it should be up to
> the user to save the CR's in the SGF.
Exactly. I e-mailed wms a long time ago when KGS was at the beta stage,
reporting bugs and asking why all moves in the SGF file had to be marked,
making it twice as big as necessary. IMO this "feature" is so completely
useless that I cannot imagine why anyone would want it.
ian
Isn't it also the case that the majority of users won't actually care
one jot. The most prolific user of the archived kgs files are infact
kgs users - aren't they? I respect your holy crusade for a pure sgf
conformal environment, but I laugh wholeheartedly at the pedantic
nature of your attack in the very same breath.
Marco Scheurer
> Hello Go world,
>
> It is obvious that I am unable to successfully defend my position in a
> discussion that started on http://senseis.xmp.net/?KGS%2FSGFDetails .
>
> After kindly but unsuccessfully suggesting to substitute cGoban's use of the
> CR marker with a true focus marker, I there state that cGoban - an otherwise
> very good KGS Go client and SGF editor/viewer - has no right to use the SGF CR
> (circle) marker for its own purpose, namely as what I call a focus marker.
I agree with you. Using CR to mark the last move would be just like
using number markups to number the moves. The SGF viewer should be
able to show or hide the focus on the last move and should give a
choice to the user on how to show it. This trivial presentation issue
has nothing to do with SGF.
Marco Scheurer
Sen:te, Lausanne, Switzerland
http://www.sente.ch/software/goban
Vesa Laatikainen
> I agree with you. Using CR to mark the last move would be just like
> using number markups to number the moves.
Considering that cGoban has problems to show the move numbers on online
games, this might be a new fatal idea :)
Cheers,
Vesa
Rene
However, you can switch off last move indication in Jago to get along with
this kind of nonsense.
Cgoban should notice that players that want an information about the last
move can use a SGF editor that shows it. It is the job of the viewer not the
SGF author.
Likewise variation marks, by the way.
Rene
Peter Strempel
* It should be job of the viewer to decide if and how to display its own
last-move mark. "Own last-move mark" means there is no explicit marker
tag in the file, so the viewer displays an own mark. What sort of mark
this might be is not the job of the SGF notation.
* A viewer should not display its own last-move mark if the same spot
contains an explicit marker to prevent being two marks on that spot,
which is invalid SGF and makes no sense. This is the behaviour of glGo
and gGo. An alternative way is an option to toggle own last-move marks
off like in Jago, as Rene mentioned.
* An editor can save anything to a SGF file, including CR marks for each
node, as long as the resulting file is valid SGF. Hence, the files
produced by CGoban are valid files, so I see no problem. If the CR marks
make so much sense is another question but not my business.
* My main interest is to ensure SGF files produced by other viewers
display properly in my software. If files produced in my editor don't
display properly in other viewers despite being valid SGF, it's not my
problem. The issue with CGoban2 here is, if you load a non-KGS game, you
won't see any last-move markers. This is annoying, but solely the
problem and decision of Mr. Shubert. However, people have been telling
me, *my* program is broken because files created by gGo don't show a
last-move marker when loaded in CGoban2. This is wrong, but not every
user of Go software knows the SGF specification in and out, or would care.
* I see no reason to expand the SGF specification concerning the
last-move marker.
Peter
Planar
ian....@durge.org (ian) wrote:
> Isn't it also the case that the majority of users won't actually care
> one jot. The most prolific user of the archived kgs files are infact
> kgs users - aren't they?
But such users are completely irrelevant to the current discussion,
because the feature in question was not implemented for them (nor
do they need it). It is purely intended to enhance interoperability
with other SGF viewers. Isn't it a bit paradoxical that it ends up
hampering it?
Alex D
news:2nfe6b...@uni-berlin.de...
> My views as author of a SGF editor:
> * A viewer should not display its own last-move mark if the same spot
> contains an explicit marker to prevent being two marks on that spot,
> which is invalid SGF and makes no sense. This is the behaviour of glGo
> and gGo. An alternative way is an option to toggle own last-move marks
> off like in Jago, as Rene mentioned.
I don't think the focus marker is part of the SGF spec; therefore, there is
nothing invalid in displaying the focus marker over any present SGF marker.
Also, if an application would hide its own marker because of an underlying SGF
marker, there is still a risk that the user does not see what the current move
is. I have the impression that you are confusing focus and CR marker here.
>
> * An editor can save anything to a SGF file, including CR marks for each
> node, as long as the resulting file is valid SGF. Hence, the files
> produced by CGoban are valid files, so I see no problem. If the CR marks
> make so much sense is another question but not my business.
There is nothing wrong with the validity of SGF files originating from cGoban.
However, I don't think it was the intention of the SGF spec to let
applications use SGF markers, but rather for authors to better annotate games.
It would be interesting to hear about this from those original SGF designers.
>
> * My main interest is to ensure SGF files produced by other viewers
> display properly in my software. If files produced in my editor don't
> display properly in other viewers despite being valid SGF, it's not my
> problem. The issue with CGoban2 here is, if you load a non-KGS game, you
> won't see any last-move markers. This is annoying, but solely the
> problem and decision of Mr. Shubert. However, people have been telling
> me, *my* program is broken because files created by gGo don't show a
> last-move marker when loaded in CGoban2. This is wrong, but not every
> user of Go software knows the SGF specification in and out, or would care.
Admit that [wms]' decision is causing a lot of ripples. (Note that he has
provided a solution for the missing focus markers in case on non-KGS files.)
-alex-
To ja Wento
> In article <6c099e00.0408...@posting.google.com>,
> ian....@durge.org (ian) wrote:
>
>
>>Isn't it also the case that the majority of users won't actually care
>>one jot. The most prolific user of the archived kgs files are infact
>>kgs users - aren't they?
>
>
> But such users are completely irrelevant to the current discussion,
> because the feature in question was not implemented for them (nor
> do they need it). It is purely intended to enhance interoperability
> with other SGF viewers. Isn't it a bit paradoxical that it ends up
> hampering it?
>
some free clients and sgf editors (names irrelevant for the discussion)
and I do appreciate them. But I cannot avoid noticing that authors of
mentioned applications often react in a very strange way to any comment
or suggestion, namely as if they were attacs on their good name or
something.
It is known that open standards and open discussions about them can mean
a lot to quality of service (of applications and servers). Even if some
(and I know that there is a lot of that around) comments are close to
abuse it is still not a reason to avoid any discussion whatsoever. That
is the case though and the results (maybe indirectly) are that among
other things a 'polution' of sgf files (as discussed in original post)
or other small problems (like some applications would not run on certain
OSes) still occure and (possibly) exclude quite some from the community
or make thier life more difficult that need be.
I agree with argument of the original post. I also doubt that anything
will be done. It is (regretably) a standard approach to make a product
and let the user worry. After all if you are using it (free of charge
especially) than it is your problem. Well in a sense it is so.
To make things better is a prerogative to A minority.
//Wentos
Frank de Groot
> and I do appreciate them. But I cannot avoid noticing that authors of
> mentioned applications often react in a very strange way to any comment
> or suggestion, namely as if they were attacs on their good name or
> something.
This is not so surprizing, when you realize that there are some folks who
are making Go software as a career decision. I know there exists someone who
has invested hundreds of thousands of USD in his Go software enterprize.
I have heard that Sam Sloan started a Go software company and AFAIK tried to
emit 5 million USD in shares.
So Go software development is serious business for some authors.
I quit a job that let me save 1,500 USD/month and traded it for developing
Go software at home, 2 years ago. All my savings are sunk into it.
Then I know someone who derives almost all his income from Go software.
Therefore, people can get edgy when their products are put in a bad light,
in their eyes undeservedly.
Furthermore, programmers of the calible neccessary to make good Go software
MUST be rather "peculiar".
Those guys MUST be extremely persistent, "arrogant" (in the face of waves of
critiscism a la "the earth is flat").
In case of WMS we have a very talented software developer who spent years of
his live working on software and a Go server that is completely free to use
and excellent in quality. I understand that "armchair programmers" can get
on his nerves :)
Then again, any developer who truly cares about moving forward with his/her
software listens carefully to the users and can put aside the feeling of:
"This software is 'my baby' ".
To ja Wento
critisism disilusioning and frustrating but also very helpfull. As far
my experience goes (and I worked also in maintenance dep of some big
company so facing yelling customers was part of the job) customers are
not always right but they often have a point and independently of the
way you decide to earn your money if you want to do something properly
(custmer) critisism is something you cannot avoid and have to face. It
is normall that products have faults and are not perfect. Critics can
help as they see things from different angle than the author.
The thread here started with very balanced and carfully written statment
about what the author percieves as putting things right. And he has a
point.
You cannot treat all comments and suggestions as if they were meant to
attack you personally. If go with your analogy to a baby: if you do not
correct it atsome point it will get spoiled eventually. And of course
there is no program in the world that cannot be made better and it is up
to designer to say stop at some point. Itis only fair to say so. On the
other hand when I hear :it is mine program, protocol, server or whatever
and like it of leave it, I have a very mixed feelings about it then. PR
is also part of a job of a (software) products maker.
You mentioned some names but I was not getting on anybody personally. I
was just pointing out that it is almostimpossible to pass suggestions or
discuss improvements of go software, protocols, formats etc.
I suppose thisnewsgroups is not meant for that.
//
Frank de Groot
news:cevlnu$mjs$1...@online.de...
>I was just pointing out that it is almost impossible to pass suggestions
>or discuss improvements of go software, protocols, formats etc.
>I suppose this newsgroups is not meant for that.
As long as there are no alternative newsgroups to discuss these, this
newsgroup is fine.
Judging from the many passionate reactions on these topics, this newsgroup
is a great place to discuss it, and all Go programmers are reading this one.
To my knowledge, the only well-read alternatives are Sensei's and the Go
programmers list, but Sensei's has no "dated thread" structure and therefore
not the best place perhaps and the Go programmers list is more intended for
actual Go programmers, AFAIK.
The people who are exclusively interested in playing Go on a wooden Goban
with a living person sitting in front of them can ignore the threads about
comp.go :)
ian
> In article <6c099e00.0408...@posting.google.com>,
> ian....@durge.org (ian) wrote:
>
> > Isn't it also the case that the majority of users won't actually care
> > one jot. The most prolific user of the archived kgs files are infact
> > kgs users - aren't they?
>
> But such users are completely irrelevant to the current discussion,
> because the feature in question was not implemented for them (nor
> do they need it). It is purely intended to enhance interoperability
> with other SGF viewers. Isn't it a bit paradoxical that it ends up
> hampering it?
In the context of the opening arguement they are not irrelevant. What
we basically have is the creation of a server specific sgf file;
kgs-sgf if you like. This file can be read in all normal sgf editors,
it could possibly cause some conflicts by displaying a circle at the
last move. As multiple mark up can be displayed at a single move
junction I still wonder what real harm it could do - screenshots of
the horror anyone? I imagine other editors also cause conflicts. In
terms of user impact I have to imagine that is unsevere, which makes
me wonder at the hyperbole being thrown around.
Planar
> In the context of the opening arguement they are not irrelevant.
They are irrelevant because they will never see a difference
between this feature and the normal way of doing things (as
done by cgoban1, for example).
> What
> we basically have is the creation of a server specific sgf file;
> kgs-sgf if you like.
Yes, and this server-specific way of using the SGF format is
*explicitely* designed to help the users who use SGF editors
other than cgoban2. It does nothing for users who stick to
cgoban2. Actually, it's a purely negative feature for them:
it makes their game records twice as big for absolutely no
difference in behaviour.
[...]
> I imagine other editors also cause conflicts. In
> terms of user impact I have to imagine that is unsevere, which makes
> me wonder at the hyperbole being thrown around.
If you had read the SL discussion, you would have noticed that
it prevents sgf2misc from numbering the moves when printing a kifu.
This is arguably a sgf2misc bug, but it still forces people to
choose between playing on KGS and printing their games record.
I'd also like to add that this feature is a big user-interface
blunder: you are making files explicitely designed to override
the user's choice of current-move highlighting. What if I don't
want the current move marked? I disable the marker in my SGF
viewer and it doesn't work. That's a bug. In the SGF file.
It's the dual of the bug you fixed by adding the "Mark Moves"
menu item.
yoosh
the cr or not.... or they don't care.
i don't want it... i think it is the only big minus of cgoban.
i'm not a seer but the result of the pool will look like this:
don't want cr: 99%
want cr: 0.5%
don't care: 0.5%
Alex D
news:ros7h0dv0em1m36do...@4ax.com...
> maby wms should make a pool and ask kgs users to vote whether they want
> the cr or not.... or they don't care.
I think enough argumentation has been put on the goban, the best solution is
for wms to make the right decision. KGS (only) users most probably have no
problem with the topic, it's (some) users of other SGF software that
experience nuisances.
-alex-
Rene
are mislead. In my last posting I held back, since I find the issue not so
much interesting. However, now I decide to stand for my viewpoint, just as
you do.
Saving circles with SGF as last move markers has at least the following
problems:
- You kind of enforce people to use your editor for your files. Every other
editor I know marks the last move in some way. Why do you insist the marker
should be a circle? Some people actually like a flashing style.
- You blow up the file with unnecessary information.
And, to add an argument against yours, if a SGF editor puts a marker
somewhere, a viewer MUST display it. I would really hate an editor that
hides anything a human put in the file before me thinking he can do better.
Another topic:
You said your editor distinguishes between his own files and other files.
This is not such a good idea. It should be done only in cases of emergency.
SGF, after all, is a global format. The authors of SGF tried to make it
universal, even if they did not succeed. So obey to their intentions and
stop saving circles by default.
Hans-Georg Michna
>but I laugh wholeheartedly at the pedantic
>nature of your attack in the very same breath.
Ian,
I wouldn't do that. Be glad that there are people who care about
abstract concepts and principles. Without these people the world
would not be a better place.
Not that this problem is particularly important, but I still
think it demands respect when someone genuinely wants to improve
things.
Hans-Georg
--
No mail, please.
Hans-Georg Michna
<fran...@online.no> wrote:
>Then again, any developer who truly cares about moving forward with his/her
>software listens carefully to the users and can put aside the feeling of:
>"This software is 'my baby' ".
Frank,
sometimes the users are the best designers. Sometimes it pays to
listen to them.
Frank de Groot
his/her
> >software listens carefully to the users and can put aside the feeling of:
> >"This software is 'my baby' ".
>
> Frank,
>
> sometimes the users are the best designers. Sometimes it pays to
> listen to them.
?? Reread my post - Exactly my point!
Hans-Georg Michna
<fran...@online.no> wrote:
>> >Then again, any developer who truly cares about moving forward with his/her
>> >software listens carefully to the users and can put aside the feeling of:
>> >"This software is 'my baby' ".
>> sometimes the users are the best designers. Sometimes it pays to
>> listen to them.
>?? Reread my post - Exactly my point!
Frank,
I meant to underline and amplify your post.
I should have added a "yes" in front.