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