Alexander Wagner a écrit : > Hi! > > Just some suggestions I came accross while looking at the > recent releases. > > - Analysis > * I think it would be good to store the engines score also > in "short comments" format. I find the rating graph quite > helpfull. > I will add an option for this. > (One could even consider drawing more than one line if > analysis of several engines is available.) > Difficult to do as scores are not in a particular field, but comments are parsed to find things looking like +/-X.X I even recently got problem with Rybka's name : Rybka -32.bit (and -32 was used as score !). I corrected this in latest release but you will understand that multiple score extraction is feasible but not that easy, if you want to avoid errors. For example imagine 2 engines analysing with their own books. Then engine 1 may be out of book before engine 2, and you will have only one score for a move when you expect 2. > * Probably one could shorten the engines names in the > comments? The legend coud be given in the Annotators > field. Something like > > [Annotator "DeepShredder 11 (A), Toga II 1.3.1 (B)"] > > and then later on > > A: +0.35, B: +0.27 > > This is less readable for me. Maybe I should insert the engine's field instead of the name that the UCI engine gives, and which is sometimes a bit too long. The problem of aliasing names is that if someone changes Annotator field, it may leave comments with orphan aliases. > * Removing the comments/variations should also clear the > annotator-field. E.g. I ended up with something like > > [Annotator "DeepShredder 11, DeepShredder 11, DeepShredder 11, > DeepShredder 11"] > > while trying several settings in the annotation dialog. > There may be several problems here, among which how to detect that when removing comments, you also removed variations ? Maybe the best solution would be not to add automatically the Annotator field : I will make an option for this, I think. > - eMail Manager > > * Something I'd look for would be the eMail Manager. > Currently I use xboard for email chess, which works pretty > well though I've to import the games later on in scid > anyway. The current handling of email chess within scid > IMHO would need some improvement to be usable. A possible > way could be to speceify a "correspondence chess database" > where all games go to that are > > [Event "Email correspondence game"] > [Site "NET"] > [Mode "EM"] > > Now one would have to find which games within the database > need to be replaced. For the key cmail (that is xboards > mail feature) uses: > > [CmailGameName "jj-aw2007-02-22"] > > Addionally it stores the mail addresses of the opponents: > > [WhiteNA "[EMAIL PROTECTED]"] > [BlackNA "[EMAIL PROTECTED]"] > > Probably one could use that in scid as well for the mail > handling? Using the cmail fields would lead to seemless > integration with cmail. > > * Concerning the current comment (by Shane) about scid not > beeing able to read the users mailbox: this is > absolutely not necessary. Its enough to define scid as > handler for the mime-type in question and call it with > the attached png-file as parameter. So there's no need > to implement imap/pop or whatever support in scid. > > I could imagine scid to check the pgn header if a pgn > file is passed on the command line and check for the > above. If it finds the fields in question it could > trigger the sync against the local correspondence chess > database Personaly, I use other means when playing correspondance chess. If there are any volunteers to look at this part of Scid (email management) ....
Pascal ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Scid-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/scid-users
