Hi Steve,
NOTE: Needs to be applied on top of the svn diff (ie your adaptation
of my original patch wrt moves visualisation) which you had sent to
me.
Attached is the svn diff which includes the logics from my original
patch (for reasons mentioned before) as well as some minor refinements
1. shadow color wrt text to try ensure better visibility irrespective
of light or dark square/piece
2. use custom tag specific to this logic, so that the move
visualisation is not lost, even if the analysis engine move
visualisation logic decides to skip during a board gui refresh. This
can occur if there isn't enough move data as the engine is still in
the middle of creating the next depth move list. Additionally now in
such a situation the logic triggers a raise request to the board, so
that any chess piece doesnt hide the move numbers.
3. go back to move numbers being displayed at the center of the
landing/end square, along with prepending of move numbers if multiple
moves land on the same square. Additionally during the situation of
multiple moves having the same landing square, all moves other than
the 1st one in such a situation will have the move number shown
towards the center of the move related arrow line. Instead of showing
the move number at the center of the arrow, now the logic uses a
random number to try and random move the text between 0.3 to 0.7 part
of the line, to reduce chances of overlapping across different lines.
Also because this is plotted only for the special case of multiple
moves having the same landing square, the chances of move number on
arrows overlapping should be even more remote.
4. separate patch which I had sent earlier wrt forcing the
visualisation of moves to update, if a deeper pv leads to a shorter
main pv move line/list is included in this patch.
On Fri, Dec 6, 2024 at 4:23 PM C Hanish Menon <hanish...@gmail.com> wrote:
>
> Hi Steve,
>
> After looking at git-svn related info online, I have used svnsync to
> duplicate the remote repo locally. Not sure of how the syncing will
> work in future, when I have made local changes in this local repo,
> either way that is for another day.
>
> On Fri, Dec 6, 2024 at 2:18 PM C Hanish Menon <hanish...@gmail.com> wrote:
> >
> > Hi Steve,
> >
> > I havent used svn much in life, use git mostly when required. Last
> > time was like 2 decades back or so.
> >
> > I tried using svnadmin create to create a local repository
> >
> > and in turn use svn import to import upstream scidvspc into that local
> > repository, but it fails with
> >
> > "svn: E175013: Access to '/p/scidvspc/code/!svn/me' forbidden"
> >
> > The command I used, along with some options which I used without rtfm was
> >
> > svn import --force --no-auth-cache code
> > http://svn.code.sf.net/p/scidvspc/code -m "Create a local repo of
> > scidvspc upstream"
> >
> > The idea being to create a local repository decoupled from the
> > upstream, so that I can do my own experiments if required without
> > needing any permissions in the upstream repository, while at the same
> > time, if possible have a structured and ready way of importing/syncing
> > with upstream, if required even in future without losing any local
> > experiments, like with git clone/pull. But given that the above fails,
> > not able to work with svn. Do you have any pointers for how to go
> > abhout.
> >
> > On Fri, Dec 6, 2024 at 2:42 AM Steve A <stevena...@gmail.com> wrote:
> > >
> > > If you edit individual files, and send the "svn diff", would be better.
> > > Cheers
> > >
> > > On Friday, December 6, 2024, Steve A <stevena...@gmail.com> wrote:
> > >>
> > >> > makes the text and arrow disappear, when
> > >> working with a single pv from analysis engine, bcas many a times when
> > >> the engine is generating the next depth pv, it will generate in
> > >> between move lines which are very short and so useless, so also I dont
> > >> call boardVisualiseMoves in these cases,
> > >>
> > >> Ok, thanks for explaining this. I was a bit heavy handed here... I'm
> > >> busy through the week... and will look at it properly on the weekend.
> > >>
> > >> Regards.
> > >>
> > >> On Friday, December 6, 2024, C Hanish Menon <hanish...@gmail.com> wrote:
> > >>>
> > >>> Hi Steve,
> > >>>
> > >>> I notice that you have reverted/changed certain aspects of my original
> > >>> patch. I have put the reasoning for my original flow below, and the
> > >>> issues of reverting/changing them
> > >>>
> > >>> 1) I am attaching an image of what I meant earlier wrt issue with
> > >>> placing move number in the middle of the line, and this is a simple
> > >>> case. There can be more complex cases where the center point will not
> > >>> match 0,0 wrt diff in center points, but still will have the text
> > >>> overlapping, so one will have to account for used font's max
> > >>> top-bottom and left-right boundaries wrt chars, leading to more
> > >>> complex mechanism to try and avoid these. While placing the number on
> > >>> the landing square center will make avoiding this overlapping simple
> > >>> and straightforward.
> > >>>
> > >>> 2) Using global(ie used in other places also) var tag, instead of tags
> > >>> local to boardVisualiseMoves, makes the text and arrow disappear, when
> > >>> working with a single pv from analysis engine, bcas many a times when
> > >>> the engine is generating the next depth pv, it will generate in
> > >>> between move lines which are very short and so useless, so also I dont
> > >>> call boardVisualiseMoves in these cases, so that the board can show
> > >>> the previous depth full move line's initial part, while the engine is
> > >>> building up the next depth move line. In these cases, with this
> > >>> modified flow, the text and arrow will disappear.
> > >>>
> > >>> 3) Using only black instead of a text color with contrasting shadow
> > >>> color, makes the move number non discernable in many cases.
> > >>>
> > >>> By any chance, did you want me to send you the patch (mapped to the
> > >>> individual tcl dir files, instead of my original applied to scid final
> > >>> script) after updating them to include my original logics?
> > >>>
> > >>> Also I had a look at the change you have done to the
> > >>> Tools->AnalysisEngine dialog, they definitely are better and make
> > >>> things clearer compared to previous flow. And for the case which I had
> > >>> mentioned in my last email, I can always potentially add a
> > >>> arrow+sequential entry to that drop down list, and use seperate if
> > >>> conditions rather than the if-else flow in your patch
> > >>>
> > >>>
> > >>> On Thu, Dec 5, 2024 at 6:22 PM C Hanish Menon <hanish...@gmail.com>
> > >>> wrote:
> > >>> >
> > >>> > Hi Steve,
> > >>> >
> > >>> > One among a few other reasons also, to directly use create line /
> > >>> > arrow in boardVisualiseMove was to keep the line thin and also non
> > >>> > interactive, so that it can overlap with the existing 1st move arrows.
> > >>> > But no issues, I will have a look at the program with your updated
> > >>> > diff.
> > >>> >
> > >>> > And given that it is open source, I can always change, in case, if I
> > >>> > want a different flow ;)
> > >>> >
> > >>> > On Thu, Dec 5, 2024 at 5:19 PM Steve A <stevena...@gmail.com> wrote:
> > >>> > >
> > >>> > > Yeah, *sorry* Hanish but I have made quite some changes to your
> > >>> > > code. I find having both sets of arrows at the same time redundant
> > >>> > > and distracting. And my version is much more attractive imho.
> > >>> > >
> > >>> > > If you look at the tools->analysis widget, you'll see what I've
> > >>> > > done. Middle clicking the board will toggle views (I hope).
> > >>> > >
> > >>> > > Regards, S.
> > >>> > >
> > >>> > > On Thursday, December 5, 2024, C Hanish Menon <hanish...@gmail.com>
> > >>> > > wrote:
> > >>> > >>
> > >>> > >> Hi Steve,
> > >>> > >>
> > >>> > >> Have a query. Looking at the diff which you sent (initial glance of
> > >>> > >> the code), it appears like you have changed the overall flow so
> > >>> > >> that
> > >>> > >> the analysis board either
> > >>> > >>
> > >>> > >> a) shows the 1st move of each move line in multipv (the existing
> > >>> > >> flow/feature in scidvspc) or
> > >>> > >> b) the visualisation of initial few moves from the main pv from
> > >>> > >> among
> > >>> > >> the multipv (the additional flow/feature which I had added).
> > >>> > >>
> > >>> > >> and not both at the same time.
> > >>> > >>
> > >>> > >> But dont you think from a user perspective, being able to see both
> > >>> > >> parallely on the analysis board is a better flow, like what I had
> > >>> > >> set
> > >>> > >> up originally. Because both give different yet useful info, that
> > >>> > >> one
> > >>> > >> will be interested in knowing when analysing a game at the same
> > >>> > >> time.
> > >>> > >> Additionally it also has the advantage of keeping the changes to
> > >>> > >> the
> > >>> > >> existing flow very minimal.
> > >>> > >>
> > >>> > >> I feel ideally we shouldnt limit the user to select between both,
> > >>> > >> bcas
> > >>> > >> both can be used/viewed parallely, without affecting one another,
> > >>> > >> and
> > >>> > >> provide different useful info to the user. So rather I am not
> > >>> > >> modifying the diff you sent, instead I am attaching the additional
> > >>> > >> patch to force mainpv analysis board visualisation update, if a
> > >>> > >> deeper
> > >>> > >> probe leads to a shorter move line, wrt the original patch which I
> > >>> > >> had
> > >>> > >> sent.
> > >>> > >>
> > >>> > >> On Thu, Dec 5, 2024 at 3:40 PM C Hanish Menon
> > >>> > >> <hanish...@gmail.com> wrote:
> > >>> > >> >
> > >>> > >> > Also, the reason why I didnt use the mid of the arrow to place
> > >>> > >> > the
> > >>> > >> > move number is because, if there are too many crossing moves,
> > >>> > >> > then the
> > >>> > >> > text may overlap, and trying to avoid that overlap will be bit
> > >>> > >> > more
> > >>> > >> > complicated, than if we are working with landing square center
> > >>> > >> > kind of
> > >>> > >> > flow.
> > >>> > >> >
> > >>> > >> > On Thu, Dec 5, 2024 at 3:37 PM C Hanish Menon
> > >>> > >> > <hanish...@gmail.com> wrote:
> > >>> > >> > >
> > >>> > >> > > Hi Steve,
> > >>> > >> > >
> > >>> > >> > > To avoid updating partial moves from the next depth, I have a
> > >>> > >> > > check,
> > >>> > >> > > that is what stops updating the board on mate or draw kind of
> > >>> > >> > > situations, when the move length returned at a higher depth
> > >>> > >> > > may be
> > >>> > >> > > shorter, I have modified the logic with a seen depth tracking
> > >>> > >> > > to
> > >>> > >> > > ensure that if two subsequent depths return a shorter move
> > >>> > >> > > line, then
> > >>> > >> > > it will update the visualisation with the shorter move line.
> > >>> > >> > >
> > >>> > >> > > Will send you the patch in some time.
> > >>> > >> > >
> > >>> > >> > > On Thu, Dec 5, 2024 at 2:27 PM Steve A <stevena...@gmail.com>
> > >>> > >> > > wrote:
> > >>> > >> > > >
> > >>> > >> > > > Sorry to spam you.... but there might be a bug in your code
> > >>> > >> > > > when we reach mate too,
> > >>> > >> > > > (where i had introduced a bug, fixed in this version).
> > >>> > >> > > > Thats it for another day , Cheers, S.A.
> > >>> > >> > > >
> > >>> > >> > > >
> > >>> > >> > > > On Thu, Dec 5, 2024 at 5:06 PM Steve A
> > >>> > >> > > > <stevena...@gmail.com> wrote:
> > >>> > >> > > >>
> > >>> > >> > > >> Hi Hanish
> > >>> > >> > > >> Ok, We should be able to include this feature :)
> > >>> > >> > > >> Attached is my alpha version... could you please update to
> > >>> > >> > > >> subversion, then apply this patch?
> > >>> > >> > > >>
> > >>> > >> > > >> The only thing i don't really like at the moment is having
> > >>> > >> > > >> the extra spinbox in the engine toolbar...
> > >>> > >> > > >> Might change this down the road.
> > >>> > >> > > >> Thanks, Steven
> > >>> > >> > > >>
> > >>> > >> > > >> On Thu, Dec 5, 2024 at 3:05 PM Steve A
> > >>> > >> > > >> <stevena...@gmail.com> wrote:
> > >>> > >> > > >>>
> > >>> > >> > > >>> ok... I'm onto it now. I see your not using drawArrow
> > >>> > >> > > >>>
> > >>> > >> > > >>> On Thu, Dec 5, 2024 at 11:01 AM Steve A
> > >>> > >> > > >>> <stevena...@gmail.com> wrote:
> > >>> > >> > > >>>>
> > >>> > >> > > >>>> Otherwise, I'll do it sometime. Cheers
> > >>> > >> > > >>>>
> > >>> > >> > > >>>> On Thursday, December 5, 2024, C Hanish Menon
> > >>> > >> > > >>>> <hanish...@gmail.com> wrote:
> > >>> > >> > > >>>>>
> > >>> > >> > > >>>>> Hi Steve,
> > >>> > >> > > >>>>>
> > >>> > >> > > >>>>> Thanks for the feedback and thoughts.
> > >>> > >> > > >>>>>
> > >>> > >> > > >>>>> Attaching the updated patch where
> > >>> > >> > > >>>>>
> > >>> > >> > > >>>>> 1. moved the visualisation of moves into a generic
> > >>> > >> > > >>>>> function of its
> > >>> > >> > > >>>>> own, which inturn is called from updateAnalysisBoard
> > >>> > >> > > >>>>> function to show
> > >>> > >> > > >>>>> the analysis engine's main pv's initial moves
> > >>> > >> > > >>>>>
> > >>> > >> > > >>>>> 1.1. using the board argument passed to this, one can
> > >>> > >> > > >>>>> make the move
> > >>> > >> > > >>>>> visualisation to appear on the main board or any other
> > >>> > >> > > >>>>> board, if one
> > >>> > >> > > >>>>> wants to. The n argument will also need to be unique for
> > >>> > >> > > >>>>> each of a
> > >>> > >> > > >>>>> different board.
> > >>> > >> > > >>>>>
> > >>> > >> > > >>>>> 1.2. if in any other place one wants to visualise a
> > >>> > >> > > >>>>> sequence of moves,
> > >>> > >> > > >>>>> the function can be called to achieve the same and
> > >>> > >> > > >>>>> inturn on whichever
> > >>> > >> > > >>>>> board that one may want to in that context.
> > >>> > >> > > >>>>>
> > >>> > >> > > >>>>> 2. the move number text shown on the board's squares
> > >>> > >> > > >>>>> uses contrasting
> > >>> > >> > > >>>>> shadow color to try and ensure that irrespective of
> > >>> > >> > > >>>>> light or dark
> > >>> > >> > > >>>>> square and or pieces, the numbers can be potentially
> > >>> > >> > > >>>>> visible to an
> > >>> > >> > > >>>>> extent.
> > >>> > >> > > >>>>>
> > >>> > >> > > >>>>> 3. If multiple moves in the move list land on the same
> > >>> > >> > > >>>>> square, the
> > >>> > >> > > >>>>> move numbers are prepended and shown on the square.
> > >>> > >> > > >>>>>
> > >>> > >> > > >>>>> 4. bcas text creation is now handled within the move
> > >>> > >> > > >>>>> visualisation
> > >>> > >> > > >>>>> function using its own tags, the text will be retained
> > >>> > >> > > >>>>> on the board to
> > >>> > >> > > >>>>> a great extent, even when some other logic may update
> > >>> > >> > > >>>>> the board, if
> > >>> > >> > > >>>>> required.
> > >>> > >> > > >>>>>
> > >>> > >> > > >>>>> This functionality can indirectly allow users to
> > >>> > >> > > >>>>> visualise to an
> > >>> > >> > > >>>>> extent where the pieces will be after a few moves
> > >>> > >> > > >>>>> (currently spinbox
> > >>> > >> > > >>>>> limited to 8 moves), to an extent, while also seeing how
> > >>> > >> > > >>>>> the pieces
> > >>> > >> > > >>>>> reached there.
> > >>> > >> > > >>>>>
> > >>> > >> > > >>>>> Not sure if varying the shades of the arrow as one
> > >>> > >> > > >>>>> proceeds through
> > >>> > >> > > >>>>> the moves in the moves list can allow a lot more of the
> > >>> > >> > > >>>>> sequence of
> > >>> > >> > > >>>>> moves to be inferred/shown because of dependencies like
> > >>> > >> > > >>>>> users
> > >>> > >> > > >>>>> monitor's brightness and contrast settings, as well as
> > >>> > >> > > >>>>> possible board
> > >>> > >> > > >>>>> square colors and so impacting visuals. However because
> > >>> > >> > > >>>>> the
> > >>> > >> > > >>>>> visualisation of moves logic has been moved into a func
> > >>> > >> > > >>>>> of its own,
> > >>> > >> > > >>>>> changing the logic in this single location should allow
> > >>> > >> > > >>>>> the benefits
> > >>> > >> > > >>>>> of any changes to be visible wherever the moves
> > >>> > >> > > >>>>> visualization function
> > >>> > >> > > >>>>> may be used.
> > >>> > >> > > >>>>>
> > >>> > >> > > >>>>>
> > >>> > >> > > >>>>>
> > >>> > >> > > >>>>> On Wed, Dec 4, 2024 at 4:46 PM Steve A
> > >>> > >> > > >>>>> <stevena...@gmail.com> wrote:
> > >>> > >> > > >>>>> >
> > >>> > >> > > >>>>> > The original anal board view showed the end position
> > >>> > >> > > >>>>> > after the whole pv was moved. I wonder if it would be
> > >>> > >> > > >>>>> > desirable to limit how many moves we see.
> > >>> > >> > > >>>>> >
> > >>> > >> > > >>>>> > But i'm thinking we should be making more use of the
> > >>> > >> > > >>>>> > arrow colors.
> > >>> > >> > > >>>>> > Mainly, i think we should be able to colour the main
> > >>> > >> > > >>>>> > PV black, then lighten up the other PV arrows ,
> > >>> > >> > > >>>>> > perhaps in accordance to their score... Might be
> > >>> > >> > > >>>>> > harder to code though. I'll try to look at it on the
> > >>> > >> > > >>>>> > weekend
> > >>> > >> > > >>>>> > eg set color [gradient $::defaultForeground .6 .]
> > >>> > >> > > >>>>> >
> > >>> > >> > > >>>>> > cheers
> > >>> > >> > > >>>>> >
> > >>> > >> > > >>>>> >
> > >>> > >> > > >>>>> > On Wednesday, December 4, 2024, Steve A
> > >>> > >> > > >>>>> > <stevena...@gmail.com> wrote:
> > >>> > >> > > >>>>> >>
> > >>> > >> > > >>>>> >> It's a nice idea, just that practical issues limit
> > >>> > >> > > >>>>> >> its clarity. Please send me your revisions and I'll
> > >>> > >> > > >>>>> >> see if I can contribute to it.
> > >>> > >> > > >>>>> >> Cheers
> > >>> > >> > > >>>>> >>
> > >>> > >> > > >>>>> >> On Wednesday, December 4, 2024, C Hanish Menon
> > >>> > >> > > >>>>> >> <hanish...@gmail.com> wrote:
> > >>> > >> > > >>>>> >>>
> > >>> > >> > > >>>>> >>> Hi Steve,
> > >>> > >> > > >>>>> >>>
> > >>> > >> > > >>>>> >>> The idea behind my patch was to try and visualise
> > >>> > >> > > >>>>> >>> the initial few
> > >>> > >> > > >>>>> >>> moves of the 1st/main pv in a single/multipv
> > >>> > >> > > >>>>> >>> response from the engine.
> > >>> > >> > > >>>>> >>> And the reason was to try and make it easier to get
> > >>> > >> > > >>>>> >>> a feel of the
> > >>> > >> > > >>>>> >>> chain (or otherwise) of moves that the engine may be
> > >>> > >> > > >>>>> >>> suggesting/looking-at in an easy implicit way,
> > >>> > >> > > >>>>> >>> without having to do
> > >>> > >> > > >>>>> >>> any end user driven actions on the gui (like using
> > >>> > >> > > >>>>> >>> +v (with or without
> > >>> > >> > > >>>>> >>> trial mode) and in turn looking at the moves in
> > >>> > >> > > >>>>> >>> detail on the main
> > >>> > >> > > >>>>> >>> board, by navigating through the moves).
> > >>> > >> > > >>>>> >>>
> > >>> > >> > > >>>>> >>> Also given that one may want to run different
> > >>> > >> > > >>>>> >>> engines parallely at the
> > >>> > >> > > >>>>> >>> same time, it makes more sense to visualise the
> > >>> > >> > > >>>>> >>> engine moves on the
> > >>> > >> > > >>>>> >>> respective local analysis board, rather than the
> > >>> > >> > > >>>>> >>> main board. This also
> > >>> > >> > > >>>>> >>> avoids the additional decision that needs to be made
> > >>> > >> > > >>>>> >>> otherwise of
> > >>> > >> > > >>>>> >>> which of the engine's main pv to show on the main
> > >>> > >> > > >>>>> >>> board, if the main
> > >>> > >> > > >>>>> >>> board were to be used. While parallely giving the
> > >>> > >> > > >>>>> >>> flexibility of
> > >>> > >> > > >>>>> >>> viewing main pv of multiple engines parallely in
> > >>> > >> > > >>>>> >>> their separate
> > >>> > >> > > >>>>> >>> analysis boards.
> > >>> > >> > > >>>>> >>>
> > >>> > >> > > >>>>> >>> Also keeping the logic to be a simple visualisation
> > >>> > >> > > >>>>> >>> and not
> > >>> > >> > > >>>>> >>> interaction with the corresponding visualisation,
> > >>> > >> > > >>>>> >>> ensures that the
> > >>> > >> > > >>>>> >>> already existing logic of showing the 1st move of
> > >>> > >> > > >>>>> >>> the different
> > >>> > >> > > >>>>> >>> multiple pv's that the engine generates on the
> > >>> > >> > > >>>>> >>> analysis board and in
> > >>> > >> > > >>>>> >>> turn clicking it to use as the move on the main
> > >>> > >> > > >>>>> >>> board, doesnt get
> > >>> > >> > > >>>>> >>> affected/overloaded in any way. Nor needed given
> > >>> > >> > > >>>>> >>> that the idea was to
> > >>> > >> > > >>>>> >>> visualise the initial few moves in the engine's main
> > >>> > >> > > >>>>> >>> pv (among
> > >>> > >> > > >>>>> >>> single/multipv).
> > >>> > >> > > >>>>> >>>
> > >>> > >> > > >>>>> >>> Also at a different level, not sure why, but I am
> > >>> > >> > > >>>>> >>> not seeing the 1st
> > >>> > >> > > >>>>> >>> move each of the different multipv's generated by
> > >>> > >> > > >>>>> >>> the analysis engine,
> > >>> > >> > > >>>>> >>> on the main board, after enabling show arrows in
> > >>> > >> > > >>>>> >>> Tools->AnalysisEngine.
> > >>> > >> > > >>>>> >>>
> > >>> > >> > > >>>>> >>> PS: I am refining my patch further like using shadow
> > >>> > >> > > >>>>> >>> colors to make
> > >>> > >> > > >>>>> >>> the text more visible irrespective of underlying
> > >>> > >> > > >>>>> >>> square or piece is
> > >>> > >> > > >>>>> >>> light or dark; look at using dict to allow showing
> > >>> > >> > > >>>>> >>> move numbers of
> > >>> > >> > > >>>>> >>> multiple moves landing on same square; try ensure
> > >>> > >> > > >>>>> >>> that move numbers
> > >>> > >> > > >>>>> >>> remain on screen, even when engine is in the middle
> > >>> > >> > > >>>>> >>> of building up the
> > >>> > >> > > >>>>> >>> next deeper level pv (rather I had purposefully not
> > >>> > >> > > >>>>> >>> looked at adding
> > >>> > >> > > >>>>> >>> support for that to act as a indication that what is
> > >>> > >> > > >>>>> >>> being visualised
> > >>> > >> > > >>>>> >>> in not the latest one, but the previous one, bcas
> > >>> > >> > > >>>>> >>> engine is still in
> > >>> > >> > > >>>>> >>> middle of building the current deeper pv; however
> > >>> > >> > > >>>>> >>> when switching
> > >>> > >> > > >>>>> >>> between different engine tabs, it is not practical
> > >>> > >> > > >>>>> >>> to try remember the
> > >>> > >> > > >>>>> >>> not shown move numbers). I may be done with these
> > >>> > >> > > >>>>> >>> changes in a day or
> > >>> > >> > > >>>>> >>> two, depending on as and when I can steal time to
> > >>> > >> > > >>>>> >>> work on this.
> > >>> > >> > > >>>>> >>>
> > >>> > >> > > >>>>> >>> On Tue, Dec 3, 2024 at 4:32 PM Steve A
> > >>> > >> > > >>>>> >>> <stevena...@gmail.com> wrote:
> > >>> > >> > > >>>>> >>> >
> > >>> > >> > > >>>>> >>> > Hmmm - it's interesting , but pretty raw and not
> > >>> > >> > > >>>>> >>> > something i'd use. But cheers.
> > >>> > >> > > >>>>> >>> >
> > >>> > >> > > >>>>> >>> > I thought for a second you were making a patch to
> > >>> > >> > > >>>>> >>> > draw the engine arrows on the main board, which
> > >>> > >> > > >>>>> >>> > lots of GUIs do already.
> > >>> > >> > > >>>>> >>> > This is also something i'm not too especially keen
> > >>> > >> > > >>>>> >>> > on because we have arrows everywhere already! :)
> > >>> > >> > > >>>>> >>> > And it presents lots of unresolved issues.
> > >>> > >> > > >>>>> >>> > .... But, since i *do* already have a quick patch
> > >>> > >> > > >>>>> >>> > that does this, I thought to add it to svn (which
> > >>> > >> > > >>>>> >>> > i've done just now, and also attached below).
> > >>> > >> > > >>>>> >>> > To see the arrows, you''ll have to select "Show
> > >>> > >> > > >>>>> >>> > Arrows" in Tools->AnalysisEngines.
> > >>> > >> > > >>>>> >>> > Cheers, S.A.
> > >>> > >> > > >>>>> >>> >
> > >>> > >> > > >>>>> >>> > On Tue, Dec 3, 2024 at 7:22 AM C Hanish Menon
> > >>> > >> > > >>>>> >>> > <hanish...@gmail.com> wrote:
> > >>> > >> > > >>>>> >>> >>
> > >>> > >> > > >>>>> >>> >> Hi Steve,
> > >>> > >> > > >>>>> >>> >>
> > >>> > >> > > >>>>> >>> >> I have tried adding support for simple
> > >>> > >> > > >>>>> >>> >> visualising of the main pv
> > >>> > >> > > >>>>> >>> >> generated by uci engine on the analysis board.
> > >>> > >> > > >>>>> >>> >> The user can control
> > >>> > >> > > >>>>> >>> >> how many moves ahead to show on the board, using
> > >>> > >> > > >>>>> >>> >> a spinbox I have
> > >>> > >> > > >>>>> >>> >> added next to the show analysis board
> > >>> > >> > > >>>>> >>> >> checkbox/button.
> > >>> > >> > > >>>>> >>> >>
> > >>> > >> > > >>>>> >>> >> I am attaching the patch with the email and a
> > >>> > >> > > >>>>> >>> >> sample image of how it appears.
> > >>> > >> > > >>>>> >>> >>
> > >>> > >> > > >>>>> >>> >> NOTE: I have patched the scid file directly. I am
> > >>> > >> > > >>>>> >>> >> not a tcl/tk
> > >>> > >> > > >>>>> >>> >> programmer, I have looked at the code in scid and
> > >>> > >> > > >>>>> >>> >> tried to
> > >>> > >> > > >>>>> >>> >> structure/implement the patch to get the job
> > >>> > >> > > >>>>> >>> >> done. There is a small
> > >>> > >> > > >>>>> >>> >> probability that I may not be doing things the
> > >>> > >> > > >>>>> >>> >> tcltk way.
> > >>> > >> > > >>>>> >>> >>
> > >>> > >> > > >>>>> >>> >> On Sat, Nov 30, 2024 at 6:58 PM C Hanish Menon
> > >>> > >> > > >>>>> >>> >> <hanish...@gmail.com> wrote:
> > >>> > >> > > >>>>> >>> >> >
> > >>> > >> > > >>>>> >>> >> > Hi Steve,
> > >>> > >> > > >>>>> >>> >> >
> > >>> > >> > > >>>>> >>> >> > Thanks for adapting and incorporating the
> > >>> > >> > > >>>>> >>> >> > patches.
> > >>> > >> > > >>>>> >>> >> >
> > >>> > >> > > >>>>> >>> >> > Regarding snap, I dont think I have currently
> > >>> > >> > > >>>>> >>> >> > set %F, it's been a long
> > >>> > >> > > >>>>> >>> >> > time, I normally start from the command line.
> > >>> > >> > > >>>>> >>> >> > However it is a good
> > >>> > >> > > >>>>> >>> >> > input, which can be useful for many, will
> > >>> > >> > > >>>>> >>> >> > update it.
> > >>> > >> > > >>>>> >>> >> >
> > >>> > >> > > >>>>> >>> >> > Previously in the snapcraft.yaml file, which I
> > >>> > >> > > >>>>> >>> >> > am also bundling with
> > >>> > >> > > >>>>> >>> >> > snap, I was fetching the latest svn commit and
> > >>> > >> > > >>>>> >>> >> > creating a snap of it,
> > >>> > >> > > >>>>> >>> >> > so that anyone attempting to create snap on
> > >>> > >> > > >>>>> >>> >> > their own can get the
> > >>> > >> > > >>>>> >>> >> > latest svn commit based version. But with the
> > >>> > >> > > >>>>> >>> >> > new version of snapcraft
> > >>> > >> > > >>>>> >>> >> > (used to create snap), they seem to have
> > >>> > >> > > >>>>> >>> >> > removed/goofed up the svn
> > >>> > >> > > >>>>> >>> >> > fetch logic, so I am using the tar file of the
> > >>> > >> > > >>>>> >>> >> > scidvspc release. Need
> > >>> > >> > > >>>>> >>> >> > to check, how to patch in svn fetching again
> > >>> > >> > > >>>>> >>> >> > wrt snapcraft may be by
> > >>> > >> > > >>>>> >>> >> > overriding its default fetch flow, so that
> > >>> > >> > > >>>>> >>> >> > people can create snap
> > >>> > >> > > >>>>> >>> >> > using the latest commit, if possible.
> > >>> > >> > > >>>>> >>> >> >
> > >>> > >> > > >>>>> >>> >> > Given that you would be familiar with
> > >>> > >> > > >>>>> >>> >> > sourceforge and its svn, by any
> > >>> > >> > > >>>>> >>> >> > chance, do you know, if there is a standard url
> > >>> > >> > > >>>>> >>> >> > one could try to fetch
> > >>> > >> > > >>>>> >>> >> > to get an archive / tar of the latest svn
> > >>> > >> > > >>>>> >>> >> > commit of a project hosted
> > >>> > >> > > >>>>> >>> >> > on sourceforge svn.
> > >>> > >> > > >>>>> >>> >> >
> > >>> > >> > > >>>>> >>> >> > On Sat, Nov 30, 2024 at 3:13 AM Steve A
> > >>> > >> > > >>>>> >>> >> > <stevena...@gmail.com> wrote:
> > >>> > >> > > >>>>> >>> >> > >
> > >>> > >> > > >>>>> >>> >> > > Thanks Hanish. I've adopted or tweaked all
> > >>> > >> > > >>>>> >>> >> > > your changes and made a commit. (I've given
> > >>> > >> > > >>>>> >>> >> > > the analysis boards identical coord setup to
> > >>> > >> > > >>>>> >>> >> > > the main board, but making the font smaller).
> > >>> > >> > > >>>>> >>> >> > > https://sourceforge.net/p/scidvspc/code/3485/
> > >>> > >> > > >>>>> >>> >> > >
> > >>> > >> > > >>>>> >>> >> > > P.S. Thanks for creating the snap package. I
> > >>> > >> > > >>>>> >>> >> > > think i recently had some correspondence
> > >>> > >> > > >>>>> >>> >> > > about it. Do you include the %F arg (or
> > >>> > >> > > >>>>> >>> >> > > similar) in your scidvspc.desktop file (ie
> > >>> > >> > > >>>>> >>> >> > > "Exec=scid %F"). This allows opening desired
> > >>> > >> > > >>>>> >>> >> > > files.
> > >>> > >> > > >>>>> >>> >> > >
> > >>> > >> > > >>>>> >>> >> > > Regards Steven.
> > >>> > >> > > >>>>> >>> >> > >
> > >>> > >> > > >>>>> >>> >> > > On Sat, Nov 30, 2024 at 2:12 AM C Hanish
> > >>> > >> > > >>>>> >>> >> > > Menon <hanish...@gmail.com> wrote:
> > >>> > >> > > >>>>> >>> >> > >>
> > >>> > >> > > >>>>> >>> >> > >> Hi,
> > >>> > >> > > >>>>> >>> >> > >>
> > >>> > >> > > >>>>> >>> >> > >> I follow and explore chess very very
> > >>> > >> > > >>>>> >>> >> > >> infrequently, like once in a few
> > >>> > >> > > >>>>> >>> >> > >> years, usually when maybe a chess
> > >>> > >> > > >>>>> >>> >> > >> championship is going on or hear
> > >>> > >> > > >>>>> >>> >> > >> something about a new chess engine or I am
> > >>> > >> > > >>>>> >>> >> > >> experimenting something or
> > >>> > >> > > >>>>> >>> >> > >> so.
> > >>> > >> > > >>>>> >>> >> > >>
> > >>> > >> > > >>>>> >>> >> > >> So also I am not good at visualizing text
> > >>> > >> > > >>>>> >>> >> > >> chess move lines/variations
> > >>> > >> > > >>>>> >>> >> > >> without having visual hint like coordinates
> > >>> > >> > > >>>>> >>> >> > >> on a chess board.
> > >>> > >> > > >>>>> >>> >> > >>
> > >>> > >> > > >>>>> >>> >> > >> Given that currently ScidVsPC doesnt have an
> > >>> > >> > > >>>>> >>> >> > >> option for the same wrt
> > >>> > >> > > >>>>> >>> >> > >> analysis board, have created this patch (03-
> > >>> > >> > > >>>>> >>> >> > >> patch file name) to
> > >>> > >> > > >>>>> >>> >> > >> enable the same. If the user enables
> > >>> > >> > > >>>>> >>> >> > >> coordinates on all sides wrt the
> > >>> > >> > > >>>>> >>> >> > >> main board (ie boardCoords value 2), then
> > >>> > >> > > >>>>> >>> >> > >> this logic will enable
> > >>> > >> > > >>>>> >>> >> > >> coordinates on the analysis board.
> > >>> > >> > > >>>>> >>> >> > >>
> > >>> > >> > > >>>>> >>> >> > >> Inturn when working on this, noticed that
> > >>> > >> > > >>>>> >>> >> > >> the board::flip logic wasn't
> > >>> > >> > > >>>>> >>> >> > >> setting the vertical (1-8) coordinate values
> > >>> > >> > > >>>>> >>> >> > >> correctly for the
> > >>> > >> > > >>>>> >>> >> > >> analysis board always, it seemed to have a
> > >>> > >> > > >>>>> >>> >> > >> race based on when the
> > >>> > >> > > >>>>> >>> >> > >> board gets enabled and when the user toggles
> > >>> > >> > > >>>>> >>> >> > >> board coords. So have
> > >>> > >> > > >>>>> >>> >> > >> created a additional patch (04- patch file
> > >>> > >> > > >>>>> >>> >> > >> name) which sets the labels
> > >>> > >> > > >>>>> >>> >> > >> based purely on flip variable. NOTE: Not
> > >>> > >> > > >>>>> >>> >> > >> able to reproduce this
> > >>> > >> > > >>>>> >>> >> > >> currently, dont remember the sequence of
> > >>> > >> > > >>>>> >>> >> > >> enabling different options
> > >>> > >> > > >>>>> >>> >> > >> and boards, but did notice it few times
> > >>> > >> > > >>>>> >>> >> > >> initially, when I was working
> > >>> > >> > > >>>>> >>> >> > >> with only 03- patch file. Also this 04-
> > >>> > >> > > >>>>> >>> >> > >> patch file makes the logic
> > >>> > >> > > >>>>> >>> >> > >> directly depend on flip variable rather than
> > >>> > >> > > >>>>> >>> >> > >> any value that may be
> > >>> > >> > > >>>>> >>> >> > >> already there wrt the labels. So feel this
> > >>> > >> > > >>>>> >>> >> > >> may be a better logic.
> > >>> > >> > > >>>>> >>> >> > >>
> > >>> > >> > > >>>>> >>> >> > >>
> > >>> > >> > > >>>>> >>> >> > >> NOTE: I had created & inturn maintain
> > >>> > >> > > >>>>> >>> >> > >> scidvspc-hkvc snap package, to
> > >>> > >> > > >>>>> >>> >> > >> run scidvspc on linux distros with snap
> > >>> > >> > > >>>>> >>> >> > >> package system support, which
> > >>> > >> > > >>>>> >>> >> > >> again I update once in a bluemoon. These
> > >>> > >> > > >>>>> >>> >> > >> patches are included in the
> > >>> > >> > > >>>>> >>> >> > >> version which I have released there. I have
> > >>> > >> > > >>>>> >>> >> > >> added the suffix -hkvc to
> > >>> > >> > > >>>>> >>> >> > >> ensure that in future if the scidvspc team
> > >>> > >> > > >>>>> >>> >> > >> wants to release their own
> > >>> > >> > > >>>>> >>> >> > >> snap package, there is no confusion. These
> > >>> > >> > > >>>>> >>> >> > >> patches can be
> > >>> > >> > > >>>>> >>> >> > >> tested/verified by running the scidvspc-hkvc
> > >>> > >> > > >>>>> >>> >> > >> snap package, if needed.
> > >>> > >> > > >>>>> >>> >> > >>
> > >>> > >> > > >>>>> >>> >> > >> --
> > >>> > >> > > >>>>> >>> >> > >> Keep ;-)
> > >>> > >> > > >>>>> >>> >> > >> HanishKVC
> > >>> > >> > > >>>>> >>> >> > >> _______________________________________________
> > >>> > >> > > >>>>> >>> >> > >> Scidvspc-users mailing list
> > >>> > >> > > >>>>> >>> >> > >> Scidvspc-users@lists.sourceforge.net
> > >>> > >> > > >>>>> >>> >> > >> https://lists.sourceforge.net/lists/listinfo/scidvspc-users
> > >>> > >> > > >>>>> >>> >> >
> > >>> > >> > > >>>>> >>> >> >
> > >>> > >> > > >>>>> >>> >> >
> > >>> > >> > > >>>>> >>> >> > --
> > >>> > >> > > >>>>> >>> >> > Keep ;-)
> > >>> > >> > > >>>>> >>> >> > HanishKVC
> > >>> > >> > > >>>>> >>> >>
> > >>> > >> > > >>>>> >>> >>
> > >>> > >> > > >>>>> >>> >>
> > >>> > >> > > >>>>> >>> >> --
> > >>> > >> > > >>>>> >>> >> Keep ;-)
> > >>> > >> > > >>>>> >>> >> HanishKVC
> > >>> > >> > > >>>>> >>>
> > >>> > >> > > >>>>> >>>
> > >>> > >> > > >>>>> >>>
> > >>> > >> > > >>>>> >>> --
> > >>> > >> > > >>>>> >>> Keep ;-)
> > >>> > >> > > >>>>> >>> HanishKVC
> > >>> > >> > > >>>>>
> > >>> > >> > > >>>>>
> > >>> > >> > > >>>>>
> > >>> > >> > > >>>>> --
> > >>> > >> > > >>>>> Keep ;-)
> > >>> > >> > > >>>>> HanishKVC
> > >>> > >> > >
> > >>> > >> > >
> > >>> > >> > >
> > >>> > >> > > --
> > >>> > >> > > Keep ;-)
> > >>> > >> > > HanishKVC
> > >>> > >> >
> > >>> > >> >
> > >>> > >> >
> > >>> > >> > --
> > >>> > >> > Keep ;-)
> > >>> > >> > HanishKVC
> > >>> > >>
> > >>> > >>
> > >>> > >>
> > >>> > >> --
> > >>> > >> Keep ;-)
> > >>> > >> HanishKVC
> > >>> >
> > >>> >
> > >>> >
> > >>> > --
> > >>> > Keep ;-)
> > >>> > HanishKVC
> > >>>
> > >>>
> > >>>
> > >>> --
> > >>> Keep ;-)
> > >>> HanishKVC
> >
> >
> >
> > --
> > Keep ;-)
> > HanishKVC
>
>
>
> --
> Keep ;-)
> HanishKVC
--
Keep ;-)
HanishKVC
Index: tcl/start.tcl
===================================================================
--- tcl/start.tcl (revision 3488)
+++ tcl/start.tcl (revision 3501)
@@ -426,9 +426,10 @@
# Colors
-set analMainPVNumColor #fe019a ;# used to identify relative move seq number in analysis board mainpv visualisation 39ff14
-set analMainPVNumColorShadow #b0b0b0 ;# used to identify relative move seq number in analysis board mainpv visualisation 39ff14
-set analMainPVLineColor #606060 ;# used to identify move seq lines in analysis board mainpv visualisation
+set analMainPVSqNumColor #fe019a ;# identify relative move number on square in analysis board mainpv visualisation
+set analMainPVNumColorShadow #b0b0b0 ;# identify relative move number in analysis board mainpv visualisation
+set analMainPVLineColor #606060 ;# identify move seq lines in analysis board mainpv visualisation
+set analMainPVLineNumColor #ff5c00 ;# identify relative move number on move seq lines in analysis board mainpv visualisation
set lite #f3f3f3
set dark #7389b6 ;# dark and lite square colors
set highcolor #b0d0e0 ;# color when something is selected
Index: tcl/tools/analysis.tcl
===================================================================
--- tcl/tools/analysis.tcl (revision 3488)
+++ tcl/tools/analysis.tcl (revision 3501)
@@ -107,7 +107,8 @@
set analysis(logUpdate$n) {}
set analysis(seenWDL$n) 0
set analysis(mainPVVCount$n) 3 ;# how much of mainpv to show visually on analysis board
- set analysis(mainPVLengthSeen$n) 0
+ set analysis(mainPVLengthSeen$n) 0 ;# used to decide when to update the visualisation
+ set analysis(mainPVDepthSeen$n) 0 ;# used to decide when to update the visualisation
}
resetEngines
@@ -2417,6 +2418,7 @@
set analysis(mainPVVCount$n) 3
set analysis(mainPVLengthSeen$n) 0
+ set analysis(mainPVDepthSeen$n) 0
spinbox $w.b.mainpvvcount -from 0 -to 8 -increment 1 -textvar analysis(mainPVVCount$n) -justify center \
-width 2 -font font_Small -command "changeMainPVVCount $n"
::utils::tooltip::Set $w.b.mainpvvcount "MainPV visualisation length"
@@ -2735,6 +2737,7 @@
global analysis
set analysis(mainPVLengthSeen$n) 0
+ set analysis(mainPVDepthSeen$n) 0
}
@@ -3729,12 +3732,21 @@
updateAnalysisText $n
}
+
+proc bvmDrawText {board x y stext fontSize color colorShadow tag} {
+ set tfont "{courier 10 pitch} $fontSize"
+ eval $board create text [expr $x+1] [expr $y+1] -fill $colorShadow {-font $tfont} {-text "$stext"} {-anchor c} {-tag $tag}
+ eval $board create text $x $y -fill $color {-font $tfont} {-text "$stext"} {-anchor c} {-tag $tag}
+}
+
# C Hanish Menon
-proc boardVisualizeMoves {board n moves visCount colorLine colorNum colorNumShadow} {
+# Visualise upto visCount moves on the specified board
+proc boardVisualizeMoves {board n moves visCount colorLine colorLineNum colorSqNum colorNumShadow} {
+ $board delete bvm$n
+ set dSqValues [dict create]
set tbox [::board::mark::GetBox $board 0 0.8]
set tsize1 [expr int([lindex $tbox 4] * 0.5)]
set tsize2 [expr int([lindex $tbox 4] * 0.4)]
- set tfont2 "{courier 10 pitch} $tsize2"
set im 0
foreach cm $moves {
incr im
@@ -3742,18 +3754,39 @@
break
}
if {$cm != ""} {
+ # Get squares involved wrt the current move
set sq_start [::board::sq [string range $cm 0 1]]
set sq_end [::board::sq [string range $cm 2 3]]
+ # Show a arrow between start and end squares
+ # Additionally move number is shown towards center of the arrow (randomly btw 0.3 to 0.7),
+ # if moves land on same square, so that one can differentiate btw the moves,
+ # without potentially overlapping, even if the lines overlap.
set coord [::board::mark::GetArrowCoords $board $sq_start $sq_end $::board::arrowLength]
- $board create line $coord -fill $colorLine -arrow last -width 1 -arrowshape {4 6 2} -tag var
- set xmid [expr ([lindex $coord 0] + [lindex $coord 2]) / 2]
- set ymid [expr ([lindex $coord 1] + [lindex $coord 3]) / 2]
- $board create text $xmid $ymid -fill black -tag var -font $tfont2 -text $im -anchor c
- # $board raise var all
+ set randpos [expr 0.3+[::tcl::mathfunc::rand]*0.4]
+ set xbtw [expr [lindex $coord 0]+(([lindex $coord 2] - [lindex $coord 0]) * $randpos)]
+ set ybtw [expr [lindex $coord 1]+(([lindex $coord 3] - [lindex $coord 1]) * $randpos)]
+ set tline [
+ $board create line $coord -fill $colorLine -arrow last -width 1 -arrowshape {4 6 2} -tag bvm$n
+ ]
+ $board raise $tline all
+ set sqValue $im
+ # Show move num on the landing square, prepend if multiple moves land on same square
+ set tboxe [::board::mark::GetBox $board $sq_end 0.8]
+ set xe [lindex $tboxe 5]
+ set ye [lindex $tboxe 6]
+ if {[dict exists $dSqValues $sq_end]} {
+ $board delete bvmt$n$sq_end
+ bvmDrawText $board $xbtw $ybtw $sqValue $tsize2 $colorLineNum $colorNumShadow bvm$n
+ set sqValue "$sqValue,[dict get $dSqValues $sq_end]"
+ }
+ dict set dSqValues $sq_end $sqValue
+ bvmDrawText $board $xe $ye $sqValue $tsize2 $colorSqNum $colorNumShadow [list bvmt$n$sq_end bvm$n]
}
}
}
+
+
### Update the small analysis board in the analysis window,
proc updateAnalysisBoard {n {moves {}}} {
@@ -3824,9 +3857,12 @@
} else {
# Hanish's feature
# Show some amount of the initial part of the Main PV using thin arrows
- if {$analysis(uci$n) && [expr [llength $moves] > $analysis(mainPVLengthSeen$n)/2]} {
- set analysis(mainPVLengthSeen$n) [llength $moves]
- boardVisualizeMoves $bd.bd $n $moves $analysis(mainPVVCount$n) $::analMainPVLineColor $::analMainPVNumColor $::analMainPVNumColorShadow
+ if {$analysis(uci$n) && ([expr [llength $moves] > $analysis(mainPVLengthSeen$n)/2] || [expr $analysis(depth$n) > ($analysis(mainPVDepthSeen$n)+1)])} {
+ set analysis(mainPVLengthSeen$n) [llength $moves]
+ set analysis(mainPVDepthSeen$n) $analysis(depth$n)
+ boardVisualizeMoves $bd.bd $n $moves $analysis(mainPVVCount$n) $::analMainPVLineColor $::analMainPVLineNumColor $::analMainPVSqNumColor $::analMainPVNumColorShadow
+ } else {
+ $bd.bd raise bvm$n
}
}
} else {
_______________________________________________
Scidvspc-users mailing list
Scidvspc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/scidvspc-users
