phhnguyen wrote:Just see a strange thing (bug?) when working with XBoard.
There indeed seems to be something strange going on here. One source of trouble is that the diagrams are not just ordiary comments to XBoard, but are recogniszed as a special syntactical unit 'PositionDiagram'. Such a unit is considered a game starter, like a move number 1, or a PGN tag. XBoard understands also other game-file formats than PGN (in particular the files that used to be saved by GNU Chess, and an old XBoard save format), and I thinkin one of these formats games start with such a PositionDiagram.
This explains why the game has no moves; the second diagram ends it before any moves are seen.
What is not clear to me is why XBoard doesn't consider this a multi-game file, and does not open the Game List to select one of the two games. I will try to figure it out.
No, my laptop is used for both office and home. I use my name as computer name thus other people can easily recognise it.
BTW, can a moderator (Muller?) help me to remove those ip in my above post please? I cannot edit it anymore and don't want those info's kept here forever. Thanks
Making XBoard more pedantic during position setup would make it less useful for variants. E.g. it is conceivable that there would be a Xiangqi variant that does not have a Palace and River, where every piece could go anywhere. It could also be annoying when you are moving pieces around on a crowded board that you cannot temporarily park them wherever you want.
So currently there is indeed never any restriction to what you can do in Edit Position mode in any variant. (E.g. in Chess you can place multiple Kings, no Kings, Kings in check, more than 32 pieces, Pawns on 1st and 8th rank, etc.) It is left up to the engine to accept or reject the position.
Of course the mentioned drawbacks of strict checking could be ameliorated by making it dependent by only doing it when testLegality is on, and when the user wants to leave Edit Position mode. It doesn't seem much of a problem in practice, however.
As for the way to place pieces: XBoard has two modes for this, controlled by the option -pieceMenu true|false. But in the GTK build the (deprecated) menu is not yet implemented. The default setting (without piece menu) creates a piece in a square that you right-click; the piece type can be selected by moving the mouse vertically with the right button pressed, and releasing the button when you see the desired piece. The Shift key decides if you start with a white or a black Pawn on mouse-button press. (Actually it is decided by whether you press the right or middle button, but most mouses nowaday do not have a middle button, so the Shift key is used as a general method to swap the functions of right and middle.)
I understand that on the Mac you don't even have a right button. XBoard has an option to adapt to that, -monoMouse true|false. Setting it makes XBoard interpret a click on an Empty square in Edit Position mode as a right-click, and on an occupied square as a left-click.
But in this mode a faster method is usually (if the board is not very empty) to click on the active clock two times, to first clear the board, and then conjure up a position with every piece type only once. (Clicking on the inactive clock makes it active, for setting the side to move.) You can then drag pieces you don't need off the board to remove them, drag pieces you need once to the desired square, and 'clone' pieces you need twice or more by dragging them to new squares with the Ctrl key pressed. That copies the piece rather than just moving it. That way you never have to create a piece 'from scratch'.
hgm wrote:
As for the way to place pieces: XBoard has two modes for this, controlled by the option -pieceMenu true|false. But in the GTK build the (deprecated) menu is not yet implemented. The default setting (without piece menu) creates a piece in a square that you right-click; the piece type can be selected by moving the mouse vertically with the right button pressed, and releasing the button when you see the desired piece. The Shift key decides if you start with a white or a black Pawn on mouse-button press. (Actually it is decided by whether you press the right or middle button, but most mouses nowaday do not have a middle button, so the Shift key is used as a general method to swap the functions of right and middle.)
I understand that on the Mac you don't even have a right button. XBoard has an option to adapt to that, -monoMouse true|false. Setting it makes XBoard interpret a click on an Empty square in Edit Position mode as a right-click, and on an occupied square as a left-click.
Macs don't have any mouse buttons.
They just have a massive trackpad that you can press down on - but it does distinguish between the left and right side of the trackpad when doing so. So yes, you do have a "right button" on a Mac (since 2008 or so, I think).
The main issue isn't the need for a "right button", it's that dragging with the right mouse button is cumbersome if the button is also the trackpad. This is true of both right- and left-click dragging, but more so with right-click dragging if you're right handed. At least in my experience (I click with my thumb, which gets folded awkwardly underneath my hand if I have to do it on the right side of the trackpad; not a problem if I can let go immediately, but seriously annoying if I need to hold it there).
It does sound a bit similar to what I have on my Asus laptop. But there pressing the pad only counts as a right-click if I press in the lower-right corner. I also do this with my right-hand thumb. But this doesn't cause any particular hindrace for moving the pointer with my index finger of the same hand. Is the problem that you have to press much higher on the pad?
Using the palette board and Copy/Move makes it hardly ever necessary to create pieces from scratch anyway. Only if you accidentally overwrite ('capture') one that you needed, and it was the only of its kind.
Perhaps I should make it that repeated right-clicking on the same square would cycle through all piece types there? This would conflict with the monoMouse idea, though, because after the first creation the square would be no longer empty, and a click would count as a select click. Of course it is rare that you would first create a piece somewhere and then immediately want to move it; for this reason created pieces are not left selected. So in monoMouse mode a click on the piece created with the previous click could be made an exception to the rule that clicks on occupied squares are left-clicks, and be used to 'upgrade' the piece (again counting as piece creation, so you can repeat it). There could even be a time-out on this, making it only work if the previous 'creation click' was less than (say) 250ms ago. Would that be a good solution?
hgm wrote:It does sound a bit similar to what I have on my Asus laptop. But there pressing the pad only counts as a right-click if I press in the lower-right corner. I also do this with my right-hand thumb. But this doesn't cause any particular hindrace for moving the pointer with my index finger of the same hand. Is the problem that you have to press much higher on the pad?
No, when I do it my thumb just makes a really awkward angle compared to my index finger. I have fairly long fingers, perhaps that makes a difference? Or an ARBO inspector would get a heart attack if they see the way I sit at a computer.
Perhaps I should make it that repeated right-clicking on the same square would cycle through all piece types there? This would conflict with the monoMouse idea, though, because after the first creation the square would be no longer empty, and a click would count as a select click. Of course it is rare that you would first create a piece somewhere and then immediately want to move it; for this reason created pieces are not left selected. So in monoMouse mode a click on the piece created with the previous click could be made an exception to the rule that clicks on occupied squares are left-clicks, and be used to 'upgrade' the piece (again counting as piece creation, so you can repeat it). There could even be a time-out on this, making it only work if the previous 'creation click' was less than (say) 250ms ago. Would that be a good solution?
Well, I would probably find that preferable (actually I like a palette with available pieces+keyboard shortcuts best, but that's another discussion), but I'm not everyone.
Problem is that the board window does not really have room for a palette. The palette can get very large in some variants, and locating it in a popup window causes very annoying eclipsing of the board. This is why I went to an 'in situ' palette that you can call up through the clocks. That doesn't seem to be really inferior to a popup palette that would automatically disappear after selection.
I have pushed a patch now to hgm.nubati.net that interprets multiple right-clicks on the same square as a signal to cycle through the available pieces on that square. This even works in -monoMouse mode, as a click on a just-placed piece will be interpreted as a right-click there, as the only exception that clicks on an occupied square are interpreted as left-clicks.
Note that when you have a right mouse button, but it is difficult to operate, -monoMouse can also be a very handy option. Because touch pads allow you to make the left-click by tapping on the pad in any location you like. And doing the sweep select that way doesn't seem very cumbersome, if the number of piece types is reasonable. (E.g. Wa Shogi is problematic.)
