Thread: [Scidvspc-users] [Feature Request] Add more space in Tree Mask to see long comments
Chess Database and Toolkit program
Brought to you by:
stevenaaus
Menu
▾
▴
scidvspc-users
|
From: Yuval M. <yma...@gm...> - 2015-11-29 04:01:40
|
I just got around to using tree masks as a way to create my opening repertoire, and so far it's been great! However, one problem I have is the lack of space to view comments. I like to put large amount of analysis in my moves and right now the current solution is that I need to hover over the move and view the pop-up tooltip to read the entire comment. Is there a way I can view the comment all in one window, perhaps by wrapping the comment down (like a paragraph) in the tree window? Thanks. |
|
From: Richard F. A. I. <ras...@gm...> - 2015-11-29 20:26:40
|
Ok as a learning exercise I wanted to see what it would take to modify
what Yuval is looking for here in terms of displaying the comment.
My first assumption was that the comment they are talking about is the
position comment, since it is the one that displays as a single line at
the top
of the tree mask view.
To facilitate a multi line display here I needed a word wrap function for
the comment, I created one in tcl/utils/strings.tcl library.
proc ::utils::string::wrapParagraph {n text} {
regsub -all {\s+} [string trim $text] " " text
set RE "^(.{1,$n})(?:\\s+(.*))?$"
for {set result ""} {[regexp $RE $text -> line text]} {} {
append result $line "\n"
}
return [string trimright $result "\n"]
}
Then In the tcl/windows/tree.tcl I added a line to wordwrap the comment
text to 75
which is the width of the tree view table + the extra column for the
mask images
Inside proc ::tree:displayLines in the section #Mask position comment at
top of move list
set wrapPosComment [ ::utils::string::wrapParagraph 75 $posComment]
Then I modified this line to display the wrapped text rather than the
first line
changing this:
# $w.f.tl insert end "$firstLine\n" [ list bluefg tagtooltip_poscomment ]
to this:
$w.f.tl insert end "$wrapPosComment\n" [ list bluefg tagtooltip_poscomment ]
At the very least this met the request as far as I can tell in a usable way.
*Potential Improvements *
After testing the experience with some larger comments, I am thinking
the comment might
better be displayed with at the very least a horizontal rule line
separating it from the table
, but my TCL is so new, haven't figured that out yet.
It might also be some sort of option for people that don't want the
table to jump around
for really large comments, to instead move it to the bottom after the
table. (this would be pretty easy)
This canvas is pretty well done overall, my other job programming
experience makes me think
that the fixed width of the tree view table might enjoy a responsive
width treatment, where in
shorter width breakpoints each line of the table could become multi line
folding down or hiding
entirely some columns like the AvElo, Perf, AvYear, Draw, ECO codes.
And then only going single line or unhiding those columns as the display
width of the canvas increases. Ditto with the wrapping of the pos
comment, as the generic wrapping I added could actually update the wrap
point as well.
Regards,
Richard
On 11/28/2015 10:01 PM, Yuval Marcus wrote:
> I just got around to using tree masks as a way to create my opening
> repertoire, and so far it's been great!
>
> However, one problem I have is the lack of space to view comments. I
> like to put large amount of analysis in my moves and right now the
> current solution is that I need to hover over the move and view the
> pop-up tooltip to read the entire comment. Is there a way I can view
> the comment all in one window, perhaps by wrapping the comment down
> (like a paragraph) in the tree window?
>
> Thanks.
>
>
> ------------------------------------------------------------------------------
>
>
> _______________________________________________
> Scidvspc-users mailing list
> Sci...@li...
> https://lists.sourceforge.net/lists/listinfo/scidvspc-users
|
|
From: Steve A <ste...@gm...> - 2015-11-30 09:33:12
|
I *am* keen to make more text for the mask as requested and Richard's idea is a good one, but i would have to have a decent look. The tk text widget is very powerful and word wrap can normally be done using inbuilt features of the text widget. (tags, "-wrap", "-width") Also, I will probably add an option to make the tree show less data, leaving more space for the end of line mask comments. Re contributing code - If you could send contributed code as a patch, i can test it much more easily. ScidvsPC uses subversion. Once subverison is downloaded , or "checked-out" (see this page for instructions https://sourceforge.net/p/scidvspc/code/ People can make their own changes, test them using "make install", and then use "svn diff > patch" to make a patch for others to use. cheers, S.A. On Mon, Nov 30, 2015 at 6:01 PM, Steve A <ste...@gm...> wrote: > Thanks Richard :) > I'll look at your email properly by the weekend. > S.A > > On Mon, Nov 30, 2015 at 6:26 AM, Richard F. Ashwell III > <ras...@gm...> wrote: >> Ok as a learning exercise I wanted to see what it would take to modify >> what Yuval is looking for here in terms of displaying the comment. >> >> My first assumption was that the comment they are talking about is the >> position comment, since it is the one that displays as a single line at the >> top >> of the tree mask view. >> >> To facilitate a multi line display here I needed a word wrap function for >> the comment, I created one in tcl/utils/strings.tcl library. >> >> proc ::utils::string::wrapParagraph {n text} { >> regsub -all {\s+} [string trim $text] " " text >> set RE "^(.{1,$n})(?:\\s+(.*))?$" >> for {set result ""} {[regexp $RE $text -> line text]} {} { >> append result $line "\n" >> } >> return [string trimright $result "\n"] >> } >> >> Then In the tcl/windows/tree.tcl I added a line to wordwrap the comment text >> to 75 >> which is the width of the tree view table + the extra column for the mask >> images >> >> Inside proc ::tree:displayLines in the section #Mask position comment at top >> of move list >> >> set wrapPosComment [ ::utils::string::wrapParagraph 75 $posComment] >> >> Then I modified this line to display the wrapped text rather than the first >> line >> >> changing this: >> >> # $w.f.tl insert end "$firstLine\n" [ list bluefg tagtooltip_poscomment ] >> >> to this: >> >> $w.f.tl insert end "$wrapPosComment\n" [ list bluefg tagtooltip_poscomment ] >> >> At the very least this met the request as far as I can tell in a usable way. >> >> Potential Improvements >> After testing the experience with some larger comments, I am thinking the >> comment might >> better be displayed with at the very least a horizontal rule line separating >> it from the table >> , but my TCL is so new, haven't figured that out yet. >> >> It might also be some sort of option for people that don't want the table to >> jump around >> for really large comments, to instead move it to the bottom after the table. >> (this would be pretty easy) >> >> This canvas is pretty well done overall, my other job programming experience >> makes me think >> that the fixed width of the tree view table might enjoy a responsive width >> treatment, where in >> shorter width breakpoints each line of the table could become multi line >> folding down or hiding >> entirely some columns like the AvElo, Perf, AvYear, Draw, ECO codes. And >> then only going single line or unhiding those columns as the display width >> of the canvas increases. Ditto with the wrapping of the pos comment, as the >> generic wrapping I added could actually update the wrap point as well. >> >> Regards, >> Richard >> >> >> >> On 11/28/2015 10:01 PM, Yuval Marcus wrote: >> >> I just got around to using tree masks as a way to create my opening >> repertoire, and so far it's been great! >> >> However, one problem I have is the lack of space to view comments. I like to >> put large amount of analysis in my moves and right now the current solution >> is that I need to hover over the move and view the pop-up tooltip to read >> the entire comment. Is there a way I can view the comment all in one window, >> perhaps by wrapping the comment down (like a paragraph) in the tree window? >> >> Thanks. >> >> >> ------------------------------------------------------------------------------ >> >> >> >> _______________________________________________ >> Scidvspc-users mailing list >> Sci...@li... >> https://lists.sourceforge.net/lists/listinfo/scidvspc-users >> >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Scidvspc-users mailing list >> Sci...@li... >> https://lists.sourceforge.net/lists/listinfo/scidvspc-users >> |
|
From: Richard F. A. I. <ras...@gm...> - 2015-11-30 12:19:56
|
Steve, thanks for the direction and process info. This will help a lot. I am glad that you are a guiding eye on the TCL/TK stuff, as anything I hack together should be considered suspect for at least the next 3-4 months, as it is just too new of a language for me, specially in the area of already crafted libraries, etc. Any direction, you suggest I head in in terms of contributions, I would gladly follow, unless something pops up though, I'll probably just keep working on stuff that I get interested in, and send it out in patch form as you suggest as this is all just a learning experience for me, any sort of feedback even outright rejection, just lets me learn faster, so its all welcome. Some other areas that I thought I might attempt to tackle at some point but in no particular order and other suggestions are assuredly welcome: 1) I think with modern day tex systems at least texlive 2015, the latex that scidvspc produces, is woefully old, and broken, at least as far as my tests. This might be a big undertaking though but I am pretty complete in my tex skills, so it should be doable. 2) The under board game display with players, photo's and current position comment, info etc. could probably use a bit of layout organizing. This might be a way for me to learn more about tk both widgets, and positioning etc. For this, even before I play with the tcl stuff, I would probably draw a picture first of what I think (opinion) would be much easier to read, as it works now, it all jumbles up for me a bit in that panel, depending on the attributes of the game that are available, etc. 3) On the cpp side, the ingame engine seems to be able to use the gaviota table bases, I was thinking of adding the option to probe instead the more modern smaller, faster, etc. Syzygy tablebases. Perhaps as an option or maybe even a permanent replacement. Just some thoughts. Richard On 11/30/2015 03:33 AM, Steve A wrote: > I *am* keen to make more text for the mask as requested > and Richard's idea is a good one, but i would have to have a decent look. > The tk text widget is very powerful and word wrap can normally be done > using inbuilt features of the text widget. (tags, "-wrap", "-width") > > Also, I will probably add an option to make the tree > show less data, leaving more space for the end of line mask comments. > > Re contributing code - If you could send contributed code as a patch, > i can test it much more easily. > ScidvsPC uses subversion. Once subverison is downloaded , or "checked-out" > (see this page for instructions https://sourceforge.net/p/scidvspc/code/ > People can make their own changes, test them using "make install", > and then use "svn diff > patch" to make a patch for others to use. > > cheers, S.A. > > > On Mon, Nov 30, 2015 at 6:01 PM, Steve A <ste...@gm...> wrote: >> Thanks Richard :) >> I'll look at your email properly by the weekend. >> S.A >> >> On Mon, Nov 30, 2015 at 6:26 AM, Richard F. Ashwell III >> <ras...@gm...> wrote: >>> Ok as a learning exercise I wanted to see what it would take to modify >>> what Yuval is looking for here in terms of displaying the comment. >>> >>> My first assumption was that the comment they are talking about is the >>> position comment, since it is the one that displays as a single line at the >>> top >>> of the tree mask view. >>> >>> To facilitate a multi line display here I needed a word wrap function for >>> the comment, I created one in tcl/utils/strings.tcl library. >>> >>> proc ::utils::string::wrapParagraph {n text} { >>> regsub -all {\s+} [string trim $text] " " text >>> set RE "^(.{1,$n})(?:\\s+(.*))?$" >>> for {set result ""} {[regexp $RE $text -> line text]} {} { >>> append result $line "\n" >>> } >>> return [string trimright $result "\n"] >>> } >>> >>> Then In the tcl/windows/tree.tcl I added a line to wordwrap the comment text >>> to 75 >>> which is the width of the tree view table + the extra column for the mask >>> images >>> >>> Inside proc ::tree:displayLines in the section #Mask position comment at top >>> of move list >>> >>> set wrapPosComment [ ::utils::string::wrapParagraph 75 $posComment] >>> >>> Then I modified this line to display the wrapped text rather than the first >>> line >>> >>> changing this: >>> >>> # $w.f.tl insert end "$firstLine\n" [ list bluefg tagtooltip_poscomment ] >>> >>> to this: >>> >>> $w.f.tl insert end "$wrapPosComment\n" [ list bluefg tagtooltip_poscomment ] >>> >>> At the very least this met the request as far as I can tell in a usable way. >>> >>> Potential Improvements >>> After testing the experience with some larger comments, I am thinking the >>> comment might >>> better be displayed with at the very least a horizontal rule line separating >>> it from the table >>> , but my TCL is so new, haven't figured that out yet. >>> >>> It might also be some sort of option for people that don't want the table to >>> jump around >>> for really large comments, to instead move it to the bottom after the table. >>> (this would be pretty easy) >>> >>> This canvas is pretty well done overall, my other job programming experience >>> makes me think >>> that the fixed width of the tree view table might enjoy a responsive width >>> treatment, where in >>> shorter width breakpoints each line of the table could become multi line >>> folding down or hiding >>> entirely some columns like the AvElo, Perf, AvYear, Draw, ECO codes. And >>> then only going single line or unhiding those columns as the display width >>> of the canvas increases. Ditto with the wrapping of the pos comment, as the >>> generic wrapping I added could actually update the wrap point as well. >>> >>> Regards, >>> Richard >>> >>> >>> >>> On 11/28/2015 10:01 PM, Yuval Marcus wrote: >>> >>> I just got around to using tree masks as a way to create my opening >>> repertoire, and so far it's been great! >>> >>> However, one problem I have is the lack of space to view comments. I like to >>> put large amount of analysis in my moves and right now the current solution >>> is that I need to hover over the move and view the pop-up tooltip to read >>> the entire comment. Is there a way I can view the comment all in one window, >>> perhaps by wrapping the comment down (like a paragraph) in the tree window? >>> >>> Thanks. >>> >>> >>> ------------------------------------------------------------------------------ >>> >>> >>> >>> _______________________________________________ >>> Scidvspc-users mailing list >>> Sci...@li... >>> https://lists.sourceforge.net/lists/listinfo/scidvspc-users >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Scidvspc-users mailing list >>> Sci...@li... >>> https://lists.sourceforge.net/lists/listinfo/scidvspc-users >>> |
|
From: Steve A <ste...@gm...> - 2015-12-02 03:14:29
Attachments:
kings.png
|
I've made the tree window less verbose by default. Among other things, It leaves more room for mask comments. To restore the year/perf/etc stats, just toggle tree->options->ShortDisplay It's tough messing around with this widget, because of the field widths getting confused by translations, and the little bar-graphs inserted into the middle of the lines. On Wed, Dec 2, 2015 at 8:13 AM, Steve A <ste...@gm...> wrote: > That sounds fine Richard. I havent verified recently the status of Chess12 > as i keep upgrading OS, but i have a hunch it was broken on my last > OS, and dare say replacing it with Skak wholesale is the way to go. > The pdf looks great. :) > Steven > > On Tue, Dec 1, 2015 at 5:56 PM, Richard F. Ashwell III > <ras...@gm...> wrote: > > Ok, so tonight I started with #1. Here is the way I see the undertaking, > > and where I am at. > > > > 1) I think the chess1.2 latex stuff is broken, because of other changes > in > > the babel > > packages specifically as latex has changed over time. At the moment I > > can't get > > any exports of that latex (game, Opening Report, Player Report, etc) > to > > compile using texlive 2015, > > One I could still be doing something wrong, two I haven't tested on > say > > for example MikTex, > > or some other distro, but at least for me only the skak version of > the > > game export works, the > > other reports (Opening, Player, etc) don't have that as an option. > > Please someone speak up > > if you think the old latex stuff should be kept up (see below #2 as to > > why). > > > > 2) I am thinking even though the pattern, taken prior of export game to > > either latex preamble (chess1.2, or skak). It will just get more > > inconvenient, and ugly to add new menu items for the Opening, and Player > > Reports, so that there where two choices to print to latex, 1 for the old > > chess1.2, and one for skak. So basically I am suggesting, that unless > the > > chess1.2 gets upvoted for some reason, that I instead convert the other > > reports to skak/xskak latex instead, and finally after all the other > > reports, are replaced, I'll a) update the export skak version to xskak > (IE > > this actually makes the scid stuff easier, as xskak which is what is more > > commonly used now, has extended skak with features that make a lot of > this > > type of reporting in chess easier. > > > > 3) To this goal, I am starting with the Player Report, since the old > > chess1.2 one doesn't build for me, if anyone has one built to a pdf, > send it > > just because I really, want to dot i's and cross t's so to speak to make > > sure that what I am contributing is better without losing anything. In > the > > meantime I used the visual (ala html) version of the player report as a > > visual guide. I then took the raw chess1.2 export and rebuit it > skak/xskak > > style. Attached is an example pdf, of that rework which I have finished. > > > > 4) The next step for the Player report, is if I can get kind of a thumbs > up, > > on replacing the chess1.2 one, I'll rework the tcl into a patch that > prints > > to my new hotness instead. Otherwise if we want to keep both, I could > > possibly use some guidance, on the best way to add the options to the > menus > > for the print to latex, (things like labeling etc. IE "Print to Latex > > (Legacy chess1.2)" "Print to Latex (xskak)" etc. Again my vote is > replace, > > so it stays 1 item, Print to Latex :) > > > > 5) Assuming all goes well, from Player, to Opening, and then back to Game > > Export, etc. I would also like to swing back to the help documentation, > > with things like tips for mac/linux/windows, etc. In terms of getting > the > > reports rendered. > > > > Thoughts on Chess1.2? Is it time for it to go bye bye? To give you an > idea > > on how old this method is, for latex chess rendering, the documentation > for > > scid still says that you need to add the chess1.2 package including > > downloads for it etc, but texlive, and MikTex have both had the package > in > > their archives since March of 1992. So all of that stuff about > installing > > that package is 23 years old :) But the problem is unless you have a > really > > old package, I don't think it works anymore, unless someone here > surprises > > me. > > > > Regards, Or as Steven might say Cheers, > > Richard > > > > > > > > On 11/30/2015 01:38 PM, Steve A wrote: > >>> > >>> Some other areas that I thought I might attempt to tackle at some point > >>> but > >>> in no particular order and other suggestions are assuredly welcome: > >>> > >>> 1) I think with modern day tex systems at least texlive 2015, the latex > >>> that > >>> scidvspc produces, is woefully old, and broken, at least as far as my > >>> tests. > >>> This > >>> might be a big undertaking though but I am pretty complete in my tex > >>> skills, > >>> so > >>> it should be doable. > >> > >> That'd be great. We had a contributor who gave us the latex/Skak > >> export feature, but havent heard from him for a couple of releases > >> now. > >> > >>> 2) The under board game display with players, photo's and current > >>> position > >>> comment, info etc. could probably use a bit of layout organizing. This > >>> might > >>> be > >>> a way for me to learn more about tk both widgets, and positioning etc. > >>> For > >>> this, even > >>> before I play with the tcl stuff, I would probably draw a picture first > >>> of > >>> what I think (opinion) > >>> would be much easier to read, as it works now, it all jumbles up for > me a > >>> bit in that > >>> panel, depending on the attributes of the game that are available, etc. > >> > >> Hmmm. I have played with this a lot over the years. > >> There are so many options/scenarios here to consider. > >> One feature i have considered implementing recently is the display of > >> %clk and %emt values in this window, or somewhere else, > >> which i consider are the importnat ones from this web-site > >> http://www.enpassant.dk/chess/palview/enhancedpgn.htm > >> (In subversion i have just added the "smoves+" command to fics, which > >> stores the move times (%emt) fields in pgn. (Note the pgn window > >> should have the "Hise Square/Arrow Codes" optino disabled to see > >> them). > >> Perhaps they could go in here, between then NextMove and Length fields > >> 49. ... Bf6 Next: 50.d4 Length: 51 > >> 49. ... Bf6 Next: 50.d4 Clock: 1.45 Length: 51 > >> 49. ... Bf6 Next: 50.d4 Movetime: 1.45 Length: 51 > >> but there is other info that goes in this line too. > >> 52. ... Rb6 (Var) Next: 53.Rxb2 Material: 11-12:-1 > >> Length: 51 > >> See /*** Move , Material, Length line ****/ in src/tkscid.cpp > >> I see "Material" is shown (but only when the material side-board is > >> disabled) > >> > >>> 3) On the cpp side, the ingame engine seems to be able to use the > gaviota > >>> table bases, > >>> I was thinking of adding the option to probe instead the more modern > >>> smaller, faster, etc. > >>> Syzygy tablebases. Perhaps as an option or maybe even a permanent > >>> replacement. > >> > >> The in-built engine is hardly used at all, and is the only part of > >> ScidvsPC that i know occasionally dumps core. But crashes are hard to > >> hit. > >> to test, add this line to the very end of move.tcl ::move::Forward > >> and walk thorugh some long rook/knight vs knight end games > >> > >> set score [sc_pos analyze -time 50] > >> > >> Work needs to be done to tablebase support - for sure. > >> OTTOMH, we have an option for Nalimov bases, > >> but we don't automatically send this to the UCI engines, > >> and it probably wouldnt be too hard to do for me, > >> but others, less familiar with the code might find it hard. > >> Simliarly, we probably need a Syzygy base firectory option, > >> but i'd have to brush up on how engines use these options before i did > >> any work on it, and is hindered byu the fact i have low bandwidth and > >> don't install these bases myself. > >> > >> cheers, S. > > > > > |
|
From: Richard F. A. I. <ras...@gm...> - 2015-12-03 22:32:39
|
Steven,
So I am in the middle of fixing some of the latex stuff, was going
to do one report at time
but as you are probably aware they are all interconnected. One of the
things I ran across is the latexifytree routine in optables.tcl is all
kinds of busted, mostly because it is expecting a lot of columns that
aren't appearing anymore from sc_tree search. Before, I just plod along
and fix all of this up too, is it related to the short display you've
created for the mask view?
Another very real possibility based on what I see in the code, is
someone just wanted to remove all of the extra columns of the opening
report, and didn't realize that this would break the latex portion. It
might have been broken for a long time, because the latex report will
generate. It is just the data in the "Moves from the report position"
section of the report will have incorrect display and bad data in
columns. Things like Frequency numbers bleeding over into the ECO
column which it expects to be there but is suppressed on the data pull
from sc_tree search now. So for example if you ran just a quick Opening
report and looked at that section you will notice the ECO column isn't
there. The latexify still expects it, and so all of the range gets are
off.
To solve unless you tell me its related to this other work you where
doing, I'll just be modifying the latexifytree routine to not expect
those columns either.
Richard
On 12/01/2015 09:14 PM, Steve A wrote:
> I've made the tree window less verbose by default.
> Among other things, It leaves more room for mask comments.
> To restore the year/perf/etc stats, just toggle
> tree->options->ShortDisplay
>
> It's tough messing around with this widget, because of the field
> widths getting
> confused by translations, and the little bar-graphs inserted into the
> middle of the lines.
>
>
> On Wed, Dec 2, 2015 at 8:13 AM, Steve A <ste...@gm...
> <mailto:ste...@gm...>> wrote:
>
> That sounds fine Richard. I havent verified recently the status of
> Chess12
> as i keep upgrading OS, but i have a hunch it was broken on my last
> OS, and dare say replacing it with Skak wholesale is the way to go.
> The pdf looks great. :)
> Steven
>
> On Tue, Dec 1, 2015 at 5:56 PM, Richard F. Ashwell III
> <ras...@gm... <mailto:ras...@gm...>> wrote:
> > Ok, so tonight I started with #1. Here is the way I see the
> undertaking,
> > and where I am at.
> >
> > 1) I think the chess1.2 latex stuff is broken, because of other
> changes in
> > the babel
> > packages specifically as latex has changed over time. At the
> moment I
> > can't get
> > any exports of that latex (game, Opening Report, Player
> Report, etc) to
> > compile using texlive 2015,
> > One I could still be doing something wrong, two I haven't
> tested on say
> > for example MikTex,
> > or some other distro, but at least for me only the skak
> version of the
> > game export works, the
> > other reports (Opening, Player, etc) don't have that as an
> option.
> > Please someone speak up
> > if you think the old latex stuff should be kept up (see below
> #2 as to
> > why).
> >
> > 2) I am thinking even though the pattern, taken prior of export
> game to
> > either latex preamble (chess1.2, or skak). It will just get more
> > inconvenient, and ugly to add new menu items for the Opening,
> and Player
> > Reports, so that there where two choices to print to latex, 1
> for the old
> > chess1.2, and one for skak. So basically I am suggesting, that
> unless the
> > chess1.2 gets upvoted for some reason, that I instead convert
> the other
> > reports to skak/xskak latex instead, and finally after all the other
> > reports, are replaced, I'll a) update the export skak version to
> xskak (IE
> > this actually makes the scid stuff easier, as xskak which is
> what is more
> > commonly used now, has extended skak with features that make a
> lot of this
> > type of reporting in chess easier.
> >
> > 3) To this goal, I am starting with the Player Report, since the old
> > chess1.2 one doesn't build for me, if anyone has one built to a
> pdf, send it
> > just because I really, want to dot i's and cross t's so to speak
> to make
> > sure that what I am contributing is better without losing
> anything. In the
> > meantime I used the visual (ala html) version of the player
> report as a
> > visual guide. I then took the raw chess1.2 export and rebuit it
> skak/xskak
> > style. Attached is an example pdf, of that rework which I have
> finished.
> >
> > 4) The next step for the Player report, is if I can get kind of
> a thumbs up,
> > on replacing the chess1.2 one, I'll rework the tcl into a patch
> that prints
> > to my new hotness instead. Otherwise if we want to keep both, I
> could
> > possibly use some guidance, on the best way to add the options
> to the menus
> > for the print to latex, (things like labeling etc. IE "Print to
> Latex
> > (Legacy chess1.2)" "Print to Latex (xskak)" etc. Again my vote
> is replace,
> > so it stays 1 item, Print to Latex :)
> >
> > 5) Assuming all goes well, from Player, to Opening, and then
> back to Game
> > Export, etc. I would also like to swing back to the help
> documentation,
> > with things like tips for mac/linux/windows, etc. In terms of
> getting the
> > reports rendered.
> >
> > Thoughts on Chess1.2? Is it time for it to go bye bye? To give
> you an idea
> > on how old this method is, for latex chess rendering, the
> documentation for
> > scid still says that you need to add the chess1.2 package including
> > downloads for it etc, but texlive, and MikTex have both had the
> package in
> > their archives since March of 1992. So all of that stuff about
> installing
> > that package is 23 years old :) But the problem is unless you
> have a really
> > old package, I don't think it works anymore, unless someone here
> surprises
> > me.
> >
> > Regards, Or as Steven might say Cheers,
> > Richard
> >
> >
> >
> > On 11/30/2015 01:38 PM, Steve A wrote:
> >>>
> >>> Some other areas that I thought I might attempt to tackle at
> some point
> >>> but
> >>> in no particular order and other suggestions are assuredly
> welcome:
> >>>
> >>> 1) I think with modern day tex systems at least texlive 2015,
> the latex
> >>> that
> >>> scidvspc produces, is woefully old, and broken, at least as
> far as my
> >>> tests.
> >>> This
> >>> might be a big undertaking though but I am pretty complete in
> my tex
> >>> skills,
> >>> so
> >>> it should be doable.
> >>
> >> That'd be great. We had a contributor who gave us the latex/Skak
> >> export feature, but havent heard from him for a couple of releases
> >> now.
> >>
> >>> 2) The under board game display with players, photo's and current
> >>> position
> >>> comment, info etc. could probably use a bit of layout
> organizing. This
> >>> might
> >>> be
> >>> a way for me to learn more about tk both widgets, and
> positioning etc.
> >>> For
> >>> this, even
> >>> before I play with the tcl stuff, I would probably draw a
> picture first
> >>> of
> >>> what I think (opinion)
> >>> would be much easier to read, as it works now, it all jumbles
> up for me a
> >>> bit in that
> >>> panel, depending on the attributes of the game that are
> available, etc.
> >>
> >> Hmmm. I have played with this a lot over the years.
> >> There are so many options/scenarios here to consider.
> >> One feature i have considered implementing recently is the
> display of
> >> %clk and %emt values in this window, or somewhere else,
> >> which i consider are the importnat ones from this web-site
> >> http://www.enpassant.dk/chess/palview/enhancedpgn.htm
> >> (In subversion i have just added the "smoves+" command to fics,
> which
> >> stores the move times (%emt) fields in pgn. (Note the pgn window
> >> should have the "Hise Square/Arrow Codes" optino disabled to see
> >> them).
> >> Perhaps they could go in here, between then NextMove and Length
> fields
> >> 49. ... Bf6 Next: 50.d4 Length: 51
> >> 49. ... Bf6 Next: 50.d4 Clock: 1.45 Length: 51
> >> 49. ... Bf6 Next: 50.d4 Movetime: 1.45 Length: 51
> >> but there is other info that goes in this line too.
> >> 52. ... Rb6 (Var) Next: 53.Rxb2 Material: 11-12:-1
> >> Length: 51
> >> See /*** Move , Material, Length line ****/ in src/tkscid.cpp
> >> I see "Material" is shown (but only when the material side-board is
> >> disabled)
> >>
> >>> 3) On the cpp side, the ingame engine seems to be able to use
> the gaviota
> >>> table bases,
> >>> I was thinking of adding the option to probe instead the more
> modern
> >>> smaller, faster, etc.
> >>> Syzygy tablebases. Perhaps as an option or maybe even a permanent
> >>> replacement.
> >>
> >> The in-built engine is hardly used at all, and is the only part of
> >> ScidvsPC that i know occasionally dumps core. But crashes are
> hard to
> >> hit.
> >> to test, add this line to the very end of move.tcl ::move::Forward
> >> and walk thorugh some long rook/knight vs knight end games
> >>
> >> set score [sc_pos analyze -time 50]
> >>
> >> Work needs to be done to tablebase support - for sure.
> >> OTTOMH, we have an option for Nalimov bases,
> >> but we don't automatically send this to the UCI engines,
> >> and it probably wouldnt be too hard to do for me,
> >> but others, less familiar with the code might find it hard.
> >> Simliarly, we probably need a Syzygy base firectory option,
> >> but i'd have to brush up on how engines use these options
> before i did
> >> any work on it, and is hindered byu the fact i have low
> bandwidth and
> >> don't install these bases myself.
> >>
> >> cheers, S.
> >
> >
>
>
>
>
> ------------------------------------------------------------------------------
> Go from Idea to Many App Stores Faster with Intel(R) XDK
> Give your users amazing mobile app experiences with Intel(R) XDK.
> Use one codebase in this all-in-one HTML5 development environment.
> Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
> http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
>
>
> _______________________________________________
> Scidvspc-users mailing list
> Sci...@li...
> https://lists.sourceforge.net/lists/listinfo/scidvspc-users
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X