WilSoft wrote:
Hi!
>> For the status: I want to finish the CC stuff first, and I'd
>> not delay 3.6.23 for Input Engine. But it's on my definite
>> list for 3.6.24 the latest. This does not mean that whats
>> there already is unusable, but Scids support for Input
>> Eninges definitely needs testing.
>
> Ok fair enough ;)
Give it a try. Its not polished (e.g. no NLS, no catch for
exceptions, probably to few lines of error handling stuff
etc.) but it should work in general. Currently I'd just
comment it for a GA, not for the cvs or an RC though where
people can have a look at whats there and still use the last
GA for productive purposes.
>> And a minor point: I've no DGT XL clock so I never tested
>> the clock code in dgtdrv2 in the wild at all. Though
>> handling the external hardware clock is implemented.
>
> I have a DGT XL clock so I will test it.
This should work as well. It could be though that there's
some functionality lacking in dgtnix, but then we could try
to add it there.
>> - How should it behave e.g. if Scid has loaded a game and
>> you set up a position?
>
> I would suggest to search the game for the first position
> where the position on the board is found and go to that
> move number.
Define: first ;) First in sequential order, first in
mainline, first considering variations, or even first from
the end of the game (with/without vars)? ;)
I feel that first in mainline, if nothing is found first in
variations, would probably what one is expecting.
>> - If you've loaded a game with variations and set up a
>> position which is reached more than once in this game,
>> how to determine where to jump to?
>
> If its possible to detect such a position (which shouldnt
> be hard to do) you can show a popup with selections
> (position found at move 1.2.3, please select). Just like
> the one which you get when variantions exists.
Would be an idea, though this will require interaction with
the keyboard/mouse. Do you have an idea of alternative
input? Ideally one could just do everything from the board,
but I think this will not be possible.
>> - How should variations input be handled? Ie. how to add
>> a variation, go over variations, go back to the
>> mainline...
>
> If the move on the board is not the next move in the
> mainline then one should be ask if a new variation must be
> added.
Consider you replay a game, say from a book. You enter the
mainline till move 10 and then the first variation is
mentioned. You want to add it there. Actually, how to
trigger "add the next moves as variation" and how to
trigger "back to the mainline"?
If you say: use the mouse/keyboard, no problem, this should
even work today. But if I want to do it from the board?
Leave var could probably be done by entering setup (removing
both kings) and setting up the mainline position again.
Kings back, scid searches that position et voila. But one
would then have to search backwards.
One point is: the DGT uses a "mode interface". There are
actually 3 modes:
- Enter White moves
- Enter Black moves
- Analysis (ie enter both moves)
Now, one could have an "add variation" event by "move now"
in analysis mode. What do you think?
A technical point is: regardless where I am in scid, I never
know it. Sounds funny, but theres no much status code or
general backend somewhere. Actually, through the realisation
of CC code I now understand a bit better how it works
internally. Maybe I could come up with some solutions here.
>> - How to move backwards in a game or jump to another
>> point?
>
> One of the problems with Fritz (you dont want to know what
> that is.. ;)) is that forward and backward jumps are not
> possible.
Oh. :) Funny. I think about problems that a huge commercial
company just solved by ignorance :)
Remembers me at the only way to make things invisible: a
huge "other-peoples-problem" field. :)
> I can imagine that if you entered a new variation, one
> goes back to the position in the mainline. The function
> mentioned in the second point should make that possible...
Which then would have to search backwards though ;)
>> - How to save the current game?
>
> Just in the regular was as it does now..
Hence, you think we should also consider the mouse/keyboard
for input as usual? Its fine with me, but a general point.
>> Note, however, that the actual hardware dependendt part is
>> NOT done in Scid but in the input engine (for the DGT this
>> could be e.g. dgtdrv2). That is, if you implement whatever
>> other hardware device as input engine you could just hook it
>> up as the driver for Scid.
>
> Nice design.
Thought that, too. Actually, still believe it :) It seems to
have some problems on CE though as CE doesn't know stdio.
>> Consider Scids support beta, the driver, well it is stable
>> for me but it lacks the testing "in the wild", and I've only
>> a serial board which I use together with a serial->USB
>> converter, meaning I never tested e.g. Bluetooth.
>
> I have an USB board.. with clock so I will test.
Great.
>> Plus, one drawback Pascal always mentiones: it needs dgtdrv2
>> + dgtnix, which talk to scid via stdio, and according to
[...]
>> my first Input Engine. (Even to port that will require some
>> work.)
>
> Why a TCL based driver?
Only for CE. Pascal thinks it would be great to have DGT
support also on CE and now unfortunately this, hm, well
"thing" doesn't know stdio, which is actually the main
backend I need for dgtdrv. :(
I perfectly agree with Pascal that it would be great to have
support for this board especially on a mobile device. That's
not the matter here, but actually my TCL knowledge is
limited (even more then my time, though it tends to switch
over, slowly ;) and talking to the DGT is on a pretty low
level resulting in a considerable amount of time for the
development of dgtnix and especially its debugging.
--
Kind regards, / War is Peace.
| Freedom is Slavery.
Alexander Wagner | Ignorance is Strength.
|
| Theory : G. Orwell, "1984"
/ In practice: USA, since 2001
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Scid-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/scid-users
