On Sun, Feb 16, 2014 at 11:57:48PM +0100, h.g.muller wrote: > Op Zo, 16 februari, 2014 12:53 pm schreef Yann Dirson: > > > > I wouldn't think so, since during the game arrows ane pieces were > > drawn at the same place, and the dot was even drawn on top of pieces IIRC. > > > OK, that is very significant. Such dots are drawn on squares for which the > corresponding element of a board-size array 'markers' is non-zero. Did you > also see other such dots appear on other squares to indicate the moves of > the piece you ppicked up, during the game? Normally it would clear the > entire array 'markers' every time the user releases a piece on its > destination square, and it should not be possible for a stray dot to > survive that, no matter what caused it to appear in the first place. > (Unless it would be caused by some out-of-bound access elsewhere, that > happened again and again on every move.) Unless it would never draw the > dots because the option is off, in which case it would also never erase > them.
I could only see the dots for the pieces I selected prior to launching two-engine mode. If I attempt to select one while the engines are playing, existing dots are removed, and (correctly) no new dot is drawn. Looks like it is just the list of dots that should be cleared when an engine is assigned a side. > > Oh I see. It does work, although it is affected by the lack of tile > > resize I already noticed, so "xboard -fcp shogi" shows a shogi board with > > the bottom row off-screen. > > > "xboard -fcp gnushogi", I presume. I will address the sizing problem. Right :) > > Wouldn't it be easier to just drop an "OrientalChu" file in an > > xboard.conf.d/ dir, so that installing a new theme does not require running > > xboard ? > > One reason for running XBoard for this is that the engine or theme package > might not know where to find the XBoard data files, or even its .conf > file. Their location depends on whether XBoard was installed from source > or as binary package. Issuing XBoard as a command would by definition > invoke the currently active XBoard. OK. OTOH, "make install" is also often run as root, and the less stuff you run that way, the safer you get. Calling xboard to request the paths to be used could be done at configure time (typically *not* run as root), together with substitutions to conf files if needed (although ~~/ probably makes it unnecessary). Then "make install" would just use those pre-specified paths. > > It would also have the nice property that, when xboard ships a new > > xboard.conf, it does not overwrite the previously-added themes. > > Indeed, this is a problem I had not thought of yet. If themes are to be > dropped as individual files, we might as well drop them in ~~/themes/conf, > where the chu and shogi files are dropped now already. It would require > XBoard to run through the contents of this directory in addition to > reading its master settings file every time it is launched, however. But then it would have to distinguish between those meant to be specified through @preset and those to be unconditionally read. And since they are really confs, as opposed to presets, they are much better located in /etc/. > For engines we could do the same, in another directory. Actually I think > this is a problem that transcends XBoard, as engines are also usable by > other GUIs. There are plenty of GUIs that support XBoard protocol or UCI. > So IMO there really is need for a standardized way for engines to announce > themselves. E.g. in Debian the directory /usr/games/engines/cecp could be > used for engines that support CECP, and /usr/games/engines/uci for engines > that support UCI (and .../usi for Shogi engines that support USI, etc.) > Engines could then drop a file there with some essential information, like > the variant(s) they play, and the command for starting them, and perhaps > some extra, protocol-specific info (like for CECP whether they use v1 or > v2 of the protocol). All GUIs could then draw on that information, by > looking in the directories for the protocols they support. It's not that easy, as not all engine requires the same information. However, I guess that could be done with little effort using the debian "menu" framework - it is, however, specific to Debian and derived distros, so it would probably count as "not generic enough". The idea is that packages that need to announce themselves just drop a file in /usr/share/menu, describing what they declare (eg. here needs="XBoard"), and the various parameters. On the other side, consumer packages (for menus, that's window managers, taskbars and the like, including an XDG backend generating .desktop files) provide a kind of script that will generate their config file(s) from the provided data. In Omaha I have opted for .desktop files, describing plugins in a more generic framework (also used to describe game, themes, etc). But the framework could be easily adapted to other formalisms (support for Zillions rules are on my todo list, albeit near the end of it ;) Best regards, -- Yann -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org