Benoit St-Pierre wrote:
Hi!
>> Till yestereve we had Play / Training / Openings. Joe User comes
>> along, "Ah, an opening trainer, interesting! Lets try that
>> thing." An there Joe is lost. Not even the ChangeLog said a
>
> Interesting example. Joe Trainer would never access to
> your modified help files if he just downloads Win binary,
> unless the documentation is up to date.
But they will be in the next release. All my changes are in
cvs right now, meaning they'll come up in the GA
automagically. My point is that it has to be there in the
next release, and if I got Pascal right, that's arround the
corner, and he does not consider lack of docs a hinderance
for a release. So, it was time to get it off.
The reason you mention is exactly the point why I spent so
much time this weekend to get it done at least in english
for 3.6.26, and actually you support my point that lack of
docs is a hinderance for a release. ;)
> It's normal that people asks here for advanced
> functionalities. What we should do about the questions
> and the answers ? Build up a better documentation system
> on-line is easier and faster than rewriting the F1 doc. A
> FAQ would be nice to complement this mailing list.
Well, in a way one could think in the direction of a Wiki
here. Thoguh I've always my doubts that it will get filled
by actual users.
> That does not mean that the F1 doc is to be neglected.
> What we must insure is to put there information that are
> vital and permanent.
Ok, thats in Bradleys direction to introduce a "meta format"
for docs that is used to create the F1 help therof as well
as help page for the web and so on.
Don't get me wrong: I find this idea a very good idea.
> You can't always correct a conceptual bug the same way you
> can correct a programming bug.
I did not intend to correct a bug. But I intended to have at
least an english documentation _in_ the next release (that
is, as I said, obviously arround the corner). Given Pascals
time frame I admit that there was no time left to invent
something radically new, move all current docs into a better
system, generate the help pages thereof and still have it
_IN_ the next release. As you mention, if it's not in the GA
release its of almost no use, as nearly nobody runs a cvs
version, I hope. (It is IMHO not advisable for the general
user anyway.)
So, my motivation was different here. I wanted to ensure,
that all nice functions that are there have at least that
amount of docs that Joe can find it once he downloaded
3.6.26 and can fiddle out what they do.
IMHO this is especially important as Pascal intends to leave
Tcl/Tk 8.4 and IMHO chances are not that bad that Joe is not
able to "just install another Tcl/Tk along the one that came
with the system". (See the recent discussion on how to get
it up on the Mac.)
> (Here's a counter-example, though : the Pause button of
> the analysis engine is described as "Start/Stop engine(a)"
> in its contextual menu. That's strange, but simple to fix
> : only correct the message in the tooltip. I don't know
> what "(a)" refers to, by the way.)
Ahm, the pause button actually starts/stops the engine. The
text is correct. There is no such thing as "pause".
Probably, the pause icon should be a stop icon. There're
some engines that handle "stop" like "pause", however.
Shredder e.g. does not forget his calculation and just
continues. But all other engines I have at my disposal do
restart from scratch. (I even forwarded this as a bug
mentioned by a user. See Pascals comments here on the list.)
The "(a)" means that you can hit a. Its the shortcut. It
confused me as well, but I admit that I've no idea how to do
it better.
> So here is what we can do. You finish off a first
> check-up or analysis of all Scid's functions. That's
> unquestionably needed. After I finish up the first pass
> of the tutorial, I will modify the on-line help pages in a
> way that will take into account all these functional
> modifications.
I'm prefecly willing to leave the current system for
something better. I do not see that writing striped down
html into a tcl file is a perfect way to handle help and I
can imagine something the way Bradley described. But given
the current situation I was just not able to invent the
system and set it up in a couple of days. ;) Call it
"destructive interference with real life".
> I'll try then to find some semantics that will be easily
> converted into Scid's idiosyncratic HTML. I don't have in
> mind controverted semantics here : just a way to retrieve
> tcl's anchors for index entries, say. I can be more
> precise as to what I have in mind, but I need to get going
> for now.
Well, I can imagine something like
<helpanchor>Analysis</helpanchor>
<title>Analysis</title>
<description>here comes the text</description>
However, this is not very different from the current style,
exept that it is using XML. Therefore, one could even think
the other way round. Why not take the current format and
generate valid html thereoff? Doing this in a TCL program
might probably be pretty simple. But I did not check that.
In any case there're quite a bunch of inconsistencies in the
usage of tags in the code right now. E.g. in quite some
circumstances <b></b> is used instead of <term></term> and
similar stuff.
I'd not put to much work into fiddling out the required help
anchors from the tcl code itself, I think it would probably
add quite a complexity and require quite some work.
Additionally, I think a vitally important point is, that
another system is as simple as the current one so
translators can handle it easily without to much
technicalities involved.
--
Kind regards, / War is Peace.
| Freedom is Slavery.
Alexander Wagner | Ignorance is Strength.
|
| Theory : G. Orwell, "1984"
/ In practice: USA, since 2001
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Scid-users mailing list
Scid-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/scid-users
