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 <stevena...@gmail.com> 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
> <rashw...@gmail.com> 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
Scidvspc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/scidvspc-users

Reply via email to