tag:old.nabble.com,2006:forum-1844Nabble - Gnu - Xboard2009-11-29T11:41:44ZGnu Xboard and WinBoard project. Gnu - Xboard home is <a href="http://www.ibiblio.org/pub/packages/solaris/sparc/html/GNUxboard.4.0.0.html" target="_top" rel="nofollow">here</a>.tag:old.nabble.com,2006:post-26565276[bug #28077] xboard needs to link against x112009-11-29T11:41:44Z2009-11-29T11:41:44ZSimon Goldschmidt<br>Update of bug #28077 (project xboard):
<br><br> Status: Ready For Test => Fixed
<br> Open/Closed: Open => Closed
<br><br><br> _______________________________________________________
<br><br>Reply to this item at:
<br><br> <<a href="http://savannah.gnu.org/bugs/?28077" target="_top" rel="nofollow">http://savannah.gnu.org/bugs/?28077</a>>
<br><br>_______________________________________________
<br> Message sent via/by Savannah
<br> <a href="http://savannah.gnu.org/" target="_top" rel="nofollow">http://savannah.gnu.org/</a><br><br><br><br>_______________________________________________
<br>Bug-XBoard mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26565276&i=0" target="_top" rel="nofollow">Bug-XBoard@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/bug-xboard" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/bug-xboard</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---Xboard---Bugs-f1845.html" embed="fixTarget[1845]" target="_top" >Gnu - Xboard - Bugs</a></p>tag:old.nabble.com,2006:post-26560989[bug #28077] xboard needs to link against x112009-11-29T02:57:42Z2009-11-29T02:57:42ZSimon Goldschmidt<br>Follow-up Comment #2, bug #28077 (project xboard):
<br><br>It builds fine with the latest code in git.
<br><br> _______________________________________________________
<br><br>Reply to this item at:
<br><br> <<a href="http://savannah.gnu.org/bugs/?28077" target="_top" rel="nofollow">http://savannah.gnu.org/bugs/?28077</a>>
<br><br>_______________________________________________
<br> Message sent via/by Savannah
<br> <a href="http://savannah.gnu.org/" target="_top" rel="nofollow">http://savannah.gnu.org/</a><br><br><br><br>_______________________________________________
<br>Bug-XBoard mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26560989&i=0" target="_top" rel="nofollow">Bug-XBoard@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/bug-xboard" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/bug-xboard</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---Xboard---Bugs-f1845.html" embed="fixTarget[1845]" target="_top" >Gnu - Xboard - Bugs</a></p>tag:old.nabble.com,2006:post-26555406[bug #28077] xboard needs to link against x112009-11-28T09:57:14Z2009-11-28T09:57:14ZSimon Goldschmidt<br>Update of bug #28077 (project xboard):
<br><br> Status: None => Ready For Test
<br> Assigned to: None => apersaud
<br><br> _______________________________________________________
<br><br>Follow-up Comment #1:
<br><br>Hi
<br><br>think I fixed it. Can you test the latest code in git (branch v4.4.x)? You
<br>need to run ./autogen, ./configure and then make.
<br><br>thanks for reporting
<br><br>ARUN
<br><br> _______________________________________________________
<br><br>Reply to this item at:
<br><br> <<a href="http://savannah.gnu.org/bugs/?28077" target="_top" rel="nofollow">http://savannah.gnu.org/bugs/?28077</a>>
<br><br>_______________________________________________
<br> Message sent via/by Savannah
<br> <a href="http://savannah.gnu.org/" target="_top" rel="nofollow">http://savannah.gnu.org/</a><br><br><br><br>_______________________________________________
<br>Bug-XBoard mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26555406&i=0" target="_top" rel="nofollow">Bug-XBoard@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/bug-xboard" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/bug-xboard</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---Xboard---Bugs-f1845.html" embed="fixTarget[1845]" target="_top" >Gnu - Xboard - Bugs</a></p>tag:old.nabble.com,2006:post-26549798almost ready for 4.4.22009-11-27T17:41:06Z2009-11-27T17:41:06ZArun PersaudHi
<br><br>just pushed a few more changes to Savannah. I still have 2 small patches
<br>here that I will add this weekend, but apart from that I think we could
<br>release 4.4.2. Would be great if people could test on different
<br>platforms. This release contains mostly bugfixes.
<br><br>cheers
<br> ARUN
<br><br><br><p>From forum: <a href="http://old.nabble.com/Gnu---XBoard---Devel-f36958.html" embed="fixTarget[36958]" target="_top" >Gnu - XBoard - Devel</a></p>tag:old.nabble.com,2006:post-26518112Re: Desired behavior: POV of scores2009-11-25T10:41:41Z2009-11-25T10:41:41ZTim MannI agree with all of that. The -*ScoreIsAbs thing is new since 4.2.7; I
<br>don't know when it was added. I don't have an opinion about whether
<br>it's worthwhile having a user option about which POV to use in
<br>display. We have a zillion options already, so if some people want
<br>this, I don't see any harm in providing it -- we already lost the
<br>"keep it simple" battle years ago. :-)
<br><br>On Wed, 25 Nov 2009 09:51:09 +0100, "h.g. muller" <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26518112&i=0" target="_top" rel="nofollow">h.g.muller@...</a>> wrote:
<div class='shrinkable-quote'><br>> There was some discussion on TalkChess on the Point Of View that should
<br>> be used for score reporting. Although it is not mentioned in the specs,
<br>> de-facto standard is that engines always report scores from the POV of the
<br>> side to move.
<br>>
<br>> This leads to a bit of a chaotic situation (which I do not want to address at
<br>> this moment in case the engine is pondering), as some engines ponder the
<br>> position after a speculative expected opponent move (so that their ponder
<br>> scores are from the POV of the side they are actually playing), while others
<br>> ponder the position as it is, and report scores from the POV of the opponent.
<br>>
<br>> What I do want to address is score reporting while the engine is thinking /
<br>> analyzing. There are engines which systematically report scores from the
<br>> white POV. In my opinion, this is a non-compliancy, but to be able to
<br>> accomodate
<br>> such engines in cases where the score is used for adjudication, WinBoard
<br>> provides the option "-first(second)ScoreIsAbs true|false". In 4.4.1,
<br>> setting this
<br>> option causes a score flip in MachineBlack mode, or for the engine playing
<br>> black
<br>> in TwoMachines mode.
<br>>
<br>> Now it seems to me that it should be counted as a bug that this is not extended
<br>> to other modes where the engine is evaluating a black move: IcsPlayingBlack
<br>> in zippy mode, and the various modes where an engine is analyzing (AnalyzeMode,
<br>> AnalyzeFile or IcsObserving in zippy mode when the engine is analyzing the
<br>> observed game), and black has the move. Also there the standard is that
<br>> engines
<br>> should report from the POV of the side to move, so that engines that report
<br>> from
<br>> the white POV need their score flipped to correct their non-compliancy.
<br>>
<br>> Do we agree about that?
<br>>
<br>> (In these new mode the score is not really used for anything like
<br>> adjudication,
<br>> so it might not seem to matter that much, but the score is presented to the
<br>> user,
<br>> and one of the major reasons why users would use AnalyzeMode at all, so I guess
<br>> this should count as a pretty important use.)
<br>>
<br>> Now a second, and independent question is this:
<br>>
<br>> Once all engines are compliant w.r.t. score reporting, or can be made
<br>> compliant with
<br>> the ScoreIsAbs option, what POV do we want to use for presenting this score
<br>> to the
<br>> user. It seems that the POV of the side to move, which is used now, is
<br>> compatible
<br>> with the EPD standard. There seem to be many users that hate it, though. Should
<br>> this be a user-settable option? We could, for instance, have a check box in the
<br>> Engine-Output window that would enable the user to select white POV or stm POV.
<br>>
<br>> Is this worth having?
<br>>
<br>>
</div><br><br>--
<br>Tim Mann <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26518112&i=1" target="_top" rel="nofollow">tim@...</a> <a href="http://tim-mann.org/" target="_top" rel="nofollow">http://tim-mann.org/</a><br><br><br><p>From forum: <a href="http://old.nabble.com/Gnu---XBoard---Devel-f36958.html" embed="fixTarget[36958]" target="_top" >Gnu - XBoard - Devel</a></p>tag:old.nabble.com,2006:post-26509906Re: Desired behavior: POV of scores2009-11-25T01:42:39Z2009-11-25T01:42:39ZMichel Van den Berghh.g. muller wrote:
<div class='shrinkable-quote'><br>> There was some discussion on TalkChess on the Point Of View that should
<br>> be used for score reporting. Although it is not mentioned in the specs,
<br>> de-facto standard is that engines always report scores from the POV of
<br>> the
<br>> side to move.
<br>>
<br>> This leads to a bit of a chaotic situation (which I do not want to
<br>> address at
<br>> this moment in case the engine is pondering), as some engines ponder the
<br>> position after a speculative expected opponent move (so that their ponder
<br>> scores are from the POV of the side they are actually playing), while
<br>> others
<br>> ponder the position as it is, and report scores from the POV of the
<br>> opponent.
<br>>
<br>> What I do want to address is score reporting while the engine is
<br>> thinking /
<br>> analyzing. There are engines which systematically report scores from the
<br>> white POV. In my opinion, this is a non-compliancy, but to be able to
<br>> accomodate
<br>> such engines in cases where the score is used for adjudication, WinBoard
<br>> provides the option "-first(second)ScoreIsAbs true|false". In 4.4.1,
<br>> setting this
<br>> option causes a score flip in MachineBlack mode, or for the engine
<br>> playing black
<br>> in TwoMachines mode.
<br>>
<br>> Now it seems to me that it should be counted as a bug that this is not
<br>> extended
<br>> to other modes where the engine is evaluating a black move:
<br>> IcsPlayingBlack
<br>> in zippy mode, and the various modes where an engine is analyzing
<br>> (AnalyzeMode,
<br>> AnalyzeFile or IcsObserving in zippy mode when the engine is analyzing
<br>> the
<br>> observed game), and black has the move. Also there the standard is
<br>> that engines
<br>> should report from the POV of the side to move, so that engines that
<br>> report from
<br>> the white POV need their score flipped to correct their non-compliancy.
<br>>
<br>> Do we agree about that?
<br>>
<br>> (In these new mode the score is not really used for anything like
<br>> adjudication,
<br>> so it might not seem to matter that much, but the score is presented
<br>> to the user,
<br>> and one of the major reasons why users would use AnalyzeMode at all,
<br>> so I guess
<br>> this should count as a pretty important use.)
<br>>
<br>> Now a second, and independent question is this:
<br>>
<br>> Once all engines are compliant w.r.t. score reporting, or can be made
<br>> compliant with
<br>> the ScoreIsAbs option, what POV do we want to use for presenting this
<br>> score to the
<br>> user. It seems that the POV of the side to move, which is used now, is
<br>> compatible
<br>> with the EPD standard. There seem to be many users that hate it,
<br>> though. Should
<br>> this be a user-settable option? We could, for instance, have a check
<br>> box in the
<br>> Engine-Output window that would enable the user to select white POV or
<br>> stm POV.
<br>>
<br>> Is this worth having?
<br>>
<br>>
</div>I don't have much to say about the analysis issue but I do hope the
<br>current default
<br>remains available (side to move POV).
<br><br><br>The ponder issue is easy to solve. Just make the engine put the move it
<br>was pondering
<br>on between (...) in the PV. This visually suggests that the engine has
<br>made the move on its internal
<br>board and has analyzed it from the POV it is playing (rather than from
<br>the POV of the
<br>side to move). This works both for engines that ponder the move and
<br>engines that ponder the position.
<br><br><br><br><br><br><br><br><br><p>From forum: <a href="http://old.nabble.com/Gnu---XBoard---Devel-f36958.html" embed="fixTarget[36958]" target="_top" >Gnu - XBoard - Devel</a></p>tag:old.nabble.com,2006:post-26509277Desired behavior: POV of scores2009-11-25T00:51:09Z2009-11-25T00:51:09Zh.g. mullerThere was some discussion on TalkChess on the Point Of View that should
<br>be used for score reporting. Although it is not mentioned in the specs,
<br>de-facto standard is that engines always report scores from the POV of the
<br>side to move.
<br><br>This leads to a bit of a chaotic situation (which I do not want to address at
<br>this moment in case the engine is pondering), as some engines ponder the
<br>position after a speculative expected opponent move (so that their ponder
<br>scores are from the POV of the side they are actually playing), while others
<br>ponder the position as it is, and report scores from the POV of the opponent.
<br><br>What I do want to address is score reporting while the engine is thinking /
<br>analyzing. There are engines which systematically report scores from the
<br>white POV. In my opinion, this is a non-compliancy, but to be able to
<br>accomodate
<br>such engines in cases where the score is used for adjudication, WinBoard
<br>provides the option "-first(second)ScoreIsAbs true|false". In 4.4.1,
<br>setting this
<br>option causes a score flip in MachineBlack mode, or for the engine playing
<br>black
<br>in TwoMachines mode.
<br><br>Now it seems to me that it should be counted as a bug that this is not extended
<br>to other modes where the engine is evaluating a black move: IcsPlayingBlack
<br>in zippy mode, and the various modes where an engine is analyzing (AnalyzeMode,
<br>AnalyzeFile or IcsObserving in zippy mode when the engine is analyzing the
<br>observed game), and black has the move. Also there the standard is that
<br>engines
<br>should report from the POV of the side to move, so that engines that report
<br>from
<br>the white POV need their score flipped to correct their non-compliancy.
<br><br>Do we agree about that?
<br><br>(In these new mode the score is not really used for anything like
<br>adjudication,
<br>so it might not seem to matter that much, but the score is presented to the
<br>user,
<br>and one of the major reasons why users would use AnalyzeMode at all, so I guess
<br>this should count as a pretty important use.)
<br><br>Now a second, and independent question is this:
<br><br>Once all engines are compliant w.r.t. score reporting, or can be made
<br>compliant with
<br>the ScoreIsAbs option, what POV do we want to use for presenting this score
<br>to the
<br>user. It seems that the POV of the side to move, which is used now, is
<br>compatible
<br>with the EPD standard. There seem to be many users that hate it, though. Should
<br>this be a user-settable option? We could, for instance, have a check box in the
<br>Engine-Output window that would enable the user to select white POV or stm POV.
<br><br>Is this worth having?
<br><br><br><p>From forum: <a href="http://old.nabble.com/Gnu---XBoard---Devel-f36958.html" embed="fixTarget[36958]" target="_top" >Gnu - XBoard - Devel</a></p>tag:old.nabble.com,2006:post-26491333Re: lots of changes in git2009-11-23T23:09:11Z2009-11-23T23:09:11Zh.g. muller<br>>probably better to use 4.4.1,n since we might run into version
<br>>problems... e.g windows might think that 4,2009,... is newer than 4,4,3,0
<br><br>That would certainly create a problem, as 20091122 does not fit in 16 bits.
<br>I don't think that Windows thinks anything about these numbers. The
<br>only thing they seem to be used for is when you hover the mouse pointer
<br>over the icon, is that it pops up a small text box that, amongst others,
<br>contains this information.
<br><br><br><br><p>From forum: <a href="http://old.nabble.com/Gnu---XBoard---Devel-f36958.html" embed="fixTarget[36958]" target="_top" >Gnu - XBoard - Devel</a></p>tag:old.nabble.com,2006:post-26478194Re: lots of changes in git2009-11-23T05:36:06Z2009-11-23T05:36:06Zh.g. mullerSome remarks about the numbering system and tagging:
<br><br>When you bump the version number, could you also update the
<br>PACKAGE_FILE_VERSION?
<br>This should be 4 16-bit integers, but that could still accomodate numbering
<br>like 4,2009,11,22,
<br>which would seem good for 4.20091122.
<br><br>I am not sure about the desiability of having intermediate tags like
<br>4.4.2.20091122 for 4.4.pre2
<br>versions in the 4.4.x branch. This branch should only contain complete
<br>patches for fixing
<br>small bugs that allow risk-less fixing. That means in principle that any
<br>git version there is
<br>as good as any other. If we want to invite more intensive testing at some
<br>point by providing
<br>a tar ball, we should simply tag it 4.4.x, and release. Because 4.4.x is
<br>still rather new and
<br>involved massive changes, we are still getting bug reports at an unusually
<br>high rate, but
<br>I am pretty sure that will slow down to a trickle at some point. (That was
<br>the whole idea
<br>of introducing the 4.4.x branch, to be able to converge to a high-quality
<br>stable version
<br>without new developments continuously introducing or exposing new bugs.)
<br><br>So eventually we will probably tag every commit to the 4.4.2 branch as a
<br>new release.
<br>Or we should distinguish major bugs (like absense of the WinBoard sources,
<br>or wrong
<br>castling rights on FEN pasting) from minor bugs (a deprecated menu not
<br>working properly,
<br>or crashing while already exiting on a fatal error) or cosmetic changes
<br>(removing superfluous
<br>debug messages), and only tag and do a new release for every major bug we fix.
<br>In practice we could hold up a release for a short time if we are working
<br>on fixing a few
<br>minor bugs and know that we will be done with that within a reasonable
<br>time. (Say one week).
<br><br>So I think what we should really do now is commit the forgotten pixmap
<br>patch for the opaque
<br>details of the leaky fairy pieces, and do an official 4.4.2 release. If
<br>people come with
<br>complaints on what we have in git now, the fixes will be for 4.4.3. The
<br>pixmaps patch
<br>in itself should be no reason to release a new version (it qualifies as
<br>cosmetic), but
<br>because we already have it waiting, it makes sense to include it in 4.4.2
<br>rather than save
<br>it for 4.4.3. The same holds for the build problem just reported by Vincent
<br>Legout.
<br><br>But I don't want to build in time-out periods, where we would only release
<br>after we
<br>have not received new bug reports in a specified amount of time. That makes
<br>no sense
<br>when bug reports will be arriving with Poissonian statistics at a fixed or
<br>slowly decreasing
<br>average rate, which they will if the patches we make will not introduce new
<br>bugs.
<br>Such a time-out period only makes sense if you think you might have
<br>introduced new bugs,
<br>and people need to be given some testing time to discover them. But patches
<br>in 4.4.x
<br>should not do that, and the only bug reports we should expect are for bugs
<br>that already
<br>manifested themselves in 4.4.1.
<br><br><br><p>From forum: <a href="http://old.nabble.com/Gnu---XBoard---Devel-f36958.html" embed="fixTarget[36958]" target="_top" >Gnu - XBoard - Devel</a></p>tag:old.nabble.com,2006:post-26472331[bug #28077] xboard needs to link against x112009-11-22T19:32:38Z2009-11-22T19:32:38ZSimon Goldschmidt<br>URL:
<br> <<a href="http://savannah.gnu.org/bugs/?28077" target="_top" rel="nofollow">http://savannah.gnu.org/bugs/?28077</a>>
<br><br> Summary: xboard needs to link against x11
<br> Project: XBoard
<br> Submitted by: None
<br> Submitted on: Mon 23 Nov 2009 03:32:37 AM UTC
<br> Category: None
<br> Severity: 3 - Normal
<br> Item Group: None
<br> Status: None
<br> Privacy: Public
<br> Assigned to: None
<br> Open/Closed: Open
<br> Discussion Lock: Any
<br><br> _______________________________________________________
<br><br>Details:
<br><br>Hi,
<br><br>xboard uses symbols from x11 but does not link to x11 explicitly. This leads
<br>to a build failure while using binutils-gold, which defaults to
<br>--no-add-needed.
<br>
<br>Add -lX11, -lXt and -lXmu to xboard_LDADD fixes the problem.
<br><br>For more explanations, see:
<br><a href="http://wiki.debian.org/qa.debian.org/FTBFS#A2009-11-02Packagesfailingbecausebinutils-gold.2BAC8-indirectlinking" target="_top" rel="nofollow">http://wiki.debian.org/qa.debian.org/FTBFS#A2009-11-02Packagesfailingbecausebinutils-gold.2BAC8-indirectlinking</a><br><a href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=556691" target="_top" rel="nofollow">http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=556691</a><br><br>Best Regards,
<br>Vincent Legout
<br><br><br><br><br> _______________________________________________________
<br><br>Reply to this item at:
<br><br> <<a href="http://savannah.gnu.org/bugs/?28077" target="_top" rel="nofollow">http://savannah.gnu.org/bugs/?28077</a>>
<br><br>_______________________________________________
<br> Message sent via/by Savannah
<br> <a href="http://savannah.gnu.org/" target="_top" rel="nofollow">http://savannah.gnu.org/</a><br><br><br><br>_______________________________________________
<br>Bug-XBoard mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26472331&i=0" target="_top" rel="nofollow">Bug-XBoard@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/bug-xboard" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/bug-xboard</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---Xboard---Bugs-f1845.html" embed="fixTarget[1845]" target="_top" >Gnu - Xboard - Bugs</a></p>tag:old.nabble.com,2006:post-26469745Re: lots of changes in git2009-11-22T13:35:51Z2009-11-22T13:35:51Zh.g. muller<br>>The master branch includes all changes including bigger ones (for
<br>>example frontend-backend separation). I also started a new branch called
<br>>4.4.x which contains mostly bugfixes and will become the next 4.4.2.
<br>>That one should get a bit more testing, so that we can release 4.4.2
<br>>soonish... It probably also needs updates for the windows .dev files...
<br><br>The 4.4.x branch should not need any updates to the make / project files,
<br>as they did not change the file structure. Although, during working on it,
<br>I ran into a missing dependency: It did not recompile the resource
<br>(winboard.rc) when I had changed the config.h, although winboard.rc
<br>(through a patch by Eric) now uses the version number defined in the latter.
<br><br>The master branch is significantly restructured; I only reflected those changes
<br>in Makefile.am (XBoard) and makefile.gcc (WinBoard). But it is a bit pointless
<br>to fix that now, as the patches that still reside with Arun will again change
<br>a lot compared to the latest version that is in git now.
<br><br><br><p>From forum: <a href="http://old.nabble.com/Gnu---XBoard---Devel-f36958.html" embed="fixTarget[36958]" target="_top" >Gnu - XBoard - Devel</a></p>tag:old.nabble.com,2006:post-26469252lots of changes in git2009-11-22T12:41:18Z2009-11-22T12:41:18ZArun PersaudHi
<br><br>HGM was working hard on lots of bug fixes and some long term changes and
<br>I finally managed to put most of it into git.
<br><br>The master branch includes all changes including bigger ones (for
<br>example frontend-backend separation). I also started a new branch called
<br>4.4.x which contains mostly bugfixes and will become the next 4.4.2.
<br>That one should get a bit more testing, so that we can release 4.4.2
<br>soonish... It probably also needs updates for the windows .dev files...
<br><br>cheers
<br> ARUN
<br><br><br><p>From forum: <a href="http://old.nabble.com/Gnu---XBoard---Devel-f36958.html" embed="fixTarget[36958]" target="_top" >Gnu - XBoard - Devel</a></p>tag:old.nabble.com,2006:post-26461484Re: Restoring window positions XBoard2009-11-21T15:33:41Z2009-11-21T15:33:41ZTim MannOn Sat, 21 Nov 2009 20:11:13 +0100, Michel Van den Bergh <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26461484&i=0" target="_top" rel="nofollow">michel.vandenbergh@...</a>> wrote:
<br>> There is something about this issue here.
<br>>
<br>> <a href="http://www.faqs.org/faqs/Xt-FAQ/section-32.html" target="_top" rel="nofollow">http://www.faqs.org/faqs/Xt-FAQ/section-32.html</a><br>>
<br>> I am not sure if it applies.
<br><br>That's related, but I don't think it's quite the same issue HGM is
<br>having. I think he's getting the coords of the shell window in root
<br>coordinate space when what he needs is the coords of the WM's frame
<br>window in root coordinate space.
<br><br>XtParent() may be part of the solution...
<br><br>--
<br>Tim Mann <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26461484&i=1" target="_top" rel="nofollow">tim@...</a> <a href="http://tim-mann.org/" target="_top" rel="nofollow">http://tim-mann.org/</a><br><br><br><p>From forum: <a href="http://old.nabble.com/Gnu---XBoard---Devel-f36958.html" embed="fixTarget[36958]" target="_top" >Gnu - XBoard - Devel</a></p>tag:old.nabble.com,2006:post-26459365Re: Restoring window positions XBoard2009-11-21T11:06:07Z2009-11-21T11:06:07ZMichel Van den Berghh.g. muller wrote:
<div class='shrinkable-quote'><br>> I have a very strange problem in XBoard. Now that it saves all settings,
<br>> including the window positions, I try to make all windows pop up in the
<br>> same place as on the previous sesion. This was already done for some
<br>> windows during a session, but now the information survives to the next
<br>> session through the settings file.
<br>>
<br>> Problem is that it does not work properly (and it also did not within a
<br>> session). I can trace the problem to unexpected (probably wrong)
<br>> behaviour of the Xtoolkit calls XtSetValues / XtGetValues, when
<br>> used with the arguments XtNx and XtNy. The values I Get are
<br>> not the same as those I Set. The x coordinate returned by XtGetValues
<br>> is always 4 larger than those that I set, the y coordinate 23. (Except
<br>> when I call XtGetValues immediately after setting them; then they
<br>> are both zero. Where "immediately" can mean 10 sec later after
<br>> calling it many times, but before clicking anything in the window.)
<br>>
<br>> Is this a known bug in X? Is the (4,23) correction a fixed quantity,
<br>> or does it depend on other system metrics? The width of the windows
<br>> also behaves suspicious (although there at least it is "what you Set is
<br>> what you Get"): when the main window is 418 wide, and I position
<br>> the EngineOutput window (say) to the right of it so it touches,
<br>> the difference of the x coordinate of the windows is not 418, but 428.
<br>> Even the (4,23) correction seems to be subject to rounding: when
<br>> I apply it, and position two windows exactly on top of each other,
<br>> when I close and re-open, sometimes they are moved over (1,1),
<br>> although mostly they pop up as the were.
<br>>
<br>>
</div>There is something about this issue here.
<br><br><a href="http://www.faqs.org/faqs/Xt-FAQ/section-32.html" target="_top" rel="nofollow">http://www.faqs.org/faqs/Xt-FAQ/section-32.html</a><br><br>I am not sure if it applies.
<br><br><br><br><br><p>From forum: <a href="http://old.nabble.com/Gnu---XBoard---Devel-f36958.html" embed="fixTarget[36958]" target="_top" >Gnu - XBoard - Devel</a></p>tag:old.nabble.com,2006:post-26459348Re: git issues2009-11-21T11:03:15Z2009-11-21T11:03:15ZTim MannOn Fri, 20 Nov 2009 23:27:15 +0100, "h.g. muller" <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26459348&i=0" target="_top" rel="nofollow">h.g.muller@...</a>> wrote:
<br>> Interrogating the window position of the Main
<br>> window, and then using those same coordinates to set the position of that
<br>> window do NOT make it pop up in the same place!
<br><br>That sounds familiar. You are probably getting the coordinates of the
<br>upper left corner of the window itself, without the title bar and
<br>resizing border (called "decorations" in X) that are added by the
<br>window manager.
<br><br>Then when you set the window position later, it's initially setting the
<br>upper left corner of the window itself, but very quickly after that the
<br>WM adds the decorations and moves the window to keep the upper left
<br>corner at the same position.
<br><br>IIRC, I had that problem at one point and had some kludge solution for
<br>it that required hardwiring the width of the decorations, which is a
<br>bad idea because they depend on what WM you're using and how it's
<br>configured ("theme" or whatever). I think there is a better solution,
<br>but I don't remember it now. Hmm, it probably requires you to find the
<br>parent window of the one you're currently querying (which will be the
<br>one that contains the decorations) and query that one instead.
<br><br>--
<br>Tim Mann <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26459348&i=1" target="_top" rel="nofollow">tim@...</a> <a href="http://tim-mann.org/" target="_top" rel="nofollow">http://tim-mann.org/</a><br><br><br><p>From forum: <a href="http://old.nabble.com/Gnu---XBoard---Devel-f36958.html" embed="fixTarget[36958]" target="_top" >Gnu - XBoard - Devel</a></p>tag:old.nabble.com,2006:post-26455316Restoring window positions XBoard2009-11-21T02:38:02Z2009-11-21T02:38:02Zh.g. mullerI have a very strange problem in XBoard. Now that it saves all settings,
<br>including the window positions, I try to make all windows pop up in the
<br>same place as on the previous sesion. This was already done for some
<br>windows during a session, but now the information survives to the next
<br>session through the settings file.
<br><br>Problem is that it does not work properly (and it also did not within a
<br>session). I can trace the problem to unexpected (probably wrong)
<br>behaviour of the Xtoolkit calls XtSetValues / XtGetValues, when
<br>used with the arguments XtNx and XtNy. The values I Get are
<br>not the same as those I Set. The x coordinate returned by XtGetValues
<br>is always 4 larger than those that I set, the y coordinate 23. (Except
<br>when I call XtGetValues immediately after setting them; then they
<br>are both zero. Where "immediately" can mean 10 sec later after
<br>calling it many times, but before clicking anything in the window.)
<br><br>Is this a known bug in X? Is the (4,23) correction a fixed quantity,
<br>or does it depend on other system metrics? The width of the windows
<br>also behaves suspicious (although there at least it is "what you Set is
<br>what you Get"): when the main window is 418 wide, and I position
<br>the EngineOutput window (say) to the right of it so it touches,
<br>the difference of the x coordinate of the windows is not 418, but 428.
<br>Even the (4,23) correction seems to be subject to rounding: when
<br>I apply it, and position two windows exactly on top of each other,
<br>when I close and re-open, sometimes they are moved over (1,1),
<br>although mostly they pop up as the were.
<br><br><br><p>From forum: <a href="http://old.nabble.com/Gnu---XBoard---Devel-f36958.html" embed="fixTarget[36958]" target="_top" >Gnu - XBoard - Devel</a></p>tag:old.nabble.com,2006:post-26459061Re: git issues2009-11-20T14:27:15Z2009-11-20T14:27:15Zh.g. muller<br>>I'd rather have ~/.config/xboard/xboard.conf. Testing if one directory
<br>>exists doesn't seem too much work for me ;) My second choice would be
<br>>~/.xboardrc.
<br><br>Well, here is a version (in args2.tar.gz) which does not do that yet, but
<br>is able to expand ~/xxx as settings-file name, fixes a bad bug in command-line
<br>parsing, and removes some unshielded debug prints. Better commit this
<br>xboard.c and args.c than the one I sent you previously; the intermediate
<br>version is not interesting, just crippled.
<br><br>I also attached a further development, as windowpos.tar.zip:
<br>This patch makes a beginning with reading out actual window coordinates
<br>in XBoard before saving settings, and restoring them when the window
<br>is opened in a later session. This now works for the Main, Comment and
<br>EngineOutput windows.
<br>Affects: xboard.c and xengineoutput.c
<br><br>This should in principle be done for all windows; problem is that the shell
<br>widgets of GameList, Tags and MoveHistory window are not global, but
<br>local to the .c files that implement these features, often hidden in structs
<br>that are only defined there. So all these files need a minute patch to make
<br>their shell widget accessible from xboard.c.
<br><br>Another problem is that it does not seem to work properly! The windows
<br>slowly drift to the lower right. Interrogating the window position of the Main
<br>window, and then using those same coordinates to set the position of that
<br>window do NOT make it pop up in the same place!
<br><br>Regards,
<br>H.G.<br /> <br /> <div class="small"><br/><img src="http://old.nabble.com/images/icon_attachment.gif" > <strong>args2.tar.gz</strong> (91K) <a href="http://old.nabble.com/attachment/26459061/0/args2.tar.gz" target="_top">Download Attachment</a><br/><img src="http://old.nabble.com/images/icon_attachment.gif" > <strong>windowpos.tar.gz</strong> (79K) <a href="http://old.nabble.com/attachment/26459061/1/windowpos.tar.gz" target="_top">Download Attachment</a></div><p>From forum: <a href="http://old.nabble.com/Gnu---XBoard---Devel-f36958.html" embed="fixTarget[36958]" target="_top" >Gnu - XBoard - Devel</a></p>tag:old.nabble.com,2006:post-26450675Re: git issues2009-11-20T13:38:05Z2009-11-20T13:38:05ZArun PersaudHi
<br><br>HGM wrote:
<br>> By this you mean we should create ~/.config and ~/.config/xboard if they
<br>> are not there, to write ~/.config/xboard/xboard.conf? Perhaps using
<br>> ~/.xboardrc is not such a bad idea after all...
<br><br>I'd rather have ~/.config/xboard/xboard.conf. Testing if one directory
<br>exists doesn't seem too much work for me ;) My second choice would be
<br>~/.xboardrc.
<br><br>cheers
<br> ARUN
<br><br><br><p>From forum: <a href="http://old.nabble.com/Gnu---XBoard---Devel-f36958.html" embed="fixTarget[36958]" target="_top" >Gnu - XBoard - Devel</a></p>tag:old.nabble.com,2006:post-26446718Re: git issues2009-11-20T08:51:17Z2009-11-20T08:51:17ZMichel Van den Bergh<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26446718&i=0" target="_top" rel="nofollow">h.g.muller@...</a> wrote:
<div class='shrinkable-quote'><br>>> It think the last alternative would be what is customary provided the
<br>>> user specific config file is in a standard location. If the user wants to
<br>>> put the config file in an exotic location then it would be ok I think to
<br>>> leave it up to him to ensure that this is possible.
<br>>>
<br>>
<br>> By this you mean we should create ~/.config and ~/.config/xboard if they
<br>> are not there, to write ~/.config/xboard/xboard.conf? Perhaps using
<br>> ~/.xboardrc is not such a bad idea after all...
<br>>
<br>> I have a Linux question anyway: I am now at a stage where redefining the
<br>> main settings file (where the save will take place) from within another
<br>> one (rather than from the command line). This required a subtle change in
<br>> behavior, because old behavior was that an expanded path name was written
<br>> back to the settingsFileName after parsing was complete, thus overwriting
<br>> anything that had changed during parsing. I now write back the expanded
<br>> path name before parsing, but after the file has been successfully opened.
<br>>
<br>> This works to redirect the save file to ./xboard.ini, but NOT to
<br>> ~/xboard.ini. Apparently the ~ is not a valid OS filename, but interpreted
<br>> by the shell? I tried using the function ExpandPathName onto the settings
<br>> file name, but that does not seem so help either. It keeps complaining
<br>> that it could not write "~/xboard.ini".
<br>>
<br>> How should this be handled?
<br>>
<br>>
<br>>
<br>>
</div>Some googling reveals that this should be handled by the function
<br>wordexp which is part of libc.
<br><br>I tried it with ~/xboard.ini and it does indeed work.
<br><br><br><br><br><p>From forum: <a href="http://old.nabble.com/Gnu---XBoard---Devel-f36958.html" embed="fixTarget[36958]" target="_top" >Gnu - XBoard - Devel</a></p>tag:old.nabble.com,2006:post-26446254Re: git issues2009-11-20T08:27:43Z2009-11-20T08:27:43Zh.g. muller> It think the last alternative would be what is customary provided the
<br>> user specific config file is in a standard location. If the user wants to
<br>> put the config file in an exotic location then it would be ok I think to
<br>> leave it up to him to ensure that this is possible.
<br><br>By this you mean we should create ~/.config and ~/.config/xboard if they
<br>are not there, to write ~/.config/xboard/xboard.conf? Perhaps using
<br>~/.xboardrc is not such a bad idea after all...
<br><br>I have a Linux question anyway: I am now at a stage where redefining the
<br>main settings file (where the save will take place) from within another
<br>one (rather than from the command line). This required a subtle change in
<br>behavior, because old behavior was that an expanded path name was written
<br>back to the settingsFileName after parsing was complete, thus overwriting
<br>anything that had changed during parsing. I now write back the expanded
<br>path name before parsing, but after the file has been successfully opened.
<br><br>This works to redirect the save file to ./xboard.ini, but NOT to
<br>~/xboard.ini. Apparently the ~ is not a valid OS filename, but interpreted
<br>by the shell? I tried using the function ExpandPathName onto the settings
<br>file name, but that does not seem so help either. It keeps complaining
<br>that it could not write "~/xboard.ini".
<br><br>How should this be handled?
<br><br><br><br><p>From forum: <a href="http://old.nabble.com/Gnu---XBoard---Devel-f36958.html" embed="fixTarget[36958]" target="_top" >Gnu - XBoard - Devel</a></p>tag:old.nabble.com,2006:post-26445498Re: git issues2009-11-20T07:52:01Z2009-11-20T07:52:01ZMichel Van den Berghh.g. muller wrote:
<div class='shrinkable-quote'><br>>
<br>>> A freshly installed user program that wants to write by default to a
<br>>> system configuration file (i.e. one in the /etc directory) would be
<br>>> *very* uncommon in Linux (and against the very idea of system
<br>>> configuration files which are supposed to be shared by all users).
<br>>>
<br>>> There is usually system wide configuration file (or directory)
<br>>> created at install time and a user specific one created when the user
<br>>> runs the program for the first time. For example I have
<br>>> /etc/firefox-3.5 and ~/.mozilla/firefox-3.5/ (and I wouldn't
<br>>> expect firefox to dump a configuration file in every
<br>>> directory I run it from....).
<br>>>
<br>>> In easy cases it is possible to dispense with the system wide
<br>>> configuration file.
<br>>
<br>> Well, you say the magic word: "installed". As long as they use "make
<br>> install",
<br>> and we make sure this creates the /etc/xboard/xboard.conf, defining a
<br>> default for
<br>> the user settings file, everything works smoothly. They would only
<br>> have problems
<br>> when they do not properly install xboard.
</div><br>Then there is a misunderstanding. I thought you proposed that the user
<br>would himself have to edit the system wide configuration file.
<div class='shrinkable-quote'><br>>
<br>> When /etc/xboard/xboard.conf contains the lines:
<br>>
<br>> -saveSettingsFile ~/.xboard/xboard.conf
<br>> -settingsFile ~/.xboard/xboard.conf
<br>>
<br>> a user would only get complaints on saving when ~/.xboard did not
<br>> exist, and
<br>> presumably he would be able to figure out how to solve that. (The
<br>> alternative
<br>> would be to make XBoard iteratively try to create all directories in
<br>> the path.)
</div>It think the last alternative would be what is customary provided the
<br>user specific config file is in a standard location. If the user wants to
<br>put the config file in an exotic location then it would be ok I think to
<br>leave it up to him to ensure
<br>that this is possible.
<br><br>In polyglot
<br>I just try to create the requested config directory (for engine specific
<br>config files). This works if the parent exists which would be the case
<br>if the parent was ~ which is the case
<br>for the default ~/.polyglot/.
<br><br>Recursively trying to create the directory path should not be hard but is
<br>probably not necessary.
<br><br><br><br>>
<br>> And crazy users like me would be happy as well, because they would simply
<br>> change the ~/.xboard/xboard.conf into ./xboard.ini, to get the
<br>> behavior they
<br>> desire.
<br>>
<br>>
<br><br><br><br><p>From forum: <a href="http://old.nabble.com/Gnu---XBoard---Devel-f36958.html" embed="fixTarget[36958]" target="_top" >Gnu - XBoard - Devel</a></p>tag:old.nabble.com,2006:post-26444747Re: git issues2009-11-20T06:57:51Z2009-11-20T06:57:51Zh.g. muller<div class='shrinkable-quote'><br>>A freshly installed user program that wants to write by default to a
<br>>system configuration file (i.e. one in the /etc directory) would be *very*
<br>>uncommon in Linux (and against the very idea of system configuration files
<br>>which are supposed to be shared by all users).
<br>>
<br>>There is usually system wide configuration file (or directory) created at
<br>>install time and a user specific one created when the user runs the
<br>>program for the first time. For example I have /etc/firefox-3.5 and
<br>>~/.mozilla/firefox-3.5/ (and I wouldn't expect firefox to dump a
<br>>configuration file in every
<br>>directory I run it from....).
<br>>
<br>>In easy cases it is possible to dispense with the system wide
<br>>configuration file.
</div><br>Well, you say the magic word: "installed". As long as they use "make install",
<br>and we make sure this creates the /etc/xboard/xboard.conf, defining a
<br>default for
<br>the user settings file, everything works smoothly. They would only have
<br>problems
<br>when they do not properly install xboard.
<br><br>When /etc/xboard/xboard.conf contains the lines:
<br><br>-saveSettingsFile ~/.xboard/xboard.conf
<br>-settingsFile ~/.xboard/xboard.conf
<br><br>a user would only get complaints on saving when ~/.xboard did not exist, and
<br>presumably he would be able to figure out how to solve that. (The alternative
<br>would be to make XBoard iteratively try to create all directories in the path.)
<br><br>And crazy users like me would be happy as well, because they would simply
<br>change the ~/.xboard/xboard.conf into ./xboard.ini, to get the behavior they
<br>desire.
<br><br><br><p>From forum: <a href="http://old.nabble.com/Gnu---XBoard---Devel-f36958.html" embed="fixTarget[36958]" target="_top" >Gnu - XBoard - Devel</a></p>tag:old.nabble.com,2006:post-26443931Re: git issues2009-11-20T06:17:16Z2009-11-20T06:17:16ZMichel Van den Berghh.g. muller wrote:
<div class='shrinkable-quote'><br>>
<br>>> I guess it does not really matter what the user specific
<br>>> configuration file is except I think it should
<br>>> definitely not be ./xboard.conf. That would mean that the xboard
<br>>> configuration would depend on
<br>>> the current directory which would lead to all kinds of surprizes
<br>>> (e.g. engines would use 64M hash
<br>>> in one directory and 128M hash in another directory).
<br>>
<br>> But that is exactly why I like it. I typically run WinBoard through a
<br>> Tournament Manager, which
<br>> gives me no control on what is on the command line that invoked it.
</div>This seems to be a problem which should be fixed in this particular
<br>Tournament Manager.... I just checked the documentation of
<br>"tourney-manager" (which comes with Ubuntu) and it allows
<br>straightforward control of xboard's command line arguments.
<br><div class='shrinkable-quote'><br>> So the only way to control
<br>> the WinBoard settings is to write them in the ini file in advance. And
<br>> when I run two tournaments
<br>> in paralel, one might need -variant gothic and the other -variant
<br>> normal. There would be no way
<br>> to do that if all invocations were forced to use the same ini file.
<br>> (Even for WinBoard I can only
<br>> do it by having two copies of winboard.exe, to have different install
<br>> directories. Inelegant, but
<br>> at least it works.)
</div>The customary way to deal with this situation is to provide xboard with
<br>a command line argument to select an alternative configuration file.
<br>This command line argument could be provided by the tournament manager.
<br><br>>
<br>> As to the configuration problem: When the default settingsfile is
<br>> /etc/xboard/xboard.conf, and
<br>> the user will try to save the settings (and -saveSettingsOnExit true
<br>> is compiled-in default...),
<br>> it will either work, or he will get an error popup mentioning that
<br>> this file could not be opened.
<br>
<br>> I guess it could be expected from Linux users that they then are smart
<br>> enough to actually
<br>> create the directory it is supposed to be in, and make it writable to
<br>> them.
<br>A freshly installed user program that wants to write by default to a
<br>system configuration file (i.e. one in the /etc directory) would be
<br>*very* uncommon in Linux (and against the very idea of system
<br>configuration files which are supposed to be shared by all users).
<br><br>There is usually system wide configuration file (or directory) created
<br>at install time and a user specific one created when the user runs the
<br>program for the first time. For example I have /etc/firefox-3.5 and
<br>~/.mozilla/firefox-3.5/ (and I wouldn't expect firefox to dump a
<br>configuration file in every
<br>directory I run it from....).
<br><br>In easy cases it is possible to dispense with the system wide
<br>configuration file.
<br><br><br><br><br><br><br><br>>
<br>> We could also provide a "make install" target in the Makefile, which
<br>> puts the directory there.
<br><br><br><br><p>From forum: <a href="http://old.nabble.com/Gnu---XBoard---Devel-f36958.html" embed="fixTarget[36958]" target="_top" >Gnu - XBoard - Devel</a></p>tag:old.nabble.com,2006:post-26439955Re: git issues2009-11-20T00:39:24Z2009-11-20T00:39:24ZMichel Van den Berghh.g. muller wrote:
<div class='shrinkable-quote'><br>>
<br>>> I think it should be the following order
<br>>>
<br>>> /etc/xboard/xboard.conf
<br>>> ~/.xboard/xboard.conf
<br>>>
<br>>> This is what is common on Linux. There should be a command line argument
<br>>> for specifying an alternative configuration file (or perhaps config
<br>>> directory).
<br>>>
<br>>> Michel
<br>>
<br>>> I think for linux the user file should go into
<br>>>
<br>>> ~/.config/xboard/xboard.conf
<br>>>
<br>>> That's where newer programs on my computer put there config files...
<br>>> other programs use something like ~/.xboardrc
<br>>>
<br>>> I remember reading somewhere that .conf should be the ending for config
<br>>> files, but I can't find a reference for that at the moment.
<br>>>
<br>>> ARUN
<br>>
<br>> Hmm, no agreement there... In fact the existing code allows an "-ini
<br>> FILENAME"
<br>> option in a settings file; encountering such an option makes XBoard
<br>> first process
<br>> the mentioned file as settings file, before finishing the processing
<br>> of the original
<br>> settings file. In addition the given FILENAME is remembered, and used
<br>> whenever
<br>> the settings are saved later. So if we use that option as the final
<br>> option occurring
<br>> in the system-wide settings file, the default place for the user
<br>> settings need not
<br>> be hard-coded, but becomes configurable itself. The compiled-in
<br>> defaults would
<br>> only have to decide on the standard place for the system-wide settings
<br>> (e.g.
<br>> /etc/xboard/xboard.conf), and only when the user would append as a
<br>> last line
<br>> to that file "-ini ./xboard.ini" he would read (and overrule) and save
<br>> settings from
<br>> an ini file in the current directory. Users that do not like that
<br>> could add the line
<br>> "-ini ~/xboard.ini" or "-ini ~/.config/xboard/xboard.conf" or "-ini
<br>> ~/.xboard/xboard.conf"
<br>> in stead, depending on their preference. The maintainer creating the
<br>> binary package
<br>> could decide which configuration fits the conventions of his
<br>> distribution best,
<br>> and include a system-wide settings file with the appropriate definition.
<br>>
<br>> If no secondary settings file was defined in the primary one, saving
<br>> the settings
<br>> would occur in the primary one.
<br>>
<br>>
<br>>
</div>This sounds sensible except that many people will install xboard with
<br>the standard mantra
<br><br>./configure
<br>make
<br>make install
<br><br>and if the system wide config file does not contain a suitable ini line
<br>users would end up
<br>with an xboard that does not remember settings (as is the current situation)
<br><br>I looked in the various Linux standard documents (LSB LFH) but I could
<br>not find a specification
<br>for what the the user specific configuration file should be.
<br>Traditionally it would indeed have been ~/.xboardrc then it changed to
<br>~/.xboard/xboard.conf and now it seems to be that many application use
<br>~/.config/xboard/xboard.conf.
<br><br>I guess it does not really matter what the user specific configuration
<br>file is except I think it should
<br>definitely not be ./xboard.conf. That would mean that the xboard
<br>configuration would depend on
<br>the current directory which would lead to all kinds of surprizes (e.g.
<br>engines would use 64M hash
<br>in one directory and 128M hash in another directory).
<br><br><br><br><br><br><br><br><br><p>From forum: <a href="http://old.nabble.com/Gnu---XBoard---Devel-f36958.html" embed="fixTarget[36958]" target="_top" >Gnu - XBoard - Devel</a></p>tag:old.nabble.com,2006:post-26439643Re: git issues2009-11-20T00:00:10Z2009-11-20T00:00:10Zh.g. muller<div class='shrinkable-quote'><br>>I think it should be the following order
<br>>
<br>>/etc/xboard/xboard.conf
<br>>~/.xboard/xboard.conf
<br>>
<br>>This is what is common on Linux. There should be a command line argument
<br>>for specifying an alternative configuration file (or perhaps config
<br>>directory).
<br>>
<br>>Michel
</div><div class='shrinkable-quote'><br>>I think for linux the user file should go into
<br>>
<br>>~/.config/xboard/xboard.conf
<br>>
<br>>That's where newer programs on my computer put there config files...
<br>>other programs use something like ~/.xboardrc
<br>>
<br>>I remember reading somewhere that .conf should be the ending for config
<br>>files, but I can't find a reference for that at the moment.
<br>>
<br>>ARUN
</div><br>Hmm, no agreement there... In fact the existing code allows an "-ini FILENAME"
<br>option in a settings file; encountering such an option makes XBoard first
<br>process
<br>the mentioned file as settings file, before finishing the processing of the
<br>original
<br>settings file. In addition the given FILENAME is remembered, and used whenever
<br>the settings are saved later. So if we use that option as the final option
<br>occurring
<br>in the system-wide settings file, the default place for the user settings
<br>need not
<br>be hard-coded, but becomes configurable itself. The compiled-in defaults would
<br>only have to decide on the standard place for the system-wide settings (e.g.
<br>/etc/xboard/xboard.conf), and only when the user would append as a last line
<br>to that file "-ini ./xboard.ini" he would read (and overrule) and save
<br>settings from
<br>an ini file in the current directory. Users that do not like that could add
<br>the line
<br>"-ini ~/xboard.ini" or "-ini ~/.config/xboard/xboard.conf" or "-ini
<br>~/.xboard/xboard.conf"
<br>in stead, depending on their preference. The maintainer creating the binary
<br>package
<br>could decide which configuration fits the conventions of his distribution best,
<br>and include a system-wide settings file with the appropriate definition.
<br><br>If no secondary settings file was defined in the primary one, saving the
<br>settings
<br>would occur in the primary one.
<br><br><br><br><p>From forum: <a href="http://old.nabble.com/Gnu---XBoard---Devel-f36958.html" embed="fixTarget[36958]" target="_top" >Gnu - XBoard - Devel</a></p>tag:old.nabble.com,2006:post-26432911Re: git issues2009-11-19T11:48:36Z2009-11-19T11:48:36ZArun PersaudHi
<br><br>> /etc/xboard/xboard.conf
<br>> ~/.xboard/xboard.conf
<br>>
<br>> This is what is common on Linux. There should be a command line argument
<br>> for specifying an alternative configuration file (or perhaps config
<br>> directory).
<br><br>I think for linux the user file should go into
<br><br>~/.config/xboard/xboard.conf
<br><br>That's where newer programs on my computer put there config files...
<br>other programs use something like ~/.xboardrc
<br><br>I remember reading somewhere that .conf should be the ending for config
<br>files, but I can't find a reference for that at the moment.
<br><br>ARUN
<br><br><br><br><p>From forum: <a href="http://old.nabble.com/Gnu---XBoard---Devel-f36958.html" embed="fixTarget[36958]" target="_top" >Gnu - XBoard - Devel</a></p>tag:old.nabble.com,2006:post-26431937Re: git issues2009-11-19T10:59:49Z2009-11-19T10:59:49ZMichel Van den Berghh.g. muller wrote:
<div class='shrinkable-quote'><br>> I am close to porting argument parsing and saving from WinBoard to
<br>> XBoard.
<br>> But I am still in doubt how to do this. In WinBoard we have the
<br>> concept of
<br>> an installDirectory, which is obtained from the registry, and the
<br>> settings file
<br>> (winboard.ini by default) is made there. I guess the Linux counterpart
<br>> of this
<br>> would be /usr/share/games/xboard. But I am not sure if this would be the
<br>> ideal place to create an xboard.ini file: the user might not have
<br>> write permission
<br>> to this directory. (This also starts to become a problem in WinBoard,
<br>> btw:
<br>> if WinBoard is installed in the /Program Files subtree in Vista, it
<br>> refuses to
<br>> create files in its installation folder!)
<br>>
<br>> Would it be better to create a settings file in the current directory,
<br>> or in the
<br>> users home directory? Perhaps we should define installDir[] = "~/.xboard"
<br>> (and create that if it doesn't exist, when we save settings)? That
<br>> could then
<br>> become the default place for the debug file, and saveGameFile as well.
<br>> Of course we could also keep everything in the current directory, so
<br>> the user
<br>> can controll where the files are made when he starts from the command
<br>> line.
<br>> That would displace the problem of defining a default directory to the
<br>> shortcut
<br>> people would use when starting from the emnu or clicking an icon,
<br>> however.
<br>>
<br>> Is it an idea to work with two xboard.ini files? After setting the
<br>> compiled-in
<br>> defaults, XBoard could read /usr/share/games/xboard/xboard.ini to
<br>> overrule
<br>> them by system-wide defaults, and after that ./xboard.ini or ~/xboard.ini
<br>> to overrule them with user-customized settings. (And after that of course
<br>> the command line would have its say.) When the user saves settings,
<br>> he would save in the latter. (But by default, the system-wide settings
<br>> would turne saveSettingsOnExit off.) The system-wide settings file
<br>> would never be saved, unless a user with admin rights would exxplicitly
<br>> mention the path name in an -ini command-line option (or copy it there).
<br>>
<br>> The more I think about it, the more I prefere using ./xboard.ini as
<br>> default
<br>> user settings file over ~/xboard.ini.
<br>>
<br>>
</div>I think it should be the following order
<br><br>/etc/xboard/xboard.conf
<br>~/.xboard/xboard.conf
<br><br>This is what is common on Linux. There should be a command line argument
<br>for specifying an alternative configuration file (or perhaps config
<br>directory).
<br><br><br><br><br><br><br><br><br><br><br><p>From forum: <a href="http://old.nabble.com/Gnu---XBoard---Devel-f36958.html" embed="fixTarget[36958]" target="_top" >Gnu - XBoard - Devel</a></p>tag:old.nabble.com,2006:post-26431750Re: git issues2009-11-19T10:43:17Z2009-11-19T10:43:17Zh.g. mullerI am close to porting argument parsing and saving from WinBoard to XBoard.
<br>But I am still in doubt how to do this. In WinBoard we have the concept of
<br>an installDirectory, which is obtained from the registry, and the settings file
<br>(winboard.ini by default) is made there. I guess the Linux counterpart of this
<br>would be /usr/share/games/xboard. But I am not sure if this would be the
<br>ideal place to create an xboard.ini file: the user might not have write
<br>permission
<br>to this directory. (This also starts to become a problem in WinBoard, btw:
<br>if WinBoard is installed in the /Program Files subtree in Vista, it refuses to
<br>create files in its installation folder!)
<br><br>Would it be better to create a settings file in the current directory, or
<br>in the
<br>users home directory? Perhaps we should define installDir[] = "~/.xboard"
<br>(and create that if it doesn't exist, when we save settings)? That could then
<br>become the default place for the debug file, and saveGameFile as well.
<br>Of course we could also keep everything in the current directory, so the user
<br>can controll where the files are made when he starts from the command line.
<br>That would displace the problem of defining a default directory to the shortcut
<br>people would use when starting from the emnu or clicking an icon, however.
<br><br>Is it an idea to work with two xboard.ini files? After setting the compiled-in
<br>defaults, XBoard could read /usr/share/games/xboard/xboard.ini to overrule
<br>them by system-wide defaults, and after that ./xboard.ini or ~/xboard.ini
<br>to overrule them with user-customized settings. (And after that of course
<br>the command line would have its say.) When the user saves settings,
<br>he would save in the latter. (But by default, the system-wide settings
<br>would turne saveSettingsOnExit off.) The system-wide settings file
<br>would never be saved, unless a user with admin rights would exxplicitly
<br>mention the path name in an -ini command-line option (or copy it there).
<br><br>The more I think about it, the more I prefere using ./xboard.ini as default
<br>user settings file over ~/xboard.ini.
<br><br><br><p>From forum: <a href="http://old.nabble.com/Gnu---XBoard---Devel-f36958.html" embed="fixTarget[36958]" target="_top" >Gnu - XBoard - Devel</a></p>tag:old.nabble.com,2006:post-26249515Re: What's Intrinsic? Did I fail to install something?2009-11-07T15:09:26Z2009-11-07T15:09:26ZArun PersaudHi
<br><br>Per Gunnarsson wrote:
<br>> Script started on Sat Nov 7 23:07:56 2009
<br>> /home/per/Desktop/xboard-4.4.1$ uname -a
<br>> OpenBSD mustafejen.kicks-ass.org 4.6 GENERIC#58 i386
<br>> /home/per/Desktop/xboard-4.4.1$ ./configure
<br>>[...]
<br>> checking for X11/Intrinsic.h... no
<br>> Xt headers not found
<br><br>seems like you missing some header files. Don't know how that's
<br>organized on OpenBSD. I'm using openSUSE and there that file come with
<br>the package xorg-x11-libXt-devel.
<br><br>HTH
<br><br>Arun
<br><br><br>_______________________________________________
<br>Bug-XBoard mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26249515&i=0" target="_top" rel="nofollow">Bug-XBoard@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/bug-xboard" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/bug-xboard</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---Xboard---Bugs-f1845.html" embed="fixTarget[1845]" target="_top" >Gnu - Xboard - Bugs</a></p>tag:old.nabble.com,2006:post-26249493What's Intrinsic? Did I fail to install something?2009-11-07T14:10:53Z2009-11-07T14:10:53ZPer Gunnarsson-3Script started on Sat Nov 7 23:07:56 2009
<br>/home/per/Desktop/xboard-4.4.1$ uname -a
<br>OpenBSD mustafejen.kicks-ass.org 4.6 GENERIC#58 i386
<br>/home/per/Desktop/xboard-4.4.1$ ./configure
<br>checking for a BSD-compatible install... /usr/bin/install -c
<br>checking whether build environment is sane... yes
<br>checking for a thread-safe mkdir -p... ./install-sh -c -d
<br>checking for gawk... no
<br>checking for mawk... no
<br>checking for nawk... nawk
<br>checking whether make sets $(MAKE)... yes
<br>checking for gcc... gcc
<br>checking for C compiler default output file name... a.out
<br>checking whether the C compiler works... yes
<br>checking whether we are cross compiling... no
<br>checking for suffix of executables...
<br>checking for suffix of object files... o
<br>checking whether we are using the GNU C compiler... yes
<br>checking whether gcc accepts -g... yes
<br>checking for gcc option to accept ISO C89... none needed
<br>checking for style of include used by make... GNU
<br>checking dependency style of gcc... gcc3
<br>checking how to run the C preprocessor... gcc -E
<br>checking for library containing strerror... none required
<br>checking for a BSD-compatible install... /usr/bin/install -c
<br>checking for flex... flex
<br>checking lex output file root... lex.yy
<br>checking lex library... -lfl
<br>checking whether yytext is a pointer... yes
<br>checking for remsh... no
<br>checking for rsh... rsh
<br>checking for makeinfo... makeinfo
<br>checking for nroff... nroff -man
<br>checking for awk... /usr/bin/awk
<br>checking for perl... /usr/bin/perl
<br>checking for grep that handles long lines and -e... /usr/bin/grep
<br>checking for egrep... /usr/bin/grep -E
<br>checking for ANSI C header files... yes
<br>checking whether time.h and sys/time.h may both be included... yes
<br>checking for sys/wait.h that is POSIX.1 compatible... yes
<br>checking for dirent.h that defines DIR... yes
<br>checking for library containing opendir... none required
<br>checking return type of signal handlers... void
<br>checking for sys/types.h... yes
<br>checking for sys/stat.h... yes
<br>checking for stdlib.h... yes
<br>checking for string.h... yes
<br>checking for memory.h... yes
<br>checking for strings.h... yes
<br>checking for inttypes.h... yes
<br>checking for stdint.h... yes
<br>checking for unistd.h... yes
<br>checking stropts.h usability... no
<br>checking stropts.h presence... no
<br>checking for stropts.h... no
<br>checking sys/time.h usability... yes
<br>checking sys/time.h presence... yes
<br>checking for sys/time.h... yes
<br>checking for string.h... (cached) yes
<br>checking for unistd.h... (cached) yes
<br>checking sys/systeminfo.h usability... no
<br>checking sys/systeminfo.h presence... no
<br>checking for sys/systeminfo.h... no
<br>checking malloc.h usability... yes
<br>checking malloc.h presence... yes
<br>checking for malloc.h... yes
<br>checking fcntl.h usability... yes
<br>checking fcntl.h presence... yes
<br>checking for fcntl.h... yes
<br>checking sys/socket.h usability... yes
<br>checking sys/socket.h presence... yes
<br>checking for sys/socket.h... yes
<br>checking stddef.h usability... yes
<br>checking stddef.h presence... yes
<br>checking for stddef.h... yes
<br>checking for _getpty... no
<br>checking for grantpt... no
<br>checking for setitimer... yes
<br>checking for usleep... yes
<br>checking for gettimeofday... yes
<br>checking for random... yes
<br>checking for gethostname... yes
<br>checking for setlocale... yes
<br>checking for getpseudotty in -lseq... no
<br>checking for X... libraries /usr/X11R6/lib, headers /usr/X11R6/include
<br>checking whether -R must be followed by a space... no
<br>checking for gethostbyname... yes
<br>checking for connect... yes
<br>checking for remove... yes
<br>checking for shmat... yes
<br>checking for IceConnectionNumber in -lICE... yes
<br>checking X11/Intrinsic.h usability... no
<br>checking X11/Intrinsic.h presence... no
<br>checking for X11/Intrinsic.h... no
<br>Xt headers not found
<br>/home/per/Desktop/xboard-4.4.1$ make
<br>make: no target to make.
<br>/home/per/Desktop/xboard-4.4.1$ ./xboard -debug
<br>/bin/ksh: ./xboard: not found
<br>/home/per/Desktop/xboard-4.4.1$ exit
<br><br>Script done on Sat Nov 7 23:09:03 2009
<br><br><br>_______________________________________________
<br>Bug-XBoard mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26249493&i=0" target="_top" rel="nofollow">Bug-XBoard@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/bug-xboard" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/bug-xboard</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---Xboard---Bugs-f1845.html" embed="fixTarget[1845]" target="_top" >Gnu - Xboard - Bugs</a></p>tag:old.nabble.com,2006:post-26242005Re: EditGame clears resultDetails2009-11-06T20:20:39Z2009-11-06T20:20:39ZTim MannOn Fri, 06 Nov 2009 19:49:13 +0100, "h.g. muller" <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26242005&i=0" target="_top" rel="nofollow">h.g.muller@...</a>> wrote:
<br>> Is there any special reason why switching to Edit-Game mode
<br>> clears the game result and resultDetails?
<br><br>I think it's only because once you've edited the game, the old result
<br>isn't valid anymore. As far as I know, what you propose below should
<br>work fine.
<br><div class='shrinkable-quote'><br>> I guess if you really are going
<br>> to edit the game by playing another move somewhere, the tail of the
<br>> game will disappear anyway, and the result with it. So it just speeds
<br>> up the unavoidable, although the user could change his mind,
<br>> and save the game unaltered after all (with spoiled tags).
<br>>
<br>> But now that I allow the user to explore variations, perhaps for the
<br>> purpose of adding them as comments to the main line when he
<br>> reverts to the latter, it is a bit inconvenient that the result is already
<br>> gone even before I shelve the main line by entering a move.
<br>> I did include code to shelve result and resultDetails as well, and
<br>> restore them on Revert, but now there is nothing to save.
<br>>
<br>> Would it break any other behavior when I defer the calling of
<br>> SetGameInfo() from EditGameEvent() until the user actually
<br>> alters the game? Perhaps I should shelve the entire gameInfo,
<br>> as when the user finally decides to Revert to the main line,
<br>> it ceases to be an "edited game", (although it might be a more
<br>> annotated one), and all the original tags would still be applicable?
</div><br><br><br><br>--
<br>Tim Mann <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26242005&i=1" target="_top" rel="nofollow">tim@...</a> <a href="http://tim-mann.org/" target="_top" rel="nofollow">http://tim-mann.org/</a><br><br><br><p>From forum: <a href="http://old.nabble.com/Gnu---XBoard---Devel-f36958.html" embed="fixTarget[36958]" target="_top" >Gnu - XBoard - Devel</a></p>tag:old.nabble.com,2006:post-26239516Re: WinBoard sources missing2009-11-06T14:21:23Z2009-11-06T14:21:23Zh.g. muller<div class='shrinkable-quote'><br>>should be relatively easy... as an alternative I could also just add the
<br>>winboard sources and put a tar-ball with the winboard source up for
<br>>download without any other modifications and we just don't change
<br>>version numbers yet. Or we get just test your refactoring patch to
<br>>include it too in 4.4.2 ;)
<br>>
<br>>What does everyone else think about those three options?
<br>>
<br>>Anyway, it will have to wait until tomorrow or Sunday until I will have
<br>>time to do it.
</div><br>I will probably not be able to get back in touch before the 11th.
<br>I think we should rethink our release policy, and perhaps
<br>include forking as a standard procedure. With this I mean that
<br>I would like to have a version where I experiment with large code
<br>changes, in parallel with a version where we only fix minor
<br>bugs, that we of course also fix in the alpha version, but which
<br>we can clear for release then much earlier.
<br><br>The 4.4.1 with two simple bug fixes (castling rights on FEN pasting
<br>and crash on engine crash) should in this scheme go out as 4.4.2
<br>in the new tar ball with WinBoard sources; the other stuff I have
<br>produced should then be called 4.4.2.<date> when we tag it
<br>as beta.
<br><br><br><br><br><p>From forum: <a href="http://old.nabble.com/Gnu---XBoard---Devel-f36958.html" embed="fixTarget[36958]" target="_top" >Gnu - XBoard - Devel</a></p>tag:old.nabble.com,2006:post-26237177EditGame clears resultDetails2009-11-06T10:49:13Z2009-11-06T10:49:13Zh.g. mullerIs there any special reason why switching to Edit-Game mode
<br>clears the game result and resultDetails? I guess if you really are going
<br>to edit the game by playing another move somewhere, the tail of the
<br>game will disappear anyway, and the result with it. So it just speeds
<br>up the unavoidable, although the user could change his mind,
<br>and save the game unaltered after all (with spoiled tags).
<br><br>But now that I allow the user to explore variations, perhaps for the
<br>purpose of adding them as comments to the main line when he
<br>reverts to the latter, it is a bit inconvenient that the result is already
<br>gone even before I shelve the main line by entering a move.
<br>I did include code to shelve result and resultDetails as well, and
<br>restore them on Revert, but now there is nothing to save.
<br><br>Would it break any other behavior when I defer the calling of
<br>SetGameInfo() from EditGameEvent() until the user actually
<br>alters the game? Perhaps I should shelve the entire gameInfo,
<br>as when the user finally decides to Revert to the main line,
<br>it ceases to be an "edited game", (although it might be a more
<br>annotated one), and all the original tags would still be applicable?
<br><br><br><p>From forum: <a href="http://old.nabble.com/Gnu---XBoard---Devel-f36958.html" embed="fixTarget[36958]" target="_top" >Gnu - XBoard - Devel</a></p>tag:old.nabble.com,2006:post-26235740Re: WinBoard sources missing2009-11-06T09:11:16Z2009-11-06T09:11:16ZArun PersaudHi
<br><br>HGM wrote:
<div class='shrinkable-quote'><br>> OK, I am in favor of an immediate 4.4.2 release, then.
<br>> Problem is that I submitted the patches in the wrong order,
<br>> as I discovered the bug I introduced in the FEN pasting
<br>> only when doing the refctoring of e.p. and castling rights.
<br>> I would prefer that refactoring to go into a beta version,
<br>> and not dump it completely untested in a "stable release".
<br>>
<br>> Is there any easy way for you to invert the order of patches,
<br>> when they are to the same file? Solving the bug is reasonably
<br>> easy and low-risk; it is just a matter of equiping EditPositionDone()
<br>> with a Boolean argument fakeRights, and putting an
<br>> if(fakeRights) { ... } around the castling-rights code.
<br>> It is called quite a few times, though, and all except the last call
<br>> should be with argument value TRUE.
</div><br>should be relatively easy... as an alternative I could also just add the
<br>winboard sources and put a tar-ball with the winboard source up for
<br>download without any other modifications and we just don't change
<br>version numbers yet. Or we get just test your refactoring patch to
<br>include it too in 4.4.2 ;)
<br><br>What does everyone else think about those three options?
<br><br>Anyway, it will have to wait until tomorrow or Sunday until I will have
<br>time to do it.
<br><br>ARUN
<br><br><br><p>From forum: <a href="http://old.nabble.com/Gnu---XBoard---Devel-f36958.html" embed="fixTarget[36958]" target="_top" >Gnu - XBoard - Devel</a></p>tag:old.nabble.com,2006:post-26233030Re: WinBoard sources missing2009-11-06T06:34:44Z2009-11-06T06:34:44Zh.g. muller<br>>n that case we could also just call it 4.4.2 ;) 4.3.x went up to 16?
<br>>and I don't think that we will get a lot more than that and even if we
<br>>would it would be ok... no real reason to save version numbers...
<br><br>OK, I am in favor of an immediate 4.4.2 release, then.
<br>Problem is that I submitted the patches in the wrong order,
<br>as I discovered the bug I introduced in the FEN pasting
<br>only when doing the refctoring of e.p. and castling rights.
<br>I would prefer that refactoring to go into a beta version,
<br>and not dump it completely untested in a "stable release".
<br><br>Is there any easy way for you to invert the order of patches,
<br>when they are to the same file? Solving the bug is reasonably
<br>easy and low-risk; it is just a matter of equiping EditPositionDone()
<br>with a Boolean argument fakeRights, and putting an
<br>if(fakeRights) { ... } around the castling-rights code.
<br>It is called quite a few times, though, and all except the last call
<br>should be with argument value TRUE.
<br><br>Should I make a seprate version of the 4.4.1 backend.c / backend.h
<br>that has just this patch?
<br><br><br><br><p>From forum: <a href="http://old.nabble.com/Gnu---XBoard---Devel-f36958.html" embed="fixTarget[36958]" target="_top" >Gnu - XBoard - Devel</a></p>