Re: [Scidvspc-users] [Feature Request] Add more space in Tree Mask to see long comments

[Richard F. A. I. <ras...@gm...>]

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