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 _______________________________________________ Scidvspc-users mailing list Scidvspc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/scidvspc-users
