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