scidvspc-users

[Scidvspc-users] Clock window

[Miguel Á. <ss...@gm...>]

Hi!

Is it possible to dock the clocks window into main window?
If it is, how?
If it isn't: this is a feature request.
Now is difficult to have the clocks window visible all the game because it
is hided by other windows when focus changes.

Thank you.

Miguel Ángel

Re: [Scidvspc-users] Text in engine analysis window too light

[Steve B. <ste...@gm...>]

In scid.gui, at line 141520, I changed "set color grey50" to "set color 
grey10", saved scid.gui back to disk, launched scid.exe, but that had no 
effect on the color of those two lines of text. They are still the same 
light shade of grey. I tried other colors, such as "set color navy", but 
that still had no effect.

On 6/2/2025 01:26, Steve A wrote:
> In this line in tcl/tools/analysis.tcl (or scid gui)
> "set color grey50"
> change grey50 to some other valid tcl color
> (eg https://wiki.tcl-lang.org/page/Colors+with+Names)
>
> On Mon, Jun 2, 2025 at 1:42 AM Steve Brown 
> <ste...@gm...> wrote:
>
>     I need to find a way to make the text for variations besides the main
>     variation in the engine analysis window darker. As it is, the
>     light-gray
>     text is difficult for me to read. Screenshot attached.
>     _______________________________________________
>     Scidvspc-users mailing list
>     Sci...@li...
>     https://lists.sourceforge.net/lists/listinfo/scidvspc-users
>

Re: [Scidvspc-users] Text in engine analysis window too light

[Steve A <ste...@gm...>]

In this line in tcl/tools/analysis.tcl (or scid gui)
"set color grey50"
change grey50 to some other valid tcl color
(eg https://wiki.tcl-lang.org/page/Colors+with+Names)

On Mon, Jun 2, 2025 at 1:42 AM Steve Brown <ste...@gm...>
wrote:

> I need to find a way to make the text for variations besides the main
> variation in the engine analysis window darker. As it is, the light-gray
> text is difficult for me to read. Screenshot attached.
> _______________________________________________
> Scidvspc-users mailing list
> Sci...@li...
> https://lists.sourceforge.net/lists/listinfo/scidvspc-users
>

[Scidvspc-users] Text in engine analysis window too light

[Steve B. <ste...@gm...>]

I need to find a way to make the text for variations besides the main 
variation in the engine analysis window darker. As it is, the light-gray 
text is difficult for me to read. Screenshot attached.

Re: [Scidvspc-users] 4.26 release candidates

[Steve A <ste...@gm...>]

OK, the exes have been changed today, because of  a single line fix to stop
stockfish 17 throwing a tizz during annotation.

Cheers

On Tuesday, February 4, 2025, Steve A <ste...@gm...> wrote:

> Hi everyone,
> 4.26 rcs are up now. (Mac 32 bit later) which - if no major problems -
> will become the releases proper.
>
> Thanks to Oz for the win builds and Hanish for the scorebar.
>
>  https://sourceforge.net/projects/scidvspc/files/
> Cheers S. A
>
>
>   Scid vs. PC 4.26
>
>     Scorebar for the Main board, and also Browser windows and Fics
> observed games
>     Analysis board improvements from Hanish
>     - Scorebar, Colour PV Bar, Move-Sequence arrows, and board coordinates
>
>     Clicking Crosstable 'Player' column title to sort
>     New 'Store Movetimes' option in Play UCI Game
>     Show longer variations in the EnterVar button at game end
>     Twin Game Checker has a few new clickables
>     Font Selection dialog has a working preview
>     Game saves don't interrupt engine analysis, and tweak engine help icon
>     Gamelist current game colour option (via switcher context menu)
>     Player Ratings context/history menu
>     Cut down our excess Resize event handling
>     Properly handle 'Stop Analysis' for Xboard engine with no 'analyze'
> (eg Scidlet)
>     Minor Fics improvements
>     More Latex export improvements
>
>     Hack to avoid MacOS Tree/Bestgames window crash
>     Fix Multi Browse BestGames didn't work for 'other' bases.
>     Fix Pgn column mode with big fonts
>     Enable proper horizontal gamelist scrolling for MacOS
>     Truncate long DB filenames in the Gamelist Tab and DB switcher
>     Disable Tree adjust after a General Search
>     Fix Undocked App fails to quit with an open engine
>     Update "Enter Var" button when we create a variation
>     Try to remove unicode related fluff when pasting text as fen
>
>
>

[Scidvspc-users] 4.26 release candidates

[Steve A <ste...@gm...>]

Hi everyone,
4.26 rcs are up now. (Mac 32 bit later) which - if no major problems - will
become the releases proper.

Thanks to Oz for the win builds and Hanish for the scorebar.

 https://sourceforge.net/projects/scidvspc/files/
Cheers S. A


  Scid vs. PC 4.26

    Scorebar for the Main board, and also Browser windows and Fics observed
games
    Analysis board improvements from Hanish
    - Scorebar, Colour PV Bar, Move-Sequence arrows, and board coordinates

    Clicking Crosstable 'Player' column title to sort
    New 'Store Movetimes' option in Play UCI Game
    Show longer variations in the EnterVar button at game end
    Twin Game Checker has a few new clickables
    Font Selection dialog has a working preview
    Game saves don't interrupt engine analysis, and tweak engine help icon
    Gamelist current game colour option (via switcher context menu)
    Player Ratings context/history menu
    Cut down our excess Resize event handling
    Properly handle 'Stop Analysis' for Xboard engine with no 'analyze' (eg
Scidlet)
    Minor Fics improvements
    More Latex export improvements

    Hack to avoid MacOS Tree/Bestgames window crash
    Fix Multi Browse BestGames didn't work for 'other' bases.
    Fix Pgn column mode with big fonts
    Enable proper horizontal gamelist scrolling for MacOS
    Truncate long DB filenames in the Gamelist Tab and DB switcher
    Disable Tree adjust after a General Search
    Fix Undocked App fails to quit with an open engine
    Update "Enter Var" button when we create a variation
    Try to remove unicode related fluff when pasting text as fen

[Scidvspc-users] Upcoming Scid vs PC 4.26

[Steve A <ste...@gm...>]

Hi all,
4.26 should be out in a few weeks or so. :).
Nice new feature finalised this month is a score-bar for the main, fics
observed games and game-browser boards.

Any volunteers on translations ???

You can find the files here
  https://sourceforge.net/p/scidvspc/code/HEAD/tree/tcl/lang/
to download your lang and just edit the TODOs and send the new file to me.
Cheers S.A.

$grep -c TODO `czech.tcl deutsch.tcl finnish.tcl francais.tcl greek.tcl
hungary.tcl italian.tcl nederlan.tcl norsk.tcl polish.tcl portbr.tcl
port.tcl russian.tcl serbian.tcl spanish.tcl swedish.tcl turkish.tcl` |
sort -t : -k 2 -g

deutsch.tcl:7
portbr.tcl:18
port.tcl:20
francais.tcl:30
norsk.tcl:43
spanish.tcl:64
turkish.tcl:71
finnish.tcl:72
russian.tcl:121
polish.tcl:144
greek.tcl:154
nederlan.tcl:155
swedish.tcl:165
italian.tcl:297
czech.tcl:463
hungary.tcl:482
serbian.tcl:600

[Scidvspc-users] Playing without seeing

[T R. <six...@gm...>]

Hello,

I would like to suggest that the option of playing blindly be implemented
in the confrontation with the machine, with only the origin and destination
squares being indicated.

And thank you.

[Scidvspc-users] Dev mailing list

[Steve A <ste...@gm...>]

Hi guys, just a quick note there is now a developer mailing list, which can
be found here.
https://sourceforge.net/p/scidvspc/mailman/

Maybe Hanish will keep posting there - as I've kicked him from Users :).
Regards S. A.

Re: [Scidvspc-users] Patch: Analboard MovesVisualisation: Longer visualisation, SeqNum only for last few

[C H. M. <han...@gm...>]

Hi,

This also allows the user to indirectly walk through the pv by
increasing or decreasing the visualisation depth spinbox by 1 at a
time, and in turn having seq number shown only for the last few moves
in the move line that has been visualised. Thus helping easily see
which is the new move that has been shown (if increasing) or hidden
(if decreasing) from the pv.

On Wed, Dec 18, 2024 at 2:06 AM C Hanish Menon <han...@gm...> wrote:
>
> Hi Steve,
>
> To help view deeper/longer into the PV from the analysis engine, allow
> the spinbox of visualisation depth to be increased upto 64 from
> initial limit which I had previously set at 8.
>
> At the same time to avoid cluttering the board with seq numbers, now
> move seq numbers will be shown only for the last few moves relative to
> the specified visualisation depth.
>
> NOTE1: Purposefully calculating the window of seq numbers to show
> relative to user set visualisation depth and not the number of moves
> in the pv, so that if reqd user can indirectly avoid any and all seq
> numbers from being shown on the board, by setting the vis depth to be
> much larger than the current engine pv depth. So that board shows only
> the move visualisation lines/arrows and not any seq numbers.
>
> Users can control the window/amount of seq numbers to show, through options.dat.
>
> Also I have reduced the font size by 20% so that it doesnt occupy too
> much of the square spaces. Also I have uncommented the text
> shadow/highlight plotting and made the gradient logic create a very
> light shade rather than a darker shade.
>
> NOTE2: This patch is generated relative to the two patches which I
> submitted on the mailing list yesterday.
>
> On Tue, Dec 17, 2024 at 2:52 AM C Hanish Menon <han...@gm...> wrote:
> >
> > Hi Steve,
> >
> > Attaching two patches
> >
> > 1. Define variables which get managed through options.dat, for the
> > colors used wrt BoardVisualiseMoves Odd and Even lines, so that user
> > can configure/change the same if required.
> >
> > 2. Allow user to select which engine PV from among MultiPVs to show on
> > analysis board wrt moves visualisation.
> >
> >
> >
> > --
> > Keep ;-)
> > HanishKVC
>
>
>
> --
> Keep ;-)
> HanishKVC



-- 
Keep ;-)
HanishKVC

[Scidvspc-users] Patch: Analboard MovesVisualisation: Longer visualisation, SeqNum only for last few

[C H. M. <han...@gm...>]

Hi Steve,

To help view deeper/longer into the PV from the analysis engine, allow
the spinbox of visualisation depth to be increased upto 64 from
initial limit which I had previously set at 8.

At the same time to avoid cluttering the board with seq numbers, now
move seq numbers will be shown only for the last few moves relative to
the specified visualisation depth.

NOTE1: Purposefully calculating the window of seq numbers to show
relative to user set visualisation depth and not the number of moves
in the pv, so that if reqd user can indirectly avoid any and all seq
numbers from being shown on the board, by setting the vis depth to be
much larger than the current engine pv depth. So that board shows only
the move visualisation lines/arrows and not any seq numbers.

Users can control the window/amount of seq numbers to show, through options.dat.

Also I have reduced the font size by 20% so that it doesnt occupy too
much of the square spaces. Also I have uncommented the text
shadow/highlight plotting and made the gradient logic create a very
light shade rather than a darker shade.

NOTE2: This patch is generated relative to the two patches which I
submitted on the mailing list yesterday.

On Tue, Dec 17, 2024 at 2:52 AM C Hanish Menon <han...@gm...> wrote:
>
> Hi Steve,
>
> Attaching two patches
>
> 1. Define variables which get managed through options.dat, for the
> colors used wrt BoardVisualiseMoves Odd and Even lines, so that user
> can configure/change the same if required.
>
> 2. Allow user to select which engine PV from among MultiPVs to show on
> analysis board wrt moves visualisation.
>
>
>
> --
> Keep ;-)
> HanishKVC



-- 
Keep ;-)
HanishKVC

[Scidvspc-users] Patch: Analboard MovesVisualisation: Select from among Engine MultiPV, UserCfg lines color

[C H. M. <han...@gm...>]

Hi Steve,

Attaching two patches

1. Define variables which get managed through options.dat, for the
colors used wrt BoardVisualiseMoves Odd and Even lines, so that user
can configure/change the same if required.

2. Allow user to select which engine PV from among MultiPVs to show on
analysis board wrt moves visualisation.



-- 
Keep ;-)
HanishKVC

[Scidvspc-users] Switch between Current Side, Opposite Side and Both Sides wrt MainPV Moves Visualisation

[C H. M. <han...@gm...>]

Hi Steve,

This is a patch which allows users in Sequential analysis boardType
mode, to switch between looking at only Current side-to-move moves or
only Opposite side moves or both sides moves from the MainPV of the
engine on the analysis board.

Thus giving more flexibility wrt what one may want to look at from the
analysis engine's mainpv, also indirectly allowing one to probe more
into the mainpv without cluttering the board.

Inturn to help with the same, a listbox is shown next to the analysis
board in Sequential mode. So that user can switch between these views.

NOTE1:  I have also cleaned up the space-tab usage to be consistent
wrt the block of code in updateAnalysisBoard wrt boardVisualiseMoves,
to only use spaces.

NOTE2: Given that "1st moves from all multiPVs" and "SeqOfMoves in
MainPV" are orthogonal to one another and useful to view parallely at
the same time. I would request you to reconsider your decision to have
them as independent/exclusive modes, which does not allow both to be
viewed at the same time. Do note that both types of arrows use
different colors, so it is visually clearly differentiable without any
confusion. Also one can always disable moves-sequence visualisation by
turning the spinbox down to 0, if needed, while the default of 3 also
doesnt clutter the board.

-- 
Keep ;-)
HanishKVC

Re: [Scidvspc-users] Patch ScidVsPC - Allow visualisation of Main PV on analysis board

[C H. M. <han...@gm...>]

Hi Steve,

There is a oversight wrt scoremate check (checking for empty string
rather than 0), which forces partialpv filtering of analysis engine
mainpv visualisation to always get triggered, this patch fixes that.

I have also included the earlier patch which I had sent wrt
boardSeqNumColor and configs/options.dat with this email.


On Mon, Dec 9, 2024 at 4:14 PM C Hanish Menon <han...@gm...> wrote:
>
> Hi Steve,
>
> Also maybe you have forgotten to enable softtabs or equivalent in your
> editor. The last few commits have tabs instead of spaces, forgot to
> mention this early, so formatting may look odd, depending on the tab
> width.
>
> On Mon, Dec 9, 2024 at 4:08 PM C Hanish Menon <han...@gm...> wrote:
> >
> > Also hopefully remaining games should be more interesting now, given
> > where the match is at.
> >
> > On Mon, Dec 9, 2024 at 4:05 PM C Hanish Menon <han...@gm...> wrote:
> > >
> > > Hi Steve,
> > >
> > > I think you forgot to add the option to the foreach list of variables
> > > used when exiting to save to options.dat. Also maybe a typo with
> > > missing ")" wrt info exists?
> > > Again not that much familiar with tcl and scidvspc inner plumbing, but
> > > this seems to be needed, based on my limited checking here.
> > >
> > > Attaching a patch wrt same.
> > >
> > > On Mon, Dec 9, 2024 at 1:22 PM Steve A <ste...@gm...> wrote:
> > > >
> > > > Ok Hanish... I applied one patch, but not the color one.... Too many minor colour options around.
> > > > I made some other tweaks too. Now you can just set analysis(boardSeqNumColor) in an init file, or in the gui somewhere.
> > > >
> > > > Ding made a classic Ding blunder last night!
> > > >
> > > > cheers.
> > > >
> > > >
> > > > On Sun, Dec 8, 2024 at 7:20 PM C Hanish Menon <han...@gm...> wrote:
> > > >>
> > > >> Hi Steve,
> > > >>
> > > >> I feel these two patches will make the moves visualisation feature
> > > >> more legible and flexible to end users
> > > >>
> > > >> These include
> > > >>
> > > >> 1. make the move number font bold
> > > >>
> > > >> 2. make the move arrow longer specifically wrt boardVisualiseMoves
> > > >>
> > > >> 3. pick the move number font color from a new option, which the user
> > > >> can control, which inturn by default set to red
> > > >>    Picking it from GlobalTextColor forces user to globally change the
> > > >> text color everywhere, when many a times because of the chess set
> > > >> used, one may want to change the color only for the movenumber shown
> > > >> on the analysis board.
> > > >>
> > > >> NOTE: Something seems to have changed wrt avoiding partial PVs from
> > > >> the engine overriding previous depth full pv visualisation, I need to
> > > >> see why the latest subversion release/eviision has changed this
> > > >> behaviour later.
> > > >>
> > > >> On Sun, Dec 8, 2024 at 12:37 PM Steve A <ste...@gm...> wrote:
> > > >> >
> > > >> > Yeah, it wasn't too legible yesterday. I reverted the num colour to default text colour, and tweaked the arrow head. The blue is just what I have set as  options-colours-enginearrows. I'll have to document it all.
> > > >> >
> > > >> > Cheers
> > > >> >
> > > >> > On Sunday, December 8, 2024, C Hanish Menon <han...@gm...> wrote:
> > > >> >>
> > > >> >> Hi Steve
> > > >> >>
> > > >> >> Was modifying things from yesterday's release, to send patch to you. But will checkout the new revision from SVN before sending any patch.
> > > >> >>
> > > >> >> Also looking at the image, I can see a reason why there may be some differences in what we have been saying and inturn trying to achieve wrt visualisation themeing around this feature
> > > >> >>
> > > >> >> For me the default scidvcpc setup shows a more fancy chess set and also the lines are black with text also black on top & also shorter arrow lines, in your yesterday's commit. All of which makes the move visualisation theme (predefined line colour, line length) you had forced ;) in yesterday's revision non legible.
> > > >> >>
> > > >> >> I was about to submit a patch with blue longer lines and red text on top and also changing to bold font. Those changes were to make things more legible.
> > > >> >>
> > > >> >> However from your image it appears like now you have also changed the lines to blue & made it longer. So that should potentially resolve the confusion & conflict in our patches
> > > >> >>
> > > >> >> PS: yes agree the match is favouring Ding now, given that the cost of risk is lot more now. However it's Gukesh who is trying to add some spice into the mix. Given their positions wrt championship both their behaviours is understandable. Here in India, in general, we root for Gukesh, but equally love Ding :)
> > > >> >>
> > > >> >>
> > > >> >> On Sun, Dec 8, 2024, 08:48 Steve A <ste...@gm...> wrote:
> > > >> >>>
> > > >> >>> Ok, Hanish's feature is looking nice - nearly finialized - and is included in subversion now.
> > > >> >>> (I've modified it a bit, so not exactly how Hanish envisioned it, sorry mate).
> > > >> >>> Check out svn and after installation select "Show Board" and  "Sequential" in the tools->Analysis window.
> > > >> >>> Screenshot attached. Cheers, S.A.
> > > >> >>>
> > > >> >>>
> > > >> >>> On Sun, Dec 8, 2024 at 1:07 PM Steve A <ste...@gm...> wrote:
> > > >> >>>>
> > > >> >>>> Ok... I sorted out some issues today. Control+Wheelmouse will resize the board now (hopefully... the focus/flow for these bindings is hard to understand).
> > > >> >>>> You're welcome to update help.tcl if you like... I haven't got around to it yet.
> > > >> >>>>
> > > >> >>>> > 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
> > > >> >>>>
> > > >> >>>> Yeah... for sure. But i think it's better to keep them separate, rather than having to zero the spinbox.
> > > >> >>>>
> > > >> >>>> > Because otherwise users will have to click the middle mouse button
> > > >> >>>>
> > > >> >>>> I agree, it's not a great UI element/design, having to use the middle button.
> > > >> >>>> But the default is settable in Tools->analysis config widget
> > > >> >>>>
> > > >> >>>> > 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)
> > > >> >>>>
> > > >> >>>> Yes - very interesting championship isn't it ! :)
> > > >> >>>> I have to say I'm going for Ding though, after the huge struggles he's had the last couple of years. Gukesh certainly has the form this year, but *maybe* his youth will be to his detriment this time... ? I guess from your name you are Indian(?) and going for Gukesh :)
> > > >> >>>>
> > > >> >>>> regards, Steve
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> Keep ;-)
> > > >> HanishKVC
> > >
> > >
> > >
> > > --
> > > Keep ;-)
> > > HanishKVC
> >
> >
> >
> > --
> > Keep ;-)
> > HanishKVC
>
>
>
> --
> Keep ;-)
> HanishKVC



-- 
Keep ;-)
HanishKVC

Re: [Scidvspc-users] Patch ScidVsPC - Allow visualisation of Main PV on analysis board

[C H. M. <han...@gm...>]

Hi Steve,

Also maybe you have forgotten to enable softtabs or equivalent in your
editor. The last few commits have tabs instead of spaces, forgot to
mention this early, so formatting may look odd, depending on the tab
width.

On Mon, Dec 9, 2024 at 4:08 PM C Hanish Menon <han...@gm...> wrote:
>
> Also hopefully remaining games should be more interesting now, given
> where the match is at.
>
> On Mon, Dec 9, 2024 at 4:05 PM C Hanish Menon <han...@gm...> wrote:
> >
> > Hi Steve,
> >
> > I think you forgot to add the option to the foreach list of variables
> > used when exiting to save to options.dat. Also maybe a typo with
> > missing ")" wrt info exists?
> > Again not that much familiar with tcl and scidvspc inner plumbing, but
> > this seems to be needed, based on my limited checking here.
> >
> > Attaching a patch wrt same.
> >
> > On Mon, Dec 9, 2024 at 1:22 PM Steve A <ste...@gm...> wrote:
> > >
> > > Ok Hanish... I applied one patch, but not the color one.... Too many minor colour options around.
> > > I made some other tweaks too. Now you can just set analysis(boardSeqNumColor) in an init file, or in the gui somewhere.
> > >
> > > Ding made a classic Ding blunder last night!
> > >
> > > cheers.
> > >
> > >
> > > On Sun, Dec 8, 2024 at 7:20 PM C Hanish Menon <han...@gm...> wrote:
> > >>
> > >> Hi Steve,
> > >>
> > >> I feel these two patches will make the moves visualisation feature
> > >> more legible and flexible to end users
> > >>
> > >> These include
> > >>
> > >> 1. make the move number font bold
> > >>
> > >> 2. make the move arrow longer specifically wrt boardVisualiseMoves
> > >>
> > >> 3. pick the move number font color from a new option, which the user
> > >> can control, which inturn by default set to red
> > >>    Picking it from GlobalTextColor forces user to globally change the
> > >> text color everywhere, when many a times because of the chess set
> > >> used, one may want to change the color only for the movenumber shown
> > >> on the analysis board.
> > >>
> > >> NOTE: Something seems to have changed wrt avoiding partial PVs from
> > >> the engine overriding previous depth full pv visualisation, I need to
> > >> see why the latest subversion release/eviision has changed this
> > >> behaviour later.
> > >>
> > >> On Sun, Dec 8, 2024 at 12:37 PM Steve A <ste...@gm...> wrote:
> > >> >
> > >> > Yeah, it wasn't too legible yesterday. I reverted the num colour to default text colour, and tweaked the arrow head. The blue is just what I have set as  options-colours-enginearrows. I'll have to document it all.
> > >> >
> > >> > Cheers
> > >> >
> > >> > On Sunday, December 8, 2024, C Hanish Menon <han...@gm...> wrote:
> > >> >>
> > >> >> Hi Steve
> > >> >>
> > >> >> Was modifying things from yesterday's release, to send patch to you. But will checkout the new revision from SVN before sending any patch.
> > >> >>
> > >> >> Also looking at the image, I can see a reason why there may be some differences in what we have been saying and inturn trying to achieve wrt visualisation themeing around this feature
> > >> >>
> > >> >> For me the default scidvcpc setup shows a more fancy chess set and also the lines are black with text also black on top & also shorter arrow lines, in your yesterday's commit. All of which makes the move visualisation theme (predefined line colour, line length) you had forced ;) in yesterday's revision non legible.
> > >> >>
> > >> >> I was about to submit a patch with blue longer lines and red text on top and also changing to bold font. Those changes were to make things more legible.
> > >> >>
> > >> >> However from your image it appears like now you have also changed the lines to blue & made it longer. So that should potentially resolve the confusion & conflict in our patches
> > >> >>
> > >> >> PS: yes agree the match is favouring Ding now, given that the cost of risk is lot more now. However it's Gukesh who is trying to add some spice into the mix. Given their positions wrt championship both their behaviours is understandable. Here in India, in general, we root for Gukesh, but equally love Ding :)
> > >> >>
> > >> >>
> > >> >> On Sun, Dec 8, 2024, 08:48 Steve A <ste...@gm...> wrote:
> > >> >>>
> > >> >>> Ok, Hanish's feature is looking nice - nearly finialized - and is included in subversion now.
> > >> >>> (I've modified it a bit, so not exactly how Hanish envisioned it, sorry mate).
> > >> >>> Check out svn and after installation select "Show Board" and  "Sequential" in the tools->Analysis window.
> > >> >>> Screenshot attached. Cheers, S.A.
> > >> >>>
> > >> >>>
> > >> >>> On Sun, Dec 8, 2024 at 1:07 PM Steve A <ste...@gm...> wrote:
> > >> >>>>
> > >> >>>> Ok... I sorted out some issues today. Control+Wheelmouse will resize the board now (hopefully... the focus/flow for these bindings is hard to understand).
> > >> >>>> You're welcome to update help.tcl if you like... I haven't got around to it yet.
> > >> >>>>
> > >> >>>> > 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
> > >> >>>>
> > >> >>>> Yeah... for sure. But i think it's better to keep them separate, rather than having to zero the spinbox.
> > >> >>>>
> > >> >>>> > Because otherwise users will have to click the middle mouse button
> > >> >>>>
> > >> >>>> I agree, it's not a great UI element/design, having to use the middle button.
> > >> >>>> But the default is settable in Tools->analysis config widget
> > >> >>>>
> > >> >>>> > 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)
> > >> >>>>
> > >> >>>> Yes - very interesting championship isn't it ! :)
> > >> >>>> I have to say I'm going for Ding though, after the huge struggles he's had the last couple of years. Gukesh certainly has the form this year, but *maybe* his youth will be to his detriment this time... ? I guess from your name you are Indian(?) and going for Gukesh :)
> > >> >>>>
> > >> >>>> regards, Steve
> > >>
> > >>
> > >>
> > >> --
> > >> Keep ;-)
> > >> HanishKVC
> >
> >
> >
> > --
> > Keep ;-)
> > HanishKVC
>
>
>
> --
> Keep ;-)
> HanishKVC



-- 
Keep ;-)
HanishKVC

Re: [Scidvspc-users] Patch ScidVsPC - Allow visualisation of Main PV on analysis board

[C H. M. <han...@gm...>]

Also hopefully remaining games should be more interesting now, given
where the match is at.

On Mon, Dec 9, 2024 at 4:05 PM C Hanish Menon <han...@gm...> wrote:
>
> Hi Steve,
>
> I think you forgot to add the option to the foreach list of variables
> used when exiting to save to options.dat. Also maybe a typo with
> missing ")" wrt info exists?
> Again not that much familiar with tcl and scidvspc inner plumbing, but
> this seems to be needed, based on my limited checking here.
>
> Attaching a patch wrt same.
>
> On Mon, Dec 9, 2024 at 1:22 PM Steve A <ste...@gm...> wrote:
> >
> > Ok Hanish... I applied one patch, but not the color one.... Too many minor colour options around.
> > I made some other tweaks too. Now you can just set analysis(boardSeqNumColor) in an init file, or in the gui somewhere.
> >
> > Ding made a classic Ding blunder last night!
> >
> > cheers.
> >
> >
> > On Sun, Dec 8, 2024 at 7:20 PM C Hanish Menon <han...@gm...> wrote:
> >>
> >> Hi Steve,
> >>
> >> I feel these two patches will make the moves visualisation feature
> >> more legible and flexible to end users
> >>
> >> These include
> >>
> >> 1. make the move number font bold
> >>
> >> 2. make the move arrow longer specifically wrt boardVisualiseMoves
> >>
> >> 3. pick the move number font color from a new option, which the user
> >> can control, which inturn by default set to red
> >>    Picking it from GlobalTextColor forces user to globally change the
> >> text color everywhere, when many a times because of the chess set
> >> used, one may want to change the color only for the movenumber shown
> >> on the analysis board.
> >>
> >> NOTE: Something seems to have changed wrt avoiding partial PVs from
> >> the engine overriding previous depth full pv visualisation, I need to
> >> see why the latest subversion release/eviision has changed this
> >> behaviour later.
> >>
> >> On Sun, Dec 8, 2024 at 12:37 PM Steve A <ste...@gm...> wrote:
> >> >
> >> > Yeah, it wasn't too legible yesterday. I reverted the num colour to default text colour, and tweaked the arrow head. The blue is just what I have set as  options-colours-enginearrows. I'll have to document it all.
> >> >
> >> > Cheers
> >> >
> >> > On Sunday, December 8, 2024, C Hanish Menon <han...@gm...> wrote:
> >> >>
> >> >> Hi Steve
> >> >>
> >> >> Was modifying things from yesterday's release, to send patch to you. But will checkout the new revision from SVN before sending any patch.
> >> >>
> >> >> Also looking at the image, I can see a reason why there may be some differences in what we have been saying and inturn trying to achieve wrt visualisation themeing around this feature
> >> >>
> >> >> For me the default scidvcpc setup shows a more fancy chess set and also the lines are black with text also black on top & also shorter arrow lines, in your yesterday's commit. All of which makes the move visualisation theme (predefined line colour, line length) you had forced ;) in yesterday's revision non legible.
> >> >>
> >> >> I was about to submit a patch with blue longer lines and red text on top and also changing to bold font. Those changes were to make things more legible.
> >> >>
> >> >> However from your image it appears like now you have also changed the lines to blue & made it longer. So that should potentially resolve the confusion & conflict in our patches
> >> >>
> >> >> PS: yes agree the match is favouring Ding now, given that the cost of risk is lot more now. However it's Gukesh who is trying to add some spice into the mix. Given their positions wrt championship both their behaviours is understandable. Here in India, in general, we root for Gukesh, but equally love Ding :)
> >> >>
> >> >>
> >> >> On Sun, Dec 8, 2024, 08:48 Steve A <ste...@gm...> wrote:
> >> >>>
> >> >>> Ok, Hanish's feature is looking nice - nearly finialized - and is included in subversion now.
> >> >>> (I've modified it a bit, so not exactly how Hanish envisioned it, sorry mate).
> >> >>> Check out svn and after installation select "Show Board" and  "Sequential" in the tools->Analysis window.
> >> >>> Screenshot attached. Cheers, S.A.
> >> >>>
> >> >>>
> >> >>> On Sun, Dec 8, 2024 at 1:07 PM Steve A <ste...@gm...> wrote:
> >> >>>>
> >> >>>> Ok... I sorted out some issues today. Control+Wheelmouse will resize the board now (hopefully... the focus/flow for these bindings is hard to understand).
> >> >>>> You're welcome to update help.tcl if you like... I haven't got around to it yet.
> >> >>>>
> >> >>>> > 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
> >> >>>>
> >> >>>> Yeah... for sure. But i think it's better to keep them separate, rather than having to zero the spinbox.
> >> >>>>
> >> >>>> > Because otherwise users will have to click the middle mouse button
> >> >>>>
> >> >>>> I agree, it's not a great UI element/design, having to use the middle button.
> >> >>>> But the default is settable in Tools->analysis config widget
> >> >>>>
> >> >>>> > 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)
> >> >>>>
> >> >>>> Yes - very interesting championship isn't it ! :)
> >> >>>> I have to say I'm going for Ding though, after the huge struggles he's had the last couple of years. Gukesh certainly has the form this year, but *maybe* his youth will be to his detriment this time... ? I guess from your name you are Indian(?) and going for Gukesh :)
> >> >>>>
> >> >>>> regards, Steve
> >>
> >>
> >>
> >> --
> >> Keep ;-)
> >> HanishKVC
>
>
>
> --
> Keep ;-)
> HanishKVC



-- 
Keep ;-)
HanishKVC

Re: [Scidvspc-users] Patch ScidVsPC - Allow visualisation of Main PV on analysis board

[C H. M. <han...@gm...>]

Hi Steve,

I think you forgot to add the option to the foreach list of variables
used when exiting to save to options.dat. Also maybe a typo with
missing ")" wrt info exists?
Again not that much familiar with tcl and scidvspc inner plumbing, but
this seems to be needed, based on my limited checking here.

Attaching a patch wrt same.

On Mon, Dec 9, 2024 at 1:22 PM Steve A <ste...@gm...> wrote:
>
> Ok Hanish... I applied one patch, but not the color one.... Too many minor colour options around.
> I made some other tweaks too. Now you can just set analysis(boardSeqNumColor) in an init file, or in the gui somewhere.
>
> Ding made a classic Ding blunder last night!
>
> cheers.
>
>
> On Sun, Dec 8, 2024 at 7:20 PM C Hanish Menon <han...@gm...> wrote:
>>
>> Hi Steve,
>>
>> I feel these two patches will make the moves visualisation feature
>> more legible and flexible to end users
>>
>> These include
>>
>> 1. make the move number font bold
>>
>> 2. make the move arrow longer specifically wrt boardVisualiseMoves
>>
>> 3. pick the move number font color from a new option, which the user
>> can control, which inturn by default set to red
>>    Picking it from GlobalTextColor forces user to globally change the
>> text color everywhere, when many a times because of the chess set
>> used, one may want to change the color only for the movenumber shown
>> on the analysis board.
>>
>> NOTE: Something seems to have changed wrt avoiding partial PVs from
>> the engine overriding previous depth full pv visualisation, I need to
>> see why the latest subversion release/eviision has changed this
>> behaviour later.
>>
>> On Sun, Dec 8, 2024 at 12:37 PM Steve A <ste...@gm...> wrote:
>> >
>> > Yeah, it wasn't too legible yesterday. I reverted the num colour to default text colour, and tweaked the arrow head. The blue is just what I have set as  options-colours-enginearrows. I'll have to document it all.
>> >
>> > Cheers
>> >
>> > On Sunday, December 8, 2024, C Hanish Menon <han...@gm...> wrote:
>> >>
>> >> Hi Steve
>> >>
>> >> Was modifying things from yesterday's release, to send patch to you. But will checkout the new revision from SVN before sending any patch.
>> >>
>> >> Also looking at the image, I can see a reason why there may be some differences in what we have been saying and inturn trying to achieve wrt visualisation themeing around this feature
>> >>
>> >> For me the default scidvcpc setup shows a more fancy chess set and also the lines are black with text also black on top & also shorter arrow lines, in your yesterday's commit. All of which makes the move visualisation theme (predefined line colour, line length) you had forced ;) in yesterday's revision non legible.
>> >>
>> >> I was about to submit a patch with blue longer lines and red text on top and also changing to bold font. Those changes were to make things more legible.
>> >>
>> >> However from your image it appears like now you have also changed the lines to blue & made it longer. So that should potentially resolve the confusion & conflict in our patches
>> >>
>> >> PS: yes agree the match is favouring Ding now, given that the cost of risk is lot more now. However it's Gukesh who is trying to add some spice into the mix. Given their positions wrt championship both their behaviours is understandable. Here in India, in general, we root for Gukesh, but equally love Ding :)
>> >>
>> >>
>> >> On Sun, Dec 8, 2024, 08:48 Steve A <ste...@gm...> wrote:
>> >>>
>> >>> Ok, Hanish's feature is looking nice - nearly finialized - and is included in subversion now.
>> >>> (I've modified it a bit, so not exactly how Hanish envisioned it, sorry mate).
>> >>> Check out svn and after installation select "Show Board" and  "Sequential" in the tools->Analysis window.
>> >>> Screenshot attached. Cheers, S.A.
>> >>>
>> >>>
>> >>> On Sun, Dec 8, 2024 at 1:07 PM Steve A <ste...@gm...> wrote:
>> >>>>
>> >>>> Ok... I sorted out some issues today. Control+Wheelmouse will resize the board now (hopefully... the focus/flow for these bindings is hard to understand).
>> >>>> You're welcome to update help.tcl if you like... I haven't got around to it yet.
>> >>>>
>> >>>> > 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
>> >>>>
>> >>>> Yeah... for sure. But i think it's better to keep them separate, rather than having to zero the spinbox.
>> >>>>
>> >>>> > Because otherwise users will have to click the middle mouse button
>> >>>>
>> >>>> I agree, it's not a great UI element/design, having to use the middle button.
>> >>>> But the default is settable in Tools->analysis config widget
>> >>>>
>> >>>> > 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)
>> >>>>
>> >>>> Yes - very interesting championship isn't it ! :)
>> >>>> I have to say I'm going for Ding though, after the huge struggles he's had the last couple of years. Gukesh certainly has the form this year, but *maybe* his youth will be to his detriment this time... ? I guess from your name you are Indian(?) and going for Gukesh :)
>> >>>>
>> >>>> regards, Steve
>>
>>
>>
>> --
>> Keep ;-)
>> HanishKVC



-- 
Keep ;-)
HanishKVC

Re: [Scidvspc-users] Patch ScidVsPC - Allow visualisation of Main PV on analysis board

[C H. M. <han...@gm...>]

Hi Steve,

I feel these two patches will make the moves visualisation feature
more legible and flexible to end users

These include

1. make the move number font bold

2. make the move arrow longer specifically wrt boardVisualiseMoves

3. pick the move number font color from a new option, which the user
can control, which inturn by default set to red
   Picking it from GlobalTextColor forces user to globally change the
text color everywhere, when many a times because of the chess set
used, one may want to change the color only for the movenumber shown
on the analysis board.

NOTE: Something seems to have changed wrt avoiding partial PVs from
the engine overriding previous depth full pv visualisation, I need to
see why the latest subversion release/eviision has changed this
behaviour later.

On Sun, Dec 8, 2024 at 12:37 PM Steve A <ste...@gm...> wrote:
>
> Yeah, it wasn't too legible yesterday. I reverted the num colour to default text colour, and tweaked the arrow head. The blue is just what I have set as  options-colours-enginearrows. I'll have to document it all.
>
> Cheers
>
> On Sunday, December 8, 2024, C Hanish Menon <han...@gm...> wrote:
>>
>> Hi Steve
>>
>> Was modifying things from yesterday's release, to send patch to you. But will checkout the new revision from SVN before sending any patch.
>>
>> Also looking at the image, I can see a reason why there may be some differences in what we have been saying and inturn trying to achieve wrt visualisation themeing around this feature
>>
>> For me the default scidvcpc setup shows a more fancy chess set and also the lines are black with text also black on top & also shorter arrow lines, in your yesterday's commit. All of which makes the move visualisation theme (predefined line colour, line length) you had forced ;) in yesterday's revision non legible.
>>
>> I was about to submit a patch with blue longer lines and red text on top and also changing to bold font. Those changes were to make things more legible.
>>
>> However from your image it appears like now you have also changed the lines to blue & made it longer. So that should potentially resolve the confusion & conflict in our patches
>>
>> PS: yes agree the match is favouring Ding now, given that the cost of risk is lot more now. However it's Gukesh who is trying to add some spice into the mix. Given their positions wrt championship both their behaviours is understandable. Here in India, in general, we root for Gukesh, but equally love Ding :)
>>
>>
>> On Sun, Dec 8, 2024, 08:48 Steve A <ste...@gm...> wrote:
>>>
>>> Ok, Hanish's feature is looking nice - nearly finialized - and is included in subversion now.
>>> (I've modified it a bit, so not exactly how Hanish envisioned it, sorry mate).
>>> Check out svn and after installation select "Show Board" and  "Sequential" in the tools->Analysis window.
>>> Screenshot attached. Cheers, S.A.
>>>
>>>
>>> On Sun, Dec 8, 2024 at 1:07 PM Steve A <ste...@gm...> wrote:
>>>>
>>>> Ok... I sorted out some issues today. Control+Wheelmouse will resize the board now (hopefully... the focus/flow for these bindings is hard to understand).
>>>> You're welcome to update help.tcl if you like... I haven't got around to it yet.
>>>>
>>>> > 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
>>>>
>>>> Yeah... for sure. But i think it's better to keep them separate, rather than having to zero the spinbox.
>>>>
>>>> > Because otherwise users will have to click the middle mouse button
>>>>
>>>> I agree, it's not a great UI element/design, having to use the middle button.
>>>> But the default is settable in Tools->analysis config widget
>>>>
>>>> > 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)
>>>>
>>>> Yes - very interesting championship isn't it ! :)
>>>> I have to say I'm going for Ding though, after the huge struggles he's had the last couple of years. Gukesh certainly has the form this year, but *maybe* his youth will be to his detriment this time... ? I guess from your name you are Indian(?) and going for Gukesh :)
>>>>
>>>> regards, Steve



-- 
Keep ;-)
HanishKVC

Re: [Scidvspc-users] Patch ScidVsPC - Allow visualisation of Main PV on analysis board

[C H. M. <han...@gm...>]

Hi Steve

Was modifying things from yesterday's release, to send patch to you. But
will checkout the new revision from SVN before sending any patch.

Also looking at the image, I can see a reason why there may be some
differences in what we have been saying and inturn trying to achieve wrt
visualisation themeing around this feature

For me the default scidvcpc setup shows a more fancy chess set and also the
lines are black with text also black on top & also shorter arrow lines, in
your yesterday's commit. All of which makes the move visualisation theme
(predefined line colour, line length) you had forced ;) in yesterday's
revision non legible.

I was about to submit a patch with blue longer lines and red text on top
and also changing to bold font. Those changes were to make things more
legible.

However from your image it appears like now you have also changed the lines
to blue & made it longer. So that should potentially resolve the confusion
& conflict in our patches

PS: yes agree the match is favouring Ding now, given that the cost of risk
is lot more now. However it's Gukesh who is trying to add some spice into
the mix. Given their positions wrt championship both their behaviours is
understandable. Here in India, in general, we root for Gukesh, but equally
love Ding :)

On Sun, Dec 8, 2024, 08:48 Steve A <ste...@gm...> wrote:

> Ok, Hanish's feature is looking nice - nearly finialized - and is included
> in subversion now.
> (I've modified it a bit, so not exactly how Hanish envisioned it, sorry
> mate).
> Check out svn and after installation select "Show Board" and  "Sequential"
> in the tools->Analysis window.
> Screenshot attached. Cheers, S.A.
>
>
> On Sun, Dec 8, 2024 at 1:07 PM Steve A <ste...@gm...> wrote:
>
>> Ok... I sorted out some issues today. Control+Wheelmouse will resize the
>> board now (hopefully... the focus/flow for these bindings is hard to
>> understand).
>> You're welcome to update help.tcl if you like... I haven't got around to
>> it yet.
>>
>> > 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
>>
>> Yeah... for sure. But i think it's better to keep them separate, rather
>> than having to zero the spinbox.
>>
>> > Because otherwise users will have to click the middle mouse button
>>
>> I agree, it's not a great UI element/design, having to use the middle
>> button.
>> But the default is settable in Tools->analysis config widget
>>
>> > 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)
>>
>> Yes - very interesting championship isn't it ! :)
>> I have to say I'm going for Ding though, after the huge struggles he's
>> had the last couple of years. Gukesh certainly has the form this year, but
>> *maybe* his youth will be to his detriment this time... ? I guess from your
>> name you are Indian(?) and going for Gukesh :)
>>
>> regards, Steve
>>
>

Re: [Scidvspc-users] Patch ScidVsPC - Allow visualisation of Main PV on analysis board

[Steve A <ste...@gm...>]

Ok, Hanish's feature is looking nice - nearly finialized - and is included
in subversion now.
(I've modified it a bit, so not exactly how Hanish envisioned it, sorry
mate).
Check out svn and after installation select "Show Board" and  "Sequential"
in the tools->Analysis window.
Screenshot attached. Cheers, S.A.


On Sun, Dec 8, 2024 at 1:07 PM Steve A <ste...@gm...> wrote:

> Ok... I sorted out some issues today. Control+Wheelmouse will resize the
> board now (hopefully... the focus/flow for these bindings is hard to
> understand).
> You're welcome to update help.tcl if you like... I haven't got around to
> it yet.
>
> > 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
>
> Yeah... for sure. But i think it's better to keep them separate, rather
> than having to zero the spinbox.
>
> > Because otherwise users will have to click the middle mouse button
>
> I agree, it's not a great UI element/design, having to use the middle
> button.
> But the default is settable in Tools->analysis config widget
>
> > 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)
>
> Yes - very interesting championship isn't it ! :)
> I have to say I'm going for Ding though, after the huge struggles he's had
> the last couple of years. Gukesh certainly has the form this year, but
> *maybe* his youth will be to his detriment this time... ? I guess from your
> name you are Indian(?) and going for Gukesh :)
>
> regards, Steve
>

Re: [Scidvspc-users] г.Cанкт-Петербург

[Щебенюк М.П. <shc...@in...>]

Thank!
 
 
С уважением,
Михаил Щебенюк
shc...@in...

Re: [Scidvspc-users] Patch ScidVsPC - Allow visualisation of Main PV on analysis board

[C H. M. <han...@gm...>]

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 <ste...@gm...> 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 <han...@gm...> 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 <han...@gm...> 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 <han...@gm...> 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 <ste...@gm...> wrote:
>> > > >
>> > > > If you edit individual files, and send the "svn diff", would be better. Cheers
>> > > >
>> > > > On Friday, December 6, 2024, Steve A <ste...@gm...> 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 <han...@gm...> 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 <han...@gm...> 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 <ste...@gm...> 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 <han...@gm...> 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 <han...@gm...> 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 <han...@gm...> 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 <ste...@gm...> 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 <ste...@gm...> 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 <ste...@gm...> wrote:
>> > > >>> > >> > > >>>
>> > > >>> > >> > > >>> ok... I'm onto it now. I see your not using drawArrow
>> > > >>> > >> > > >>>
>> > > >>> > >> > > >>> On Thu, Dec 5, 2024 at 11:01 AM Steve A <ste...@gm...> wrote:
>> > > >>> > >> > > >>>>
>> > > >>> > >> > > >>>> Otherwise, I'll do it sometime. Cheers
>> > > >>> > >> > > >>>>
>> > > >>> > >> > > >>>> On Thursday, December 5, 2024, C Hanish Menon <han...@gm...> 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 <ste...@gm...> 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 <ste...@gm...> 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 <han...@gm...> 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 <ste...@gm...> 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 <han...@gm...> 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 <han...@gm...> 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 <ste...@gm...> 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 <han...@gm...> 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
>> > > >>> > >> > > >>>>> >>> >> > >> Sci...@li...
>> > > >>> > >> > > >>>>> >>> >> > >> 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

Re: [Scidvspc-users] Patch ScidVsPC - Allow visualisation of Main PV on analysis board

[C H. M. <han...@gm...>]

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 <han...@gm...> 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 <han...@gm...> 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 <ste...@gm...> wrote:
> > >
> > > If you edit individual files, and send the "svn diff", would be better. Cheers
> > >
> > > On Friday, December 6, 2024, Steve A <ste...@gm...> 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 <han...@gm...> 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 <han...@gm...> 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 <ste...@gm...> 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 <han...@gm...> 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 <han...@gm...> 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 <han...@gm...> 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 <ste...@gm...> 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 <ste...@gm...> 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 <ste...@gm...> wrote:
> > >>> > >> > > >>>
> > >>> > >> > > >>> ok... I'm onto it now. I see your not using drawArrow
> > >>> > >> > > >>>
> > >>> > >> > > >>> On Thu, Dec 5, 2024 at 11:01 AM Steve A <ste...@gm...> wrote:
> > >>> > >> > > >>>>
> > >>> > >> > > >>>> Otherwise, I'll do it sometime. Cheers
> > >>> > >> > > >>>>
> > >>> > >> > > >>>> On Thursday, December 5, 2024, C Hanish Menon <han...@gm...> 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 <ste...@gm...> 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 <ste...@gm...> 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 <han...@gm...> 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 <ste...@gm...> 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 <han...@gm...> 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 <han...@gm...> 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 <ste...@gm...> 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 <han...@gm...> 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
> > >>> > >> > > >>>>> >>> >> > >> Sci...@li...
> > >>> > >> > > >>>>> >>> >> > >> 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

Re: [Scidvspc-users] Patch ScidVsPC - Allow visualisation of Main PV on analysis board

[C H. M. <han...@gm...>]

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 <han...@gm...> 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 <ste...@gm...> wrote:
> >
> > If you edit individual files, and send the "svn diff", would be better. Cheers
> >
> > On Friday, December 6, 2024, Steve A <ste...@gm...> 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 <han...@gm...> 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 <han...@gm...> 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 <ste...@gm...> 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 <han...@gm...> 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 <han...@gm...> 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 <han...@gm...> 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 <ste...@gm...> 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 <ste...@gm...> 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 <ste...@gm...> wrote:
> >>> > >> > > >>>
> >>> > >> > > >>> ok... I'm onto it now. I see your not using drawArrow
> >>> > >> > > >>>
> >>> > >> > > >>> On Thu, Dec 5, 2024 at 11:01 AM Steve A <ste...@gm...> wrote:
> >>> > >> > > >>>>
> >>> > >> > > >>>> Otherwise, I'll do it sometime. Cheers
> >>> > >> > > >>>>
> >>> > >> > > >>>> On Thursday, December 5, 2024, C Hanish Menon <han...@gm...> 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 <ste...@gm...> 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 <ste...@gm...> 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 <han...@gm...> 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 <ste...@gm...> 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 <han...@gm...> 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 <han...@gm...> 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 <ste...@gm...> 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 <han...@gm...> 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
> >>> > >> > > >>>>> >>> >> > >> Sci...@li...
> >>> > >> > > >>>>> >>> >> > >> 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

Re: [Scidvspc-users] Patch ScidVsPC - Allow visualisation of Main PV on analysis board

[C H. M. <han...@gm...>]

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 <ste...@gm...> wrote:
>
> If you edit individual files, and send the "svn diff", would be better. Cheers
>
> On Friday, December 6, 2024, Steve A <ste...@gm...> 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 <han...@gm...> 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 <han...@gm...> 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 <ste...@gm...> 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 <han...@gm...> 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 <han...@gm...> 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 <han...@gm...> 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 <ste...@gm...> 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 <ste...@gm...> 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 <ste...@gm...> wrote:
>>> > >> > > >>>
>>> > >> > > >>> ok... I'm onto it now. I see your not using drawArrow
>>> > >> > > >>>
>>> > >> > > >>> On Thu, Dec 5, 2024 at 11:01 AM Steve A <ste...@gm...> wrote:
>>> > >> > > >>>>
>>> > >> > > >>>> Otherwise, I'll do it sometime. Cheers
>>> > >> > > >>>>
>>> > >> > > >>>> On Thursday, December 5, 2024, C Hanish Menon <han...@gm...> 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 <ste...@gm...> 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 <ste...@gm...> 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 <han...@gm...> 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 <ste...@gm...> 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 <han...@gm...> 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 <han...@gm...> 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 <ste...@gm...> 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 <han...@gm...> 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
>>> > >> > > >>>>> >>> >> > >> Sci...@li...
>>> > >> > > >>>>> >>> >> > >> 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