pgeorges wrote:

Hi!

 >> For observing games receiving of seeks and game infos is
 >> not that desirable IMHO, especially if one wants to see
 >> the whispers and kibitzes within the output. A better way
 >> to deal with this would probably be to gag seeks from the
 >> output window.
 >>
 > I added a "silence" checkbox. But I still have to find a
 > good way to get game proposals and display them to the
 > user, and "set seek 0" trashes the offerings.

That's right of course. This is also just a hack to get the
main console readable. I don't know how much work you want
to invest into FICS right now. So this checkbox is a work
arround for the time beeing in the essence a "better than
nothing" thing... But I think a good FICS connection has
quite some potential for the use in a database application
like scid.

In general I'd suggest to "gag out" the seek offerings and
display them only in the offerings checkbox. That is: set
seek to 1 but not display the lines it generates. The same
is true for the game info lines btw. I'd generally not set
gin to 0 but gag the lines out of the main console and
transfer their display to another window. I'd suggest two
additional window at the moment: one "Game Information" and
one "Seeks". IMHO one should think about wether it is not
more practical to have yet another window for the console.
For many things it should be something like 80chars wide,
and depending on the ammount of buttons and other infos it
might generate a lot of empty space, so a button box might
be more approriate.

I think for the infra structure some parsing has to be
implemented in the fileevent handler currently displaying
the main console and the dispaly logic then moved on to the
window display routines. This parsing stuff could get a bit
involved as one has to rely on text messages instead of
structured data, but this kind of things can be done. I do
such things all the time in tf, more or less the only other
computer game I'm playing. It's just a bit error prone as
one has to implement the triggers for all possible
occurences and most likely you miss some. (E.g. I'm still
collecting synonyms for "Someone says:" strings. Currently
counting 65 still rising.)

 >> Additionally I found that the setting of the game clock
 >> by the server seems to confuse scid. I.e. if a game is
 >> relayed the clock information comes from the relay. So
 >> some additional parsing is required here. Currently one
 >> gets an "error reading move <last move>" after the next
 >> move is entered.
 >>
 > ok, I also get the bug observing a relayed game. I don't
 > know the difference between observing a normal game a
 > relayed one. shouldn't FICS send the same information ?

If I'd have to guess: scid currently stumbles accross the
clock settings message and tries to interpret some move with
it. This is not set for normal games, is it? Or at least it
is not set with a text like "the relay is setting whites
clock to...". I think that there's quite some text parsing
required in the file handler to get it working smoothly,
that is one would IMHO have to write some general text
parser that checks for system messages and delegates them to
the proper scid routines (like seek, game info and so on)

It might be worth some work to get a decent parsing in these
routines, one that is easily extensible.

 >> Now I've also to report a slight bug: closing the fics
 >> console by the close button of the window manager (ie.
 >> not using the Close button of the dialog) throws an error
 >> message.
 >>
 > I can't reproduce this bug, but in case I hardened the
 > "Destroy binding" so it behaves as if the user presses the
 > "close" button, so it should be ok now.

I'll check with the next release then or from cvs.

-- 

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: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Scid-users mailing list
Scid-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/scid-users

Reply via email to