pgeorges schrieb:
Hello Pascal!
>> This happens to me when I resize this window vertically
>> between the two visible panels and the lower window
>> border. The space is devided by the statusline. However
>> you have to make it really long, like 2/3 screen height.
> I fixed 90% of the problem (you may still encounter
> packing problem in some cases).
THX :)
>> Thats the point: you could! Adding the ability to read
>> some strings via some input stream that is connected to
>> the input engine and give it to the normal processing of
>> scid would do the trick. Thats the basic idea of the
>> dgtdrv-approach. The developer of some gui does not need
>> any hardware, juast as (s)he does not need any chess
>> engine.
> There are some drawbacks here : - the board is considered
> as an engine : this prohibits some specific use (lifting a
> piece for example to trigger special functions);
Nope. Absolutely not. I just throw a message for this. To
keep it compatible with xboard/uci I wrap them in
info-messages. E.g. the DGT-"move" to switch to setup mode
is lifting both kings. If you lift both kings dgtdrv issues
an info message like (uci-mode):
info string !enter setup mode!
And then no placements or "moves" will be send. A sensible
GUI would read this stop the clocks and probably inform the
user e.g. Otherwise it will just ignore the string as an
informal message (or whatever it does otherwise with those
strings.)
To end setup mode you'd place both kings back, specifying
the side to move by placing their king last. dgtdrv would
then throw something like
info string !end setup mode!
info string !black to move!
info string FEN <position>
with the <position> replaced by the actual position in FEN.
(So actually the "black to move" message is redundant.)
Same goes for "move now", "new game", "end game <result>".
Additional similar messages are thrown with the clock timing
(in case you connect a DGT XL it should be passed through
and most likely also set the GUI's timing) and stuff like
that.
Besides you've some additional commands a normal engine does
not know like "getboardposition", "getclock" stuff like
that. The full protocol can be found at
http://dgtdrv.sourceforge.net/dgtdrv-3.html
> - the UI must work in tournament mode (not the case for
> Scid PC now, but should be ok on PPC)
Nope. Actually it would even be better to merge the boards
messages to the normal scid move input. The "missuse" of
tournament mode is just a work arround to get a GUI reading
the board that doesn't know a thing about it. I tried here
to work with as many GUIs as possible.
My xboard patch that incorporates many of the above messages
into xboard uses turnament mode as I was able to fiddle out
how xboard handles the engine wheras I did not yet manage to
find out how normal move input is handled. I currently do
not understand the message handling in xboard for mouse
events. If I would I'd hook my code in there of course add a
menu item "DGT" and just replace mouse events by board
events. That's actually the "good way" to do it. The other
one is just a fallback for GUIs that don't know dgtdrv.
On the other hand keep the dialog-part close to uci/xboard
has the advantage that you don't need much code within your
GUI as you already have either or even both to talk to a
chess engine. One could just reroute the messages
internally. Switch off the keyboard and connect the driver
engine instead by means of a pretty simple parser that is
almost what's already there for uci/xboard + some additional
strings to parse.
> - coding in Tcl makes it easier to port (consider a port
> to Pocket PC for example);
As I say: you could do the input engine in whatever language
you want. For quite some time I considered doing dgtdrv in
perl. (It's C just as I did not want to code a perl-binding
for dgtnix first, so it was more convenient to do it in C.)
The scid-part of this handling would be tcl anyway.
> - I want to use Bluetooth one day : in Tcl it means simply
> to change a COM parameter
Same for the input engine. Actually the nice thing is IMHO
that you could move this issue even away from scid. Probably
someone with a Novag board could do such an engine. Some
other guy sais "oh, I've this RS232, I could hook on this as
well" and another one thinks about some IP-daemon that
connects to FICS and grabs the tournament transmission from
Dortmund next year right into scid. Having an interface this
is possible otherwise all this had to be coded into scid.
> - There is no stdin / stdout in Pocket PC, I need to use
> message queues
Ok. Here you won. (They really charge money for WinCE??? ;)
Ahm, partly one would do the same as for current chess
engines to hook up with scid.
>>> If you have some nice piece sets, you can send them I
>>> will incorporate them in the file bitmaps.tcl (I prefer
>>> to embed data in tcl, and avoid the use of external
>>> files for resources used by Scid).
>> What format and dimensions?
>>
> I need one image for each size 25 to 80 by step of 5
> pixels.
Ok. I'll check this.
> Each GIF image should contain in that order (horizontal
> layout): wp wn wb wr wq wk bp bn bb br bq bk
One line I guess. Should be possible by adopting
MkXboardTheme.
> and have a transparent background.
No alpha channel, ok.
--
Kind regards,
Alexander Wagner
Universitaetsbibliothek Ilmenau
Langewiesener Str. 37
98693 Ilmenau
Tel.: 03677/69-4521 , Fax.: 03677/69-4617
-------------------------------------------------------------------------
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
Scid-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/scid-users
