Hi Steve
Thanks for including the feature in the upstream. Wrt the points which
you have mentioned
1. Regarding visualisation towards the end: the code will auto update
the visualisation wrt the game end situations also, where suddenly a
newer depth may lead to a valid shorter pv. However it does this after
a gap of one additional depth also confirming that the shorter pv is
valid. This is to help ensure that the two different situations which
have the same symptom of shorter pv can be distinguished
unambiguously. The two situations being - passed moves being short
bcas either the engine has still not finished with creating its deeper
pv and the other case of engine created a valid shorter pv, which can
occur towards the end of the game.
2. The random based logic having the mid point text jumping around a
bit, mainly occurs especially at the beginning of analysis with
shorter depth PVs', which the engine can munch through fast, but as
the depth increases this jumping around implicitly stops. Also in my
case I show mid point numbers, only if there is a conflict of multiple
moves landing in the same square, which will occur again only once in
a while, so that possibility of jumping around in a non common case,
should be ideally fine, is what I feel.
At the same time showing move number in the landing square acts as an
easy indirect visual reference wrt the piece, compared to number in
the middle of the arrow. However for the case of multiple moves
landing on the same square, having the number additionally on the
arrow can help differentiate which move is which, i.e. the reason why
I code the flow to include both.
3. the reason why I had not used engineLineColor is to allow for the
situation where one can see the different 1st moves suggested by the
analysis engine (which uses engineLineColor, if I am not wrong) as
well as the move sequence wrt main pv (which used the new color
variable) at the same time on the analysis board, bcas both give
different but equally useful info. And having different colors (and
the thinner line wrt move sequence) helps visualise both at the same
time without affecting one another.
Because otherwise users will have to click the middle mouse button
(non-existent on laptops, and also bcas its not used by many software
these days, so any multi finger or btn+click fallbacks on touch pad,
will be unfamiliar to most) and or go and change in
tools->analysisengine, to switch between the different modes to see
both at different times.
While having both visible at the same time can help people get a feel
of what is the chain of moves that engine is evaluating as the main pv
as well as the different possible 1st moves that engine is looking at
for the current board positions. in one shot without any additional
gui interaction.
4. I think I had seen an argument "all" passed to board raise wrt
line, which inturn I had also duplicated, as I havent looked into the
semantic of raise and inturn significance of all in that context. By
any chance is it that all which impacts the performance wrt raise.
Equally given that there is a common tag shared by all the lines ie
bvm$n, so calling raise once at the end after the loop should be good
enough and avoid some load on the system.
Parallely board raise would be required where I dont call into
boardVisualiseMoves, in the updateAnalysisBoard i.e. if the moves list
is shorter case, so that pieces which will be drawn as part of the
remaining board gui refresh will mask the line/text if it overlaps
with the pieces.
Thanks once again for including in upstream, I will look at your
changes if any and come back based on above thoughts, if needed.
PS: I have a background in computer science, rather I keep jumping
between things and languages based on what I am doing (like watching
the chess championship this time), I try to limit things to the
immediately needed language syntax and roughly inferred semantics for
the task at hand, to keep myself sane. So my knowledge of tcl is very
limited, but tcl's very minimal core syntax rules and having a
read-eval-print tcl-shell did help experiment and infer to a great
extent. Additionally the open source nature also helped infer from
existing code. So also a big thank you to all open source people.
On Sat, Dec 7, 2024 at 9:15 AM Steve A <stevena...@gmail.com> wrote:
>
> Hi H.
> Ok, i'm having a decent look at this now :)
> Thanks for taking the time to learn svn. My knowledge of CVS software is
> pretty poor. Are you a computer professional, student or hobbyist like myself
> ?
>
> So i'm looking at 10-anal-moves-visualisation-needed_logics.diff now. Thanks
> for the code :) It works great... Nice feature!.
> I've adopted your logic (which *does* need fixing when we are near the end
> of a checkmated game) but I've still pushed out the things i don't like,
> sorry.
>
> Details -
>
> Yeah, that random number thing just doesn't work here... It bounces around
> all over the place. I can see you are trying to solve the problem of having
> multiple shared endpoints, but this issue *is* the reason i think we have to
> use midpoint numbering instead. The probablity of having midpoint numbers
> collide is way smaller than having endpoints collide.
>
> Ok... I'm changing the array var names to something less confusing. Sorry if
> it's harder to follow now.
> I've moved the font size calculation out of the procedure to
> ::analysis(boardSeqFont) ... maybe the size needs tweaking ?
>
> The arrows are changed to ::engineLineColor (which is changeable from
> Options->Colours->...
> The text num color a darkened shade of the line color
>
> This line
> eval $board create text [expr $x+1] [expr $y+1] -fill $colorShadow {-font
> $tfont} {-text "$stext"} {-anchor c} {-tag $tag}
> should just be
> $board create text [expr $x+1] [expr $y+1] -fill $colorShadow -font $tfont
> -text $stext -anchor c -tag $tag
> You're doing pretty good with TCL.. :) Most people give up pretty easily.
> We don't need all the "board raise". Last drawn canvas items are on-top, and
> the raise is very slow on macOS
> We don't always need the bvm$n. bvm is sufficient as the different canvas all
> all unique (with $n in their name already)
>
> I hope you're not too put out with my changes :)
> I'm pretty happy with this feature, and have committed it to svn right now.
> regards, Steve
>
> On Sat, Dec 7, 2024 at 5:49 AM C Hanish Menon <hanish...@gmail.com> wrote:
>>
>> Hi Steve,
>>
>> NOTE: Needs to be applied on top of the svn diff (ie your adaptation
>> of my original patch wrt moves visualisation) which you had sent to
>> me.
>>
>> Attached is the svn diff which includes the logics from my original
>> patch (for reasons mentioned before) as well as some minor refinements
>>
>> 1. shadow color wrt text to try ensure better visibility irrespective
>> of light or dark square/piece
>>
>> 2. use custom tag specific to this logic, so that the move
>> visualisation is not lost, even if the analysis engine move
>> visualisation logic decides to skip during a board gui refresh. This
>> can occur if there isn't enough move data as the engine is still in
>> the middle of creating the next depth move list. Additionally now in
>> such a situation the logic triggers a raise request to the board, so
>> that any chess piece doesnt hide the move numbers.
>>
>> 3. go back to move numbers being displayed at the center of the
>> landing/end square, along with prepending of move numbers if multiple
>> moves land on the same square. Additionally during the situation of
>> multiple moves having the same landing square, all moves other than
>> the 1st one in such a situation will have the move number shown
>> towards the center of the move related arrow line. Instead of showing
>> the move number at the center of the arrow, now the logic uses a
>> random number to try and random move the text between 0.3 to 0.7 part
>> of the line, to reduce chances of overlapping across different lines.
>> Also because this is plotted only for the special case of multiple
>> moves having the same landing square, the chances of move number on
>> arrows overlapping should be even more remote.
>>
>> 4. separate patch which I had sent earlier wrt forcing the
>> visualisation of moves to update, if a deeper pv leads to a shorter
>> main pv move line/list is included in this patch.
>>
>>
>> On Fri, Dec 6, 2024 at 4:23 PM C Hanish Menon <hanish...@gmail.com> wrote:
>> >
>> > Hi Steve,
>> >
>> > After looking at git-svn related info online, I have used svnsync to
>> > duplicate the remote repo locally. Not sure of how the syncing will
>> > work in future, when I have made local changes in this local repo,
>> > either way that is for another day.
>> >
>> > On Fri, Dec 6, 2024 at 2:18 PM C Hanish Menon <hanish...@gmail.com> wrote:
>> > >
>> > > Hi Steve,
>> > >
>> > > I havent used svn much in life, use git mostly when required. Last
>> > > time was like 2 decades back or so.
>> > >
>> > > I tried using svnadmin create to create a local repository
>> > >
>> > > and in turn use svn import to import upstream scidvspc into that local
>> > > repository, but it fails with
>> > >
>> > > "svn: E175013: Access to '/p/scidvspc/code/!svn/me' forbidden"
>> > >
>> > > The command I used, along with some options which I used without rtfm was
>> > >
>> > > svn import --force --no-auth-cache code
>> > > http://svn.code.sf.net/p/scidvspc/code -m "Create a local repo of
>> > > scidvspc upstream"
>> > >
>> > > The idea being to create a local repository decoupled from the
>> > > upstream, so that I can do my own experiments if required without
>> > > needing any permissions in the upstream repository, while at the same
>> > > time, if possible have a structured and ready way of importing/syncing
>> > > with upstream, if required even in future without losing any local
>> > > experiments, like with git clone/pull. But given that the above fails,
>> > > not able to work with svn. Do you have any pointers for how to go
>> > > abhout.
>> > >
>> > > On Fri, Dec 6, 2024 at 2:42 AM Steve A <stevena...@gmail.com> wrote:
>> > > >
>> > > > If you edit individual files, and send the "svn diff", would be
>> > > > better. Cheers
>> > > >
>> > > > On Friday, December 6, 2024, Steve A <stevena...@gmail.com> wrote:
>> > > >>
>> > > >> > makes the text and arrow disappear, when
>> > > >> working with a single pv from analysis engine, bcas many a times when
>> > > >> the engine is generating the next depth pv, it will generate in
>> > > >> between move lines which are very short and so useless, so also I dont
>> > > >> call boardVisualiseMoves in these cases,
>> > > >>
>> > > >> Ok, thanks for explaining this. I was a bit heavy handed here... I'm
>> > > >> busy through the week... and will look at it properly on the weekend.
>> > > >>
>> > > >> Regards.
>> > > >>
>> > > >> On Friday, December 6, 2024, C Hanish Menon <hanish...@gmail.com>
>> > > >> wrote:
>> > > >>>
>> > > >>> Hi Steve,
>> > > >>>
>> > > >>> I notice that you have reverted/changed certain aspects of my
>> > > >>> original
>> > > >>> patch. I have put the reasoning for my original flow below, and the
>> > > >>> issues of reverting/changing them
>> > > >>>
>> > > >>> 1) I am attaching an image of what I meant earlier wrt issue with
>> > > >>> placing move number in the middle of the line, and this is a simple
>> > > >>> case. There can be more complex cases where the center point will not
>> > > >>> match 0,0 wrt diff in center points, but still will have the text
>> > > >>> overlapping, so one will have to account for used font's max
>> > > >>> top-bottom and left-right boundaries wrt chars, leading to more
>> > > >>> complex mechanism to try and avoid these. While placing the number on
>> > > >>> the landing square center will make avoiding this overlapping simple
>> > > >>> and straightforward.
>> > > >>>
>> > > >>> 2) Using global(ie used in other places also) var tag, instead of
>> > > >>> tags
>> > > >>> local to boardVisualiseMoves, makes the text and arrow disappear,
>> > > >>> when
>> > > >>> working with a single pv from analysis engine, bcas many a times when
>> > > >>> the engine is generating the next depth pv, it will generate in
>> > > >>> between move lines which are very short and so useless, so also I
>> > > >>> dont
>> > > >>> call boardVisualiseMoves in these cases, so that the board can show
>> > > >>> the previous depth full move line's initial part, while the engine is
>> > > >>> building up the next depth move line. In these cases, with this
>> > > >>> modified flow, the text and arrow will disappear.
>> > > >>>
>> > > >>> 3) Using only black instead of a text color with contrasting shadow
>> > > >>> color, makes the move number non discernable in many cases.
>> > > >>>
>> > > >>> By any chance, did you want me to send you the patch (mapped to the
>> > > >>> individual tcl dir files, instead of my original applied to scid
>> > > >>> final
>> > > >>> script) after updating them to include my original logics?
>> > > >>>
>> > > >>> Also I had a look at the change you have done to the
>> > > >>> Tools->AnalysisEngine dialog, they definitely are better and make
>> > > >>> things clearer compared to previous flow. And for the case which I
>> > > >>> had
>> > > >>> mentioned in my last email, I can always potentially add a
>> > > >>> arrow+sequential entry to that drop down list, and use seperate if
>> > > >>> conditions rather than the if-else flow in your patch
>> > > >>>
>> > > >>>
>> > > >>> On Thu, Dec 5, 2024 at 6:22 PM C Hanish Menon <hanish...@gmail.com>
>> > > >>> wrote:
>> > > >>> >
>> > > >>> > Hi Steve,
>> > > >>> >
>> > > >>> > One among a few other reasons also, to directly use create line /
>> > > >>> > arrow in boardVisualiseMove was to keep the line thin and also non
>> > > >>> > interactive, so that it can overlap with the existing 1st move
>> > > >>> > arrows.
>> > > >>> > But no issues, I will have a look at the program with your updated
>> > > >>> > diff.
>> > > >>> >
>> > > >>> > And given that it is open source, I can always change, in case, if
>> > > >>> > I
>> > > >>> > want a different flow ;)
>> > > >>> >
>> > > >>> > On Thu, Dec 5, 2024 at 5:19 PM Steve A <stevena...@gmail.com>
>> > > >>> > wrote:
>> > > >>> > >
>> > > >>> > > Yeah, *sorry* Hanish but I have made quite some changes to your
>> > > >>> > > code. I find having both sets of arrows at the same time
>> > > >>> > > redundant and distracting. And my version is much more
>> > > >>> > > attractive imho.
>> > > >>> > >
>> > > >>> > > If you look at the tools->analysis widget, you'll see what I've
>> > > >>> > > done. Middle clicking the board will toggle views (I hope).
>> > > >>> > >
>> > > >>> > > Regards, S.
>> > > >>> > >
>> > > >>> > > On Thursday, December 5, 2024, C Hanish Menon
>> > > >>> > > <hanish...@gmail.com> wrote:
>> > > >>> > >>
>> > > >>> > >> Hi Steve,
>> > > >>> > >>
>> > > >>> > >> Have a query. Looking at the diff which you sent (initial
>> > > >>> > >> glance of
>> > > >>> > >> the code), it appears like you have changed the overall flow so
>> > > >>> > >> that
>> > > >>> > >> the analysis board either
>> > > >>> > >>
>> > > >>> > >> a) shows the 1st move of each move line in multipv (the existing
>> > > >>> > >> flow/feature in scidvspc) or
>> > > >>> > >> b) the visualisation of initial few moves from the main pv from
>> > > >>> > >> among
>> > > >>> > >> the multipv (the additional flow/feature which I had added).
>> > > >>> > >>
>> > > >>> > >> and not both at the same time.
>> > > >>> > >>
>> > > >>> > >> But dont you think from a user perspective, being able to see
>> > > >>> > >> both
>> > > >>> > >> parallely on the analysis board is a better flow, like what I
>> > > >>> > >> had set
>> > > >>> > >> up originally. Because both give different yet useful info,
>> > > >>> > >> that one
>> > > >>> > >> will be interested in knowing when analysing a game at the same
>> > > >>> > >> time.
>> > > >>> > >> Additionally it also has the advantage of keeping the changes
>> > > >>> > >> to the
>> > > >>> > >> existing flow very minimal.
>> > > >>> > >>
>> > > >>> > >> I feel ideally we shouldnt limit the user to select between
>> > > >>> > >> both, bcas
>> > > >>> > >> both can be used/viewed parallely, without affecting one
>> > > >>> > >> another, and
>> > > >>> > >> provide different useful info to the user. So rather I am not
>> > > >>> > >> modifying the diff you sent, instead I am attaching the
>> > > >>> > >> additional
>> > > >>> > >> patch to force mainpv analysis board visualisation update, if a
>> > > >>> > >> deeper
>> > > >>> > >> probe leads to a shorter move line, wrt the original patch
>> > > >>> > >> which I had
>> > > >>> > >> sent.
>> > > >>> > >>
>> > > >>> > >> On Thu, Dec 5, 2024 at 3:40 PM C Hanish Menon
>> > > >>> > >> <hanish...@gmail.com> wrote:
>> > > >>> > >> >
>> > > >>> > >> > Also, the reason why I didnt use the mid of the arrow to
>> > > >>> > >> > place the
>> > > >>> > >> > move number is because, if there are too many crossing moves,
>> > > >>> > >> > then the
>> > > >>> > >> > text may overlap, and trying to avoid that overlap will be
>> > > >>> > >> > bit more
>> > > >>> > >> > complicated, than if we are working with landing square
>> > > >>> > >> > center kind of
>> > > >>> > >> > flow.
>> > > >>> > >> >
>> > > >>> > >> > On Thu, Dec 5, 2024 at 3:37 PM C Hanish Menon
>> > > >>> > >> > <hanish...@gmail.com> wrote:
>> > > >>> > >> > >
>> > > >>> > >> > > Hi Steve,
>> > > >>> > >> > >
>> > > >>> > >> > > To avoid updating partial moves from the next depth, I have
>> > > >>> > >> > > a check,
>> > > >>> > >> > > that is what stops updating the board on mate or draw kind
>> > > >>> > >> > > of
>> > > >>> > >> > > situations, when the move length returned at a higher depth
>> > > >>> > >> > > may be
>> > > >>> > >> > > shorter, I have modified the logic with a seen depth
>> > > >>> > >> > > tracking to
>> > > >>> > >> > > ensure that if two subsequent depths return a shorter move
>> > > >>> > >> > > line, then
>> > > >>> > >> > > it will update the visualisation with the shorter move line.
>> > > >>> > >> > >
>> > > >>> > >> > > Will send you the patch in some time.
>> > > >>> > >> > >
>> > > >>> > >> > > On Thu, Dec 5, 2024 at 2:27 PM Steve A
>> > > >>> > >> > > <stevena...@gmail.com> wrote:
>> > > >>> > >> > > >
>> > > >>> > >> > > > Sorry to spam you.... but there might be a bug in your
>> > > >>> > >> > > > code when we reach mate too,
>> > > >>> > >> > > > (where i had introduced a bug, fixed in this version).
>> > > >>> > >> > > > Thats it for another day , Cheers, S.A.
>> > > >>> > >> > > >
>> > > >>> > >> > > >
>> > > >>> > >> > > > On Thu, Dec 5, 2024 at 5:06 PM Steve A
>> > > >>> > >> > > > <stevena...@gmail.com> wrote:
>> > > >>> > >> > > >>
>> > > >>> > >> > > >> Hi Hanish
>> > > >>> > >> > > >> Ok, We should be able to include this feature :)
>> > > >>> > >> > > >> Attached is my alpha version... could you please update
>> > > >>> > >> > > >> to subversion, then apply this patch?
>> > > >>> > >> > > >>
>> > > >>> > >> > > >> The only thing i don't really like at the moment is
>> > > >>> > >> > > >> having the extra spinbox in the engine toolbar...
>> > > >>> > >> > > >> Might change this down the road.
>> > > >>> > >> > > >> Thanks, Steven
>> > > >>> > >> > > >>
>> > > >>> > >> > > >> On Thu, Dec 5, 2024 at 3:05 PM Steve A
>> > > >>> > >> > > >> <stevena...@gmail.com> wrote:
>> > > >>> > >> > > >>>
>> > > >>> > >> > > >>> ok... I'm onto it now. I see your not using drawArrow
>> > > >>> > >> > > >>>
>> > > >>> > >> > > >>> On Thu, Dec 5, 2024 at 11:01 AM Steve A
>> > > >>> > >> > > >>> <stevena...@gmail.com> wrote:
>> > > >>> > >> > > >>>>
>> > > >>> > >> > > >>>> Otherwise, I'll do it sometime. Cheers
>> > > >>> > >> > > >>>>
>> > > >>> > >> > > >>>> On Thursday, December 5, 2024, C Hanish Menon
>> > > >>> > >> > > >>>> <hanish...@gmail.com> wrote:
>> > > >>> > >> > > >>>>>
>> > > >>> > >> > > >>>>> Hi Steve,
>> > > >>> > >> > > >>>>>
>> > > >>> > >> > > >>>>> Thanks for the feedback and thoughts.
>> > > >>> > >> > > >>>>>
>> > > >>> > >> > > >>>>> Attaching the updated patch where
>> > > >>> > >> > > >>>>>
>> > > >>> > >> > > >>>>> 1. moved the visualisation of moves into a generic
>> > > >>> > >> > > >>>>> function of its
>> > > >>> > >> > > >>>>> own, which inturn is called from updateAnalysisBoard
>> > > >>> > >> > > >>>>> function to show
>> > > >>> > >> > > >>>>> the analysis engine's main pv's initial moves
>> > > >>> > >> > > >>>>>
>> > > >>> > >> > > >>>>> 1.1. using the board argument passed to this, one can
>> > > >>> > >> > > >>>>> make the move
>> > > >>> > >> > > >>>>> visualisation to appear on the main board or any
>> > > >>> > >> > > >>>>> other board, if one
>> > > >>> > >> > > >>>>> wants to. The n argument will also need to be unique
>> > > >>> > >> > > >>>>> for each of a
>> > > >>> > >> > > >>>>> different board.
>> > > >>> > >> > > >>>>>
>> > > >>> > >> > > >>>>> 1.2. if in any other place one wants to visualise a
>> > > >>> > >> > > >>>>> sequence of moves,
>> > > >>> > >> > > >>>>> the function can be called to achieve the same and
>> > > >>> > >> > > >>>>> inturn on whichever
>> > > >>> > >> > > >>>>> board that one may want to in that context.
>> > > >>> > >> > > >>>>>
>> > > >>> > >> > > >>>>> 2. the move number text shown on the board's squares
>> > > >>> > >> > > >>>>> uses contrasting
>> > > >>> > >> > > >>>>> shadow color to try and ensure that irrespective of
>> > > >>> > >> > > >>>>> light or dark
>> > > >>> > >> > > >>>>> square and or pieces, the numbers can be potentially
>> > > >>> > >> > > >>>>> visible to an
>> > > >>> > >> > > >>>>> extent.
>> > > >>> > >> > > >>>>>
>> > > >>> > >> > > >>>>> 3. If multiple moves in the move list land on the
>> > > >>> > >> > > >>>>> same square, the
>> > > >>> > >> > > >>>>> move numbers are prepended and shown on the square.
>> > > >>> > >> > > >>>>>
>> > > >>> > >> > > >>>>> 4. bcas text creation is now handled within the move
>> > > >>> > >> > > >>>>> visualisation
>> > > >>> > >> > > >>>>> function using its own tags, the text will be
>> > > >>> > >> > > >>>>> retained on the board to
>> > > >>> > >> > > >>>>> a great extent, even when some other logic may update
>> > > >>> > >> > > >>>>> the board, if
>> > > >>> > >> > > >>>>> required.
>> > > >>> > >> > > >>>>>
>> > > >>> > >> > > >>>>> This functionality can indirectly allow users to
>> > > >>> > >> > > >>>>> visualise to an
>> > > >>> > >> > > >>>>> extent where the pieces will be after a few moves
>> > > >>> > >> > > >>>>> (currently spinbox
>> > > >>> > >> > > >>>>> limited to 8 moves), to an extent, while also seeing
>> > > >>> > >> > > >>>>> how the pieces
>> > > >>> > >> > > >>>>> reached there.
>> > > >>> > >> > > >>>>>
>> > > >>> > >> > > >>>>> Not sure if varying the shades of the arrow as one
>> > > >>> > >> > > >>>>> proceeds through
>> > > >>> > >> > > >>>>> the moves in the moves list can allow a lot more of
>> > > >>> > >> > > >>>>> the sequence of
>> > > >>> > >> > > >>>>> moves to be inferred/shown because of dependencies
>> > > >>> > >> > > >>>>> like users
>> > > >>> > >> > > >>>>> monitor's brightness and contrast settings, as well
>> > > >>> > >> > > >>>>> as possible board
>> > > >>> > >> > > >>>>> square colors and so impacting visuals. However
>> > > >>> > >> > > >>>>> because the
>> > > >>> > >> > > >>>>> visualisation of moves logic has been moved into a
>> > > >>> > >> > > >>>>> func of its own,
>> > > >>> > >> > > >>>>> changing the logic in this single location should
>> > > >>> > >> > > >>>>> allow the benefits
>> > > >>> > >> > > >>>>> of any changes to be visible wherever the moves
>> > > >>> > >> > > >>>>> visualization function
>> > > >>> > >> > > >>>>> may be used.
>> > > >>> > >> > > >>>>>
>> > > >>> > >> > > >>>>>
>> > > >>> > >> > > >>>>>
>> > > >>> > >> > > >>>>> On Wed, Dec 4, 2024 at 4:46 PM Steve A
>> > > >>> > >> > > >>>>> <stevena...@gmail.com> wrote:
>> > > >>> > >> > > >>>>> >
>> > > >>> > >> > > >>>>> > The original anal board view showed the end
>> > > >>> > >> > > >>>>> > position after the whole pv was moved. I wonder if
>> > > >>> > >> > > >>>>> > it would be desirable to limit how many moves we
>> > > >>> > >> > > >>>>> > see.
>> > > >>> > >> > > >>>>> >
>> > > >>> > >> > > >>>>> > But i'm thinking we should be making more use of
>> > > >>> > >> > > >>>>> > the arrow colors.
>> > > >>> > >> > > >>>>> > Mainly, i think we should be able to colour the
>> > > >>> > >> > > >>>>> > main PV black, then lighten up the other PV arrows
>> > > >>> > >> > > >>>>> > , perhaps in accordance to their score... Might be
>> > > >>> > >> > > >>>>> > harder to code though. I'll try to look at it on
>> > > >>> > >> > > >>>>> > the weekend
>> > > >>> > >> > > >>>>> > eg set color [gradient $::defaultForeground .6 .]
>> > > >>> > >> > > >>>>> >
>> > > >>> > >> > > >>>>> > cheers
>> > > >>> > >> > > >>>>> >
>> > > >>> > >> > > >>>>> >
>> > > >>> > >> > > >>>>> > On Wednesday, December 4, 2024, Steve A
>> > > >>> > >> > > >>>>> > <stevena...@gmail.com> wrote:
>> > > >>> > >> > > >>>>> >>
>> > > >>> > >> > > >>>>> >> It's a nice idea, just that practical issues limit
>> > > >>> > >> > > >>>>> >> its clarity. Please send me your revisions and
>> > > >>> > >> > > >>>>> >> I'll see if I can contribute to it.
>> > > >>> > >> > > >>>>> >> Cheers
>> > > >>> > >> > > >>>>> >>
>> > > >>> > >> > > >>>>> >> On Wednesday, December 4, 2024, C Hanish Menon
>> > > >>> > >> > > >>>>> >> <hanish...@gmail.com> wrote:
>> > > >>> > >> > > >>>>> >>>
>> > > >>> > >> > > >>>>> >>> Hi Steve,
>> > > >>> > >> > > >>>>> >>>
>> > > >>> > >> > > >>>>> >>> The idea behind my patch was to try and visualise
>> > > >>> > >> > > >>>>> >>> the initial few
>> > > >>> > >> > > >>>>> >>> moves of the 1st/main pv in a single/multipv
>> > > >>> > >> > > >>>>> >>> response from the engine.
>> > > >>> > >> > > >>>>> >>> And the reason was to try and make it easier to
>> > > >>> > >> > > >>>>> >>> get a feel of the
>> > > >>> > >> > > >>>>> >>> chain (or otherwise) of moves that the engine may
>> > > >>> > >> > > >>>>> >>> be
>> > > >>> > >> > > >>>>> >>> suggesting/looking-at in an easy implicit way,
>> > > >>> > >> > > >>>>> >>> without having to do
>> > > >>> > >> > > >>>>> >>> any end user driven actions on the gui (like
>> > > >>> > >> > > >>>>> >>> using +v (with or without
>> > > >>> > >> > > >>>>> >>> trial mode) and in turn looking at the moves in
>> > > >>> > >> > > >>>>> >>> detail on the main
>> > > >>> > >> > > >>>>> >>> board, by navigating through the moves).
>> > > >>> > >> > > >>>>> >>>
>> > > >>> > >> > > >>>>> >>> Also given that one may want to run different
>> > > >>> > >> > > >>>>> >>> engines parallely at the
>> > > >>> > >> > > >>>>> >>> same time, it makes more sense to visualise the
>> > > >>> > >> > > >>>>> >>> engine moves on the
>> > > >>> > >> > > >>>>> >>> respective local analysis board, rather than the
>> > > >>> > >> > > >>>>> >>> main board. This also
>> > > >>> > >> > > >>>>> >>> avoids the additional decision that needs to be
>> > > >>> > >> > > >>>>> >>> made otherwise of
>> > > >>> > >> > > >>>>> >>> which of the engine's main pv to show on the main
>> > > >>> > >> > > >>>>> >>> board, if the main
>> > > >>> > >> > > >>>>> >>> board were to be used. While parallely giving the
>> > > >>> > >> > > >>>>> >>> flexibility of
>> > > >>> > >> > > >>>>> >>> viewing main pv of multiple engines parallely in
>> > > >>> > >> > > >>>>> >>> their separate
>> > > >>> > >> > > >>>>> >>> analysis boards.
>> > > >>> > >> > > >>>>> >>>
>> > > >>> > >> > > >>>>> >>> Also keeping the logic to be a simple
>> > > >>> > >> > > >>>>> >>> visualisation and not
>> > > >>> > >> > > >>>>> >>> interaction with the corresponding visualisation,
>> > > >>> > >> > > >>>>> >>> ensures that the
>> > > >>> > >> > > >>>>> >>> already existing logic of showing the 1st move of
>> > > >>> > >> > > >>>>> >>> the different
>> > > >>> > >> > > >>>>> >>> multiple pv's that the engine generates on the
>> > > >>> > >> > > >>>>> >>> analysis board and in
>> > > >>> > >> > > >>>>> >>> turn clicking it to use as the move on the main
>> > > >>> > >> > > >>>>> >>> board, doesnt get
>> > > >>> > >> > > >>>>> >>> affected/overloaded in any way. Nor needed given
>> > > >>> > >> > > >>>>> >>> that the idea was to
>> > > >>> > >> > > >>>>> >>> visualise the initial few moves in the engine's
>> > > >>> > >> > > >>>>> >>> main pv (among
>> > > >>> > >> > > >>>>> >>> single/multipv).
>> > > >>> > >> > > >>>>> >>>
>> > > >>> > >> > > >>>>> >>> Also at a different level, not sure why, but I am
>> > > >>> > >> > > >>>>> >>> not seeing the 1st
>> > > >>> > >> > > >>>>> >>> move each of the different multipv's generated by
>> > > >>> > >> > > >>>>> >>> the analysis engine,
>> > > >>> > >> > > >>>>> >>> on the main board, after enabling show arrows in
>> > > >>> > >> > > >>>>> >>> Tools->AnalysisEngine.
>> > > >>> > >> > > >>>>> >>>
>> > > >>> > >> > > >>>>> >>> PS: I am refining my patch further like using
>> > > >>> > >> > > >>>>> >>> shadow colors to make
>> > > >>> > >> > > >>>>> >>> the text more visible irrespective of underlying
>> > > >>> > >> > > >>>>> >>> square or piece is
>> > > >>> > >> > > >>>>> >>> light or dark; look at using dict to allow
>> > > >>> > >> > > >>>>> >>> showing move numbers of
>> > > >>> > >> > > >>>>> >>> multiple moves landing on same square; try ensure
>> > > >>> > >> > > >>>>> >>> that move numbers
>> > > >>> > >> > > >>>>> >>> remain on screen, even when engine is in the
>> > > >>> > >> > > >>>>> >>> middle of building up the
>> > > >>> > >> > > >>>>> >>> next deeper level pv (rather I had purposefully
>> > > >>> > >> > > >>>>> >>> not looked at adding
>> > > >>> > >> > > >>>>> >>> support for that to act as a indication that what
>> > > >>> > >> > > >>>>> >>> is being visualised
>> > > >>> > >> > > >>>>> >>> in not the latest one, but the previous one, bcas
>> > > >>> > >> > > >>>>> >>> engine is still in
>> > > >>> > >> > > >>>>> >>> middle of building the current deeper pv; however
>> > > >>> > >> > > >>>>> >>> when switching
>> > > >>> > >> > > >>>>> >>> between different engine tabs, it is not
>> > > >>> > >> > > >>>>> >>> practical to try remember the
>> > > >>> > >> > > >>>>> >>> not shown move numbers). I may be done with these
>> > > >>> > >> > > >>>>> >>> changes in a day or
>> > > >>> > >> > > >>>>> >>> two, depending on as and when I can steal time to
>> > > >>> > >> > > >>>>> >>> work on this.
>> > > >>> > >> > > >>>>> >>>
>> > > >>> > >> > > >>>>> >>> On Tue, Dec 3, 2024 at 4:32 PM Steve A
>> > > >>> > >> > > >>>>> >>> <stevena...@gmail.com> wrote:
>> > > >>> > >> > > >>>>> >>> >
>> > > >>> > >> > > >>>>> >>> > Hmmm - it's interesting , but pretty raw and
>> > > >>> > >> > > >>>>> >>> > not something i'd use. But cheers.
>> > > >>> > >> > > >>>>> >>> >
>> > > >>> > >> > > >>>>> >>> > I thought for a second you were making a patch
>> > > >>> > >> > > >>>>> >>> > to draw the engine arrows on the main board,
>> > > >>> > >> > > >>>>> >>> > which lots of GUIs do already.
>> > > >>> > >> > > >>>>> >>> > This is also something i'm not too especially
>> > > >>> > >> > > >>>>> >>> > keen on because we have arrows everywhere
>> > > >>> > >> > > >>>>> >>> > already! :) And it presents lots of unresolved
>> > > >>> > >> > > >>>>> >>> > issues.
>> > > >>> > >> > > >>>>> >>> > .... But, since i *do* already have a quick
>> > > >>> > >> > > >>>>> >>> > patch that does this, I thought to add it to
>> > > >>> > >> > > >>>>> >>> > svn (which i've done just now, and also
>> > > >>> > >> > > >>>>> >>> > attached below).
>> > > >>> > >> > > >>>>> >>> > To see the arrows, you''ll have to select "Show
>> > > >>> > >> > > >>>>> >>> > Arrows" in Tools->AnalysisEngines.
>> > > >>> > >> > > >>>>> >>> > Cheers, S.A.
>> > > >>> > >> > > >>>>> >>> >
>> > > >>> > >> > > >>>>> >>> > On Tue, Dec 3, 2024 at 7:22 AM C Hanish Menon
>> > > >>> > >> > > >>>>> >>> > <hanish...@gmail.com> wrote:
>> > > >>> > >> > > >>>>> >>> >>
>> > > >>> > >> > > >>>>> >>> >> Hi Steve,
>> > > >>> > >> > > >>>>> >>> >>
>> > > >>> > >> > > >>>>> >>> >> I have tried adding support for simple
>> > > >>> > >> > > >>>>> >>> >> visualising of the main pv
>> > > >>> > >> > > >>>>> >>> >> generated by uci engine on the analysis board.
>> > > >>> > >> > > >>>>> >>> >> The user can control
>> > > >>> > >> > > >>>>> >>> >> how many moves ahead to show on the board,
>> > > >>> > >> > > >>>>> >>> >> using a spinbox I have
>> > > >>> > >> > > >>>>> >>> >> added next to the show analysis board
>> > > >>> > >> > > >>>>> >>> >> checkbox/button.
>> > > >>> > >> > > >>>>> >>> >>
>> > > >>> > >> > > >>>>> >>> >> I am attaching the patch with the email and a
>> > > >>> > >> > > >>>>> >>> >> sample image of how it appears.
>> > > >>> > >> > > >>>>> >>> >>
>> > > >>> > >> > > >>>>> >>> >> NOTE: I have patched the scid file directly. I
>> > > >>> > >> > > >>>>> >>> >> am not a tcl/tk
>> > > >>> > >> > > >>>>> >>> >> programmer, I have looked at the code in scid
>> > > >>> > >> > > >>>>> >>> >> and tried to
>> > > >>> > >> > > >>>>> >>> >> structure/implement the patch to get the job
>> > > >>> > >> > > >>>>> >>> >> done. There is a small
>> > > >>> > >> > > >>>>> >>> >> probability that I may not be doing things the
>> > > >>> > >> > > >>>>> >>> >> tcltk way.
>> > > >>> > >> > > >>>>> >>> >>
>> > > >>> > >> > > >>>>> >>> >> On Sat, Nov 30, 2024 at 6:58 PM C Hanish Menon
>> > > >>> > >> > > >>>>> >>> >> <hanish...@gmail.com> wrote:
>> > > >>> > >> > > >>>>> >>> >> >
>> > > >>> > >> > > >>>>> >>> >> > Hi Steve,
>> > > >>> > >> > > >>>>> >>> >> >
>> > > >>> > >> > > >>>>> >>> >> > Thanks for adapting and incorporating the
>> > > >>> > >> > > >>>>> >>> >> > patches.
>> > > >>> > >> > > >>>>> >>> >> >
>> > > >>> > >> > > >>>>> >>> >> > Regarding snap, I dont think I have
>> > > >>> > >> > > >>>>> >>> >> > currently set %F, it's been a long
>> > > >>> > >> > > >>>>> >>> >> > time, I normally start from the command
>> > > >>> > >> > > >>>>> >>> >> > line. However it is a good
>> > > >>> > >> > > >>>>> >>> >> > input, which can be useful for many, will
>> > > >>> > >> > > >>>>> >>> >> > update it.
>> > > >>> > >> > > >>>>> >>> >> >
>> > > >>> > >> > > >>>>> >>> >> > Previously in the snapcraft.yaml file, which
>> > > >>> > >> > > >>>>> >>> >> > I am also bundling with
>> > > >>> > >> > > >>>>> >>> >> > snap, I was fetching the latest svn commit
>> > > >>> > >> > > >>>>> >>> >> > and creating a snap of it,
>> > > >>> > >> > > >>>>> >>> >> > so that anyone attempting to create snap on
>> > > >>> > >> > > >>>>> >>> >> > their own can get the
>> > > >>> > >> > > >>>>> >>> >> > latest svn commit based version. But with
>> > > >>> > >> > > >>>>> >>> >> > the new version of snapcraft
>> > > >>> > >> > > >>>>> >>> >> > (used to create snap), they seem to have
>> > > >>> > >> > > >>>>> >>> >> > removed/goofed up the svn
>> > > >>> > >> > > >>>>> >>> >> > fetch logic, so I am using the tar file of
>> > > >>> > >> > > >>>>> >>> >> > the scidvspc release. Need
>> > > >>> > >> > > >>>>> >>> >> > to check, how to patch in svn fetching again
>> > > >>> > >> > > >>>>> >>> >> > wrt snapcraft may be by
>> > > >>> > >> > > >>>>> >>> >> > overriding its default fetch flow, so that
>> > > >>> > >> > > >>>>> >>> >> > people can create snap
>> > > >>> > >> > > >>>>> >>> >> > using the latest commit, if possible.
>> > > >>> > >> > > >>>>> >>> >> >
>> > > >>> > >> > > >>>>> >>> >> > Given that you would be familiar with
>> > > >>> > >> > > >>>>> >>> >> > sourceforge and its svn, by any
>> > > >>> > >> > > >>>>> >>> >> > chance, do you know, if there is a standard
>> > > >>> > >> > > >>>>> >>> >> > url one could try to fetch
>> > > >>> > >> > > >>>>> >>> >> > to get an archive / tar of the latest svn
>> > > >>> > >> > > >>>>> >>> >> > commit of a project hosted
>> > > >>> > >> > > >>>>> >>> >> > on sourceforge svn.
>> > > >>> > >> > > >>>>> >>> >> >
>> > > >>> > >> > > >>>>> >>> >> > On Sat, Nov 30, 2024 at 3:13 AM Steve A
>> > > >>> > >> > > >>>>> >>> >> > <stevena...@gmail.com> wrote:
>> > > >>> > >> > > >>>>> >>> >> > >
>> > > >>> > >> > > >>>>> >>> >> > > Thanks Hanish. I've adopted or tweaked all
>> > > >>> > >> > > >>>>> >>> >> > > your changes and made a commit. (I've
>> > > >>> > >> > > >>>>> >>> >> > > given the analysis boards identical coord
>> > > >>> > >> > > >>>>> >>> >> > > setup to the main board, but making the
>> > > >>> > >> > > >>>>> >>> >> > > font smaller).
>> > > >>> > >> > > >>>>> >>> >> > > https://sourceforge.net/p/scidvspc/code/3485/
>> > > >>> > >> > > >>>>> >>> >> > >
>> > > >>> > >> > > >>>>> >>> >> > > P.S. Thanks for creating the snap package.
>> > > >>> > >> > > >>>>> >>> >> > > I think i recently had some correspondence
>> > > >>> > >> > > >>>>> >>> >> > > about it. Do you include the %F arg (or
>> > > >>> > >> > > >>>>> >>> >> > > similar) in your scidvspc.desktop file (ie
>> > > >>> > >> > > >>>>> >>> >> > > "Exec=scid %F"). This allows opening
>> > > >>> > >> > > >>>>> >>> >> > > desired files.
>> > > >>> > >> > > >>>>> >>> >> > >
>> > > >>> > >> > > >>>>> >>> >> > > Regards Steven.
>> > > >>> > >> > > >>>>> >>> >> > >
>> > > >>> > >> > > >>>>> >>> >> > > On Sat, Nov 30, 2024 at 2:12 AM C Hanish
>> > > >>> > >> > > >>>>> >>> >> > > Menon <hanish...@gmail.com> wrote:
>> > > >>> > >> > > >>>>> >>> >> > >>
>> > > >>> > >> > > >>>>> >>> >> > >> Hi,
>> > > >>> > >> > > >>>>> >>> >> > >>
>> > > >>> > >> > > >>>>> >>> >> > >> I follow and explore chess very very
>> > > >>> > >> > > >>>>> >>> >> > >> infrequently, like once in a few
>> > > >>> > >> > > >>>>> >>> >> > >> years, usually when maybe a chess
>> > > >>> > >> > > >>>>> >>> >> > >> championship is going on or hear
>> > > >>> > >> > > >>>>> >>> >> > >> something about a new chess engine or I
>> > > >>> > >> > > >>>>> >>> >> > >> am experimenting something or
>> > > >>> > >> > > >>>>> >>> >> > >> so.
>> > > >>> > >> > > >>>>> >>> >> > >>
>> > > >>> > >> > > >>>>> >>> >> > >> So also I am not good at visualizing text
>> > > >>> > >> > > >>>>> >>> >> > >> chess move lines/variations
>> > > >>> > >> > > >>>>> >>> >> > >> without having visual hint like
>> > > >>> > >> > > >>>>> >>> >> > >> coordinates on a chess board.
>> > > >>> > >> > > >>>>> >>> >> > >>
>> > > >>> > >> > > >>>>> >>> >> > >> Given that currently ScidVsPC doesnt have
>> > > >>> > >> > > >>>>> >>> >> > >> an option for the same wrt
>> > > >>> > >> > > >>>>> >>> >> > >> analysis board, have created this patch
>> > > >>> > >> > > >>>>> >>> >> > >> (03- patch file name) to
>> > > >>> > >> > > >>>>> >>> >> > >> enable the same. If the user enables
>> > > >>> > >> > > >>>>> >>> >> > >> coordinates on all sides wrt the
>> > > >>> > >> > > >>>>> >>> >> > >> main board (ie boardCoords value 2), then
>> > > >>> > >> > > >>>>> >>> >> > >> this logic will enable
>> > > >>> > >> > > >>>>> >>> >> > >> coordinates on the analysis board.
>> > > >>> > >> > > >>>>> >>> >> > >>
>> > > >>> > >> > > >>>>> >>> >> > >> Inturn when working on this, noticed that
>> > > >>> > >> > > >>>>> >>> >> > >> the board::flip logic wasn't
>> > > >>> > >> > > >>>>> >>> >> > >> setting the vertical (1-8) coordinate
>> > > >>> > >> > > >>>>> >>> >> > >> values correctly for the
>> > > >>> > >> > > >>>>> >>> >> > >> analysis board always, it seemed to have
>> > > >>> > >> > > >>>>> >>> >> > >> a race based on when the
>> > > >>> > >> > > >>>>> >>> >> > >> board gets enabled and when the user
>> > > >>> > >> > > >>>>> >>> >> > >> toggles board coords. So have
>> > > >>> > >> > > >>>>> >>> >> > >> created a additional patch (04- patch
>> > > >>> > >> > > >>>>> >>> >> > >> file name) which sets the labels
>> > > >>> > >> > > >>>>> >>> >> > >> based purely on flip variable. NOTE: Not
>> > > >>> > >> > > >>>>> >>> >> > >> able to reproduce this
>> > > >>> > >> > > >>>>> >>> >> > >> currently, dont remember the sequence of
>> > > >>> > >> > > >>>>> >>> >> > >> enabling different options
>> > > >>> > >> > > >>>>> >>> >> > >> and boards, but did notice it few times
>> > > >>> > >> > > >>>>> >>> >> > >> initially, when I was working
>> > > >>> > >> > > >>>>> >>> >> > >> with only 03- patch file. Also this 04-
>> > > >>> > >> > > >>>>> >>> >> > >> patch file makes the logic
>> > > >>> > >> > > >>>>> >>> >> > >> directly depend on flip variable rather
>> > > >>> > >> > > >>>>> >>> >> > >> than any value that may be
>> > > >>> > >> > > >>>>> >>> >> > >> already there wrt the labels. So feel
>> > > >>> > >> > > >>>>> >>> >> > >> this may be a better logic.
>> > > >>> > >> > > >>>>> >>> >> > >>
>> > > >>> > >> > > >>>>> >>> >> > >>
>> > > >>> > >> > > >>>>> >>> >> > >> NOTE: I had created & inturn maintain
>> > > >>> > >> > > >>>>> >>> >> > >> scidvspc-hkvc snap package, to
>> > > >>> > >> > > >>>>> >>> >> > >> run scidvspc on linux distros with snap
>> > > >>> > >> > > >>>>> >>> >> > >> package system support, which
>> > > >>> > >> > > >>>>> >>> >> > >> again I update once in a bluemoon. These
>> > > >>> > >> > > >>>>> >>> >> > >> patches are included in the
>> > > >>> > >> > > >>>>> >>> >> > >> version which I have released there. I
>> > > >>> > >> > > >>>>> >>> >> > >> have added the suffix -hkvc to
>> > > >>> > >> > > >>>>> >>> >> > >> ensure that in future if the scidvspc
>> > > >>> > >> > > >>>>> >>> >> > >> team wants to release their own
>> > > >>> > >> > > >>>>> >>> >> > >> snap package, there is no confusion.
>> > > >>> > >> > > >>>>> >>> >> > >> These patches can be
>> > > >>> > >> > > >>>>> >>> >> > >> tested/verified by running the
>> > > >>> > >> > > >>>>> >>> >> > >> scidvspc-hkvc snap package, if needed.
>> > > >>> > >> > > >>>>> >>> >> > >>
>> > > >>> > >> > > >>>>> >>> >> > >> --
>> > > >>> > >> > > >>>>> >>> >> > >> Keep ;-)
>> > > >>> > >> > > >>>>> >>> >> > >> HanishKVC
>> > > >>> > >> > > >>>>> >>> >> > >> _______________________________________________
>> > > >>> > >> > > >>>>> >>> >> > >> Scidvspc-users mailing list
>> > > >>> > >> > > >>>>> >>> >> > >> Scidvspc-users@lists.sourceforge.net
>> > > >>> > >> > > >>>>> >>> >> > >> https://lists.sourceforge.net/lists/listinfo/scidvspc-users
>> > > >>> > >> > > >>>>> >>> >> >
>> > > >>> > >> > > >>>>> >>> >> >
>> > > >>> > >> > > >>>>> >>> >> >
>> > > >>> > >> > > >>>>> >>> >> > --
>> > > >>> > >> > > >>>>> >>> >> > Keep ;-)
>> > > >>> > >> > > >>>>> >>> >> > HanishKVC
>> > > >>> > >> > > >>>>> >>> >>
>> > > >>> > >> > > >>>>> >>> >>
>> > > >>> > >> > > >>>>> >>> >>
>> > > >>> > >> > > >>>>> >>> >> --
>> > > >>> > >> > > >>>>> >>> >> Keep ;-)
>> > > >>> > >> > > >>>>> >>> >> HanishKVC
>> > > >>> > >> > > >>>>> >>>
>> > > >>> > >> > > >>>>> >>>
>> > > >>> > >> > > >>>>> >>>
>> > > >>> > >> > > >>>>> >>> --
>> > > >>> > >> > > >>>>> >>> Keep ;-)
>> > > >>> > >> > > >>>>> >>> HanishKVC
>> > > >>> > >> > > >>>>>
>> > > >>> > >> > > >>>>>
>> > > >>> > >> > > >>>>>
>> > > >>> > >> > > >>>>> --
>> > > >>> > >> > > >>>>> Keep ;-)
>> > > >>> > >> > > >>>>> HanishKVC
>> > > >>> > >> > >
>> > > >>> > >> > >
>> > > >>> > >> > >
>> > > >>> > >> > > --
>> > > >>> > >> > > Keep ;-)
>> > > >>> > >> > > HanishKVC
>> > > >>> > >> >
>> > > >>> > >> >
>> > > >>> > >> >
>> > > >>> > >> > --
>> > > >>> > >> > Keep ;-)
>> > > >>> > >> > HanishKVC
>> > > >>> > >>
>> > > >>> > >>
>> > > >>> > >>
>> > > >>> > >> --
>> > > >>> > >> Keep ;-)
>> > > >>> > >> HanishKVC
>> > > >>> >
>> > > >>> >
>> > > >>> >
>> > > >>> > --
>> > > >>> > Keep ;-)
>> > > >>> > HanishKVC
>> > > >>>
>> > > >>>
>> > > >>>
>> > > >>> --
>> > > >>> Keep ;-)
>> > > >>> HanishKVC
>> > >
>> > >
>> > >
>> > > --
>> > > Keep ;-)
>> > > HanishKVC
>> >
>> >
>> >
>> > --
>> > Keep ;-)
>> > HanishKVC
>>
>>
>>
>> --
>> Keep ;-)
>> HanishKVC
--
Keep ;-)
HanishKVC
_______________________________________________
Scidvspc-users mailing list
Scidvspc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/scidvspc-users
