On Sat, Feb 15, 2014 at 10:57:20PM +0100, h.g.mul...@hccnet.nl wrote: > Op Za, 15 februari, 2014 9:44 pm schreef Yann Dirson: > > First a new small bug: have hachu played a full Chu game, probably > > after having selecting a white piece, and noticed that the dot stayed there > > till end of the game: http://imagebin.org/293529 > > OK, this is a dot from the 'Show target squares' option, that apparently > was not properly erased. This is always a bit tricky, because it can be > that it is actually erased on the board, but that the corresponding expose > event to actually update the display was never performed. (A check for > that is to flip the view, because that redraws the entire board. But I > guess it is too late for that now.)
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. > It would be helpful to know if you were playing with legality checking on > or off: when it is on XBoard itself marks the target squares with dots > when you 'lift' a piece, drawing on its internal move generator and rule > knowledge, while when it is off it follows the instructions sent to it by > the engine for marking the squares (and HaChu uses that). So it seems I have legality checking on by default with @chu, but not with @shogi. I assume GNU Shogi misses the necessary support. > It would also be helpful to see the entire game, and know the moment when > this dot first appeared. (Presumably when a piece was lifted that could > move to that square.) Or was the dot there already when the game started? The dot was there at first. I must have clicked on one piece or 2 to show my son how things worked, then started two-machines mode with the dot still displayed, and it stays here as the engines start to play. Easily reproducible, in fact. > > > > I see. However, the problem of giving easy access to all those > > GUI-only users not willing to dive into manpages to discover that, > > will still be there. > > > When the engine sends the 'setup' command, the user would not have to > worry about rule knowledge. And I think I also made it such that when an > engine does not report it plays variant normal of fischerandom, that > XBoard would automatically switch to the variant that the engine does > play. 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. > That leaves setting the theme. The various theme 'components', such as > pieceImageDirectory and square background textures or square colors can > already be set through the GUI, but it is a bit inconvenient that he would > have to set all aspects separately. In WInBoard I solved this by adding a > View->Themes dialog, very similar to the Load Engine dialog. (Cloned from > it, in fact.) The idea is that the user sees a list of theme names where > he sees engine nick-names in Load Engine, and can select those by clicking > them. A theme (like an engine) is a line in a multiline option stored in > the settings file (-themeNames in stead of -firstChessProgramNames). The > line consist of a sequence of XBoard options, processed as if they formed > a command line when the user selects that theme. The rest of the dialog > contains controls to set options that define the theme (basically what is > now in the View->Board dialog), plus a text entry for the 'theme name' > that is initialized empty. If the user uses the dialog not to select an > existing theme but to modify individual settings, XBoard would just > implement the new settings on 'OK'. But if he provided also a theme name, > the combination of settings would forget into a line, and added under the > given name to the list of themes, so next time he can recall it with a > single click. > > I recently added a new class of options to XBoard (of which -installEngine > was the first representative), which would add their value (a text string) > as a new line to the end of a multi-line option (-firstChessProgramNames, > in this case). I could make another such option, -installTheme, which > would add to -themeNames. This could be used to make newly installed > themes automatically appear in the theme list of all users, by in the > install script of a theme package write the command > > xboard -addMasterOption {-installTheme '"Oriental Chu" -pid ~~/themes/chu > -lightSquareColor #FFE040 -darkSquareColor #FFE040'} -autoClose > > which then would add the line > > -installTheme '"Oriental Chu" -pid ~~/themes/chu -lightSquareColor #FFE040 > -darkSquareColor #FFE040 -variant chu' > > at the end of the xboard.conf master settings file, so that every future > user would get to see it, and get the line > > "Oriental Chu" -pid ~~/themes/chu -lightSquareColor #FFE040 > -darkSquareColor #FFE040 > > added to his -themeNames list, so he could select it with a simple click. > Basically the line to be added contains the same as what is now in the > conf files like ~~/conf/chu, except on a single line. 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 ? It would also have the nice property that, when xboard ships a new xboard.conf, it does not overwrite the previously-added themes. Debian has support for warning the admin when upgrading, and offer her to select one to keep or to go for manual merge; or we could add an update-xboard-conf command to reconstruct ourselves xboard.conf each time xboard.conf.d/ has changes; but it just makes things unnecessary complicated in this case. > > Hm, with today's large screen sizes, it's not very friendly to require > > keeping a small window. What about using SVG there instead ? > > > > The texture become rather ugly on sizing, when they are SVG. A better > solution would be to simply provide a very large board bitmap. For en > even-colored board, this compresses to almost nothing, but for the plywood > default theme it might be several MB. But that still isn't a big deal, > nowadays. Especially if it comes in a separate Xiangqi thema package, > which doesn't bother the 99% of the users that don't even know what > Xiangqi is. The reason of the current modest size is that I did not want > to bloat the XBoard package with stuff almost no one uses. What about making the board a composition of a plywood non-resized texture in a single file, and resized SVG drawings on top ? > > Or maybe provide a launcher to select theme/rules/engine and run > > xboard with proper options, at least until those are made selectable from > > within xboard itself ? There are tools to help for this (remember seeing > > new packages in Debian for this months if not years ago), but I can't find > > the right keywords to find them again. > > > > Well, WinBoard has such a launcher (actually part of it), known as the > Startup Dialog, where you can select engines from pull-down menus. I have > always hated it, because I felt that these things should have been > possible any time during a run. Which for engine-selection they now are. > In combination with an -installTheme option having a theme-selection > listbox in the View -> Board dialog seems the best option. I don't think > it would be too difficult for the average manualophobic user to find it. Sounds good > > Right. Maybe a more user-friendly message would be enough, and you > > could keep the detailed reason for -debug ? > > > > Well, the reason for the user-unfrinedly message you saw now is basically > that HaChu is non-compliant. It does announce the variants (and it should, > because they are officially-defined and supported variants in the WinBoard > Alien Edition, under which it can play them, or at least Dai and a > crippled version of Tenjiku). But according to the standard version of > XBoard they are non-standard, and so now interpreted as engine-defined > variants. But the engine does not send a setup command for them when they > get selected, so XBoard is really totally in the dark as to what these > are. When I make HaChu send the setup commands (which would not hurt the > Alien Edition, which would just ignore them, as there it is not an > engine-defined variant), XBoard could give a more detailed error message. > (Probably the setup command would define it as 15x15+0_dai, and since > standard XBoard doesn't know Dai, the error I could let it print would be > 'parent variant unknown, switching back to previous variant'. > > Still not very elegant. Another solution would be to recognize all > standard variants define in the Alien Edition protocol (checkers, go, > reversi, amazons, dark, multi, alien, dai, tenjiku, dada, maka, tai), and > ignore those, rather than thinking they are engine-defined variants. So no > buttons would be created for them, and a user could not select them. Then > at least you would not have these problems with engines that were > originally intended for the Alien Edition (such as HaChu). That would require updating xboard-compatible engines every time a new variant gets added to the Alien Edition - quite ugly too :) What about rather changing Alien Edition to recognize an alienvariants feature instead, so it does not interfere with standard xboard ? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org