about using winboard

[hgm]

A separate "edit position" dialog would probably be my preference

Like in Shredder:
http://www.maclife.de/testcenter/spiele ... dder-chess

This duplicates the board, so that it doesn't matter that the dialog covers the original one. I don't really see what is gained by this. If there is room for the piece pallette next to the board, it would have been possible to display a dialog that shows just that, and leave the original board uncovered. It would look exactly the same to the user. Is the trick here that the board in the dialog is much smaller than the board in the main window?

For Winboard, it would probably make sense to add a combobox to select the chess variant because that decides which pieces are available.

That doesn't seem really needed; when people are working with a certain variant, they tend to stick with it. So any dialog can pop up with the current variant in mind, leaving variant switches the exclusive domain of the New Variant dialog. The chances that someone would want to switch variant at the same time as setting up a position are minute.

The peoblem with variants is more that some variants have more pieces than others, and that a dialog like Shredder's don't look so nice anymore in Chu Shogi, where there would be 2 x 36 piece types next to the board.

A proper dialogue would also get around the "click clock" hack which has exactly one reason: the clocks occupy space in the main window that is never part of any square.

Not sure what you want to say there. The clocks indeed serve no function in Edit Position mode, and the space they take up could thus be repurposed for other functions.

[Evert]

What do you mean by 'primary' and 'secondary' click? Is that left and right mouse button?

Sort of. I guess it's Apple-speak.
The "primary" click is indeed normally the "left" (formerly only, on a Mac) mouse button. The "secondary" click is normally the "right" mouse button, but on a Mac is can also be option-click (and usually was back when there was only a single button). In the case of a trackpad, it's a click on the left or right-side of the pad.

This is one of the (first) things I tried, and it did not work nice at all. Because of the problem you mention; the extra dialog tends to eclipse parts of the board where you want to place pieces. And even if a place can be found for it where it would not eclipse anything, this then tends to make the distance you have to travel between grabbing a piece and placing it unnecessarily large. It was really annoying.

This is what drove me to an 'internal' piece palette, where the pieces you want to select for placing are already on the board itself, much closer to were you actually want them.

Well, there is of course no problem in having an alternative. Certainly, being able to drag pieces around the board or adding them by right-clicking is a great addition. It would just be nice if there were an external palette window as an alternative (which could then also have options for castling, holdings, N-check and whatever other state is pertinent to the current variant; perhaps convenience options like mirror/flip the position would be nifty).

There of course is still some eclipsing in the sense that the pallette pieces are now on squares where you might want to place other pieces, but in practice this is very rare. The large majority of chess positions have pieces on the back rank only because they were never moved, and still in their original location. Except for (Q-side) castling, but it feels quite natural to just place the pieces that start between King and Rook first. It hardly ever happens that a group of pieces needs to be permuted cyclically from where they start initially.

I guess that depends on your workflow and how you think about the position. It annoys me when I have to think about the order in which I have to place pieces by moving stuff I don't want out of the way first, because I want to place pieces for the main idea first.

The modifier key had not occurred to me yet, but sounds like a very good idea: Shift + rightClick (or middle click) to 'decrement' the piece type. Which with sweep selection is possible by sweeping in the upward direction, to immediately access the black pieces.

What do you mean by 'switch side'? Color-flip the clicked piece? Shift + right-click initially already places a black Pawn instead of a white one.

Yes, that is what I meant.

I am not sure why you make the destinction WinBoard/XBoard here.

They have distinct frontends, right?
So implementing it in XBoard would not add it to WinBoard without more work and vice versa.

Now that XBoard has reached, and perhaps even surpassed WinBoard, this is indeed not a totally crazy idea. One drawback is that to use GTK and the Cairo plot library on Windows you would need dozens of megabytes in libraries, killing the light-weight character for which I like WinBoard so much.

Well, XBoard (GTKBoard?) for Windows could be a separate entity from WinBoard proper.
It means that if something is fixed/added to XBoard (scalable pieces, for instance), people can get that in Windows, but at the price of using XBoard rather than WinBoard.

I'm not entirely sure if that isn't in some sense a step backward, however: you're going from WinBoard on Windows and XBoard everywhere else, to XBoard everywhere and WinBoard as an alternate option on Windows.

[hgm]

Well, there is of course no problem in having an alternative. Certainly, being able to drag pieces around the board or adding them by right-clicking is a great addition. It would just be nice if there were an external palette window as an alternative (which could then also have options for castling, holdings, N-check and whatever other state is pertinent to the current variant; perhaps convenience options like mirror/flip the position would be nifty).

What is in your opinion the advantage of a static palette dialog over one that pops up for each square? I only see disadvantages. Finding a good place for it to pop up is problematic due to board eclipsing, and that it might depend on where the main window is located on the display, and at best forces you to put it far away from where you eventually want to drop the piece. A dialog that just pops up for an already indicated square can pop up with the mouse pointer at its center.

Is the problem that is especially difficult to produce a right-click on a Mac touch pad? The -monoMouse configuration option would do away with the right-clicks altogether, so that you could summon the piece menu by left-clicking on an empty square. Drawback is that you can no longer move empty squares, and no longer drop new pieces on top of existing ones, but these seem things that would not really be needed.

Also note that the current method does allow controlling of e.p. and castling rights: pieces start virgin when dropped on their usual starting square, and the virginity of Kings and Rooks can be toggled by clicking them when they are already selected. For Pawns this would toggle the e.p. right for capturing that Pawn (which starts off). The message field will display a text to indicate whether you just turned the rights on or off. Other piece types still exhibit the old behavior (disappearing on the second click, by 'capturing themselves'). I am not sure that this is ever useful, so granting rights could be extended to those too, in variants like Seirawan Chess.

They have distinct frontends, right?
So implementing it in XBoard would not add it to WinBoard without more work and vice versa.

Ah, OK, you were specifically talking about adding a dialog. (But if I thought this would be worth having, I would likely implement it for both.) I was still thinking along the lines of board behavior, which would automatically be the same.

For example, there seems no advantage to actually popping up a new dialog to provide piece images for the user to click on. There would for a text-based piece menu, but piece images can just as conveniently be shown on the board itself. Right-clicking a square could select that square for dropping, and at the same time switch the board display to one with 12 different colored piece types on its center squares (as a 3x4 or 6x2 array), blacking out all other squares. After which a click on any of those would drop that piece on the preselected square, switching back to displaying the position. While clicking on a blacked-out square would act to cancel the drop.

This is easy to adapt to variants, as I don't think there is any variant where the board would not be large enough to hold all (colored) piece types. And this would be a back-end change, working in both WinBoard and XBoard alike.

Well, XBoard (GTKBoard?) for Windows could be a separate entity from WinBoard proper.
It means that if something is fixed/added to XBoard (scalable pieces, for instance), people can get that in Windows, but at the price of using XBoard rather than WinBoard.

Sure, there would be no reason to abolish WinBoard. But running XBoard under Windows has been possible already since I first came back to computer Chess. Even for the Xaw build. Through Cygwin. Of course at that time XBoard was so primitive and ugly that it made no sense to do that. But it worked, and it should still work. I suppose nowadays there are other GTK implementations available for Windows that could be used as well. I just never tried that. But thre is no reason why others could not try that.

[Evert]

What is in your opinion the advantage of a static palette dialog over one that pops up for each square? I only see disadvantages. Finding a good place for it to pop up is problematic due to board eclipsing, and that it might depend on where the main window is located on the display, and at best forces you to put it far away from where you eventually want to drop the piece. A dialog that just pops up for an already indicated square can pop up with the mouse pointer at its center.

As a user, figuring out where to pop up the window isn't my problem. Presumably, the first time I opened it, it appeared in some quasi-sensible location, and I may have dragged it to where I want it in the future (say, to the right of the board on top of the analysis window, which I don't need if I'm editing a position). I expect it to reappear there.
The main advantage over a pop-up menu, for me, is that to select a piece, I can move the mouse to a particular static target. To select an item from a popup menu, I need to first open the popup menu (which feels like an extra action), then scroll to a target I hadn't seen yet to select it. If I don't know where in the popup menu the piece I want is going to appear, I need to locate it after the menu pops up. Conversely, when moving in the general direction of the palette, I can visually identify the target while moving the mouse over there.
Psychologically, I need to "wait for the popup menu to appear" after I click, whereas I don't need to do anything to make the palette appear.

I guess my ideal interface would:

• Allow me to drag pieces around on the board
• Allow me to quickly change piece type on a square using the type of (modifier)+click+drag that is already in place/similar to what was discussed
• Offer a context menu if I want it
• Give me a palette to drag pieces from

So that's a bunch of different ways to select a piece, but the one that would be most convenient is situational (and up to personal preference of the user).

Is the problem that is especially difficult to produce a right-click on a Mac touch pad?

It's not the right-click perse, it's right-click+drag that is annoying for me.
Well, a right-click has me pressing down the right side of the trackpad. I use my thumb to do that, which isn't particularly difficult, but it requires me to bend my thumb under the palm of my hand (whereas I stretch it to the side for a left click), which then makes it awkward to subsequently drag (my thumb limits the mobility of the rest of my hand).

Paying attention to it, I seem to have an interesting combination of fingers to do things. I use my middle finger to move the mouse pointer, index+thumb to drag, middle+ring to scroll.

The -monoMouse configuration option would do away with the right-clicks altogether, so that you could summon the piece menu by left-clicking on an empty square. Drawback is that you can no longer move empty squares, and no longer drop new pieces on top of existing ones, but these seem things that would not really be needed.

I remember trying that out and not liking it much, but I don't remember why. It may be what you say: losing the ability to drag empty squares or drop pieces on top of other pieces sound like the sort of things that would annoy me.[/list]

[hgm]

As a user, figuring out where to pop up the window isn't my problem. Presumably, the first time I opened it, it appeared in some quasi-sensible location, and I may have dragged it to where I want it in the future (say, to the right of the board on top of the analysis window, which I don't need if I'm editing a position). I expect it to reappear there.

Well, it would become a user problem if it appeared in unpredictable locations. Reappearing in the same place (relative to the board) might not be possible, because the window is in another absolute screen location than the previous time.

The main advantage over a pop-up menu, for me, is that to select a piece, I can move the mouse to a particular static target. To select an item from a popup menu, I need to first open the popup menu (which feels like an extra action), then scroll to a target I hadn't seen yet to select it. If I don't know where in the popup menu the piece I want is going to appear, I need to locate it after the menu pops up. Conversely, when moving in the general direction of the palette, I can visually identify the target while moving the mouse over there.
Psychologically, I need to "wait for the popup menu to appear" after I click, whereas I don't need to do anything to make the palette appear.

You are right. I just tried it again (with a pseudo-popup) and it is awful. This is why I wanted to get rid of the pieceMenu, and introduced the sweep selection instead. I just had forgotten how awful it was.

I guess my ideal interface would:

• Allow me to drag pieces around on the board
• Allow me to quickly change piece type on a square using the type of (modifier)+click+drag that is already in place/similar to what was discussed
• Offer a context menu if I want it
• Give me a palette to drag pieces from

So that's a bunch of different ways to select a piece, but the one that would be most convenient is situational (and up to personal preference of the user).

This seems a bit over-doing it, for a feature that would be rarely needed in the first place. And the 'internal palette' causing a collision problem that makes it different from an external palette even more rarely.

It's not the right-click perse, it's right-click+drag that is annoying for me.

Well, for the context menu you would not have to drag with the right button pressed. But I guess the context menu is out for other reasons.

I remember trying that out and not liking it much, but I don't remember why. It may be what you say: losing the ability to drag empty squares or drop pieces on top of other pieces sound like the sort of things that would annoy me.

You use that often? I always had the impression that it was sort of a bug that this works in the first place... Dragging a piece off-board is usually not more work. Normally you would only need to delete pieces when you started from the palette position, and the position did not use some piece types. But then they are always on an edge square. Capturing all pieces you don't want with a piece you do want, before bringing that to its desired location is also not more work than using an empty square for it.

My main objection against a palette dialog is that in some variants it would become unweildly large. I hate solutions that do not work for all variants.

[hgm]

I got an interesting idea for an alternative setup mode. The disadvantages of an internal palette compared to an external one is that piece types you did not need do not automatically disappear when you leave setup mode. And, depending on how the external palette is implemented, that you need an explicit selection for every piece you want to place, instead of just doig multiple clicks that automatically save the same type. (But the piece to reselect will always be under your mouse pointer already, so this is not such a big deal.) This has to be made up for by shorter average dragging distance and more pieces that 'accidentally' start in the desired place, so that you neither have to move nor delete them.

I can conceive a setup mode that uses 'select once, place many" for an internal palette too, however:
* right-click on a piece => piece disappears, and type gets selected
When a piece type is thus selected:
* left-click occupied or empty squares => selected type is put there
* right-click on empty square => deselect the current type
When no piece type is selected:
* left click on a piece grabs / selects the piece for moving
* right-click on an empty square pops up an explanatory note

Advantages to the currently implemented method are that it is (1) easier to remove palette pieces for unused types (just a single right-click), as they disappear as a side effect of their selection. And (2) that you can place multiple pieces of the same type without reselecting the type.

In addition there are more opportunities for improving the discoverability: after a right-click a message "left-click places knight" (or whatever), which would even be useful feedback to users that do know how it works, because it gives feedback on the selected type. (But this would raise the problem how to name fairy pieces; I guess "fairy NUMBER" would be an acceptable start, though.) Right-clicking on an empty square, which has no function in this scheme, even offers opportunity for an elaborate explanation plus other functionality. So that a right-click would always do something, which is good for users who expect context menus. The explaatory note could actually be somewhat like a menu, in that in addition to the message it could contain a number of buttons. E.g. to materialize a certain piece type in the clicked empty square, to clear the board, etc.)

[Fulvio]

I can conceive a setup mode that uses 'select once, place many" for an internal palette too, however:
* right-click on a piece => piece disappears, and type gets selected
When a piece type is thus selected:
* left-click occupied or empty squares => selected type is put there
* right-click on empty square => deselect the current type
When no piece type is selected:
* left click on a piece grabs / selects the piece for moving
* right-click on an empty square pops up an explanatory note

Do you remember the clock example where everybody else calls it "clock" and you decide to be innovative calling it "bell"?
Have you at least checked how other do it before inventing elaborate sequences of left/right clicks where the meaning of a click change every time?

Left-click place the current-piece, but only if the square doesn't already contains the same piece; in that case it is removed.
Dragging a piece will also selects it as the current-piece (beside moving the piece), a piece dragged outside the board is removed.
On ChessBase right-click place the current-piece with the opposite color (but I don't like it).
Don't forget that you have also to show somehow what the current-piece is.

If you have a Windows machine there is a free ChessBase Reader that you can try (open a new board and press <s>).

If you have a recent Debian based system you can try it in SCID:
sudo apt-get install scid
(click on the 3 lines under the board, click the pen icon, click set up the board)

[Evert]

I would suggest using ctrl/cmd+drag to copy a piece instead of moving it. This is equivalent to how it works with files and thus more familiar.

[hgm]

Have you at least checked how other do it before inventing elaborate sequences of left/right clicks where the meaning of a click change every time?

Not exhaustively. But solutions used by others are usually not really good for WinBoard, because the requirements are more severe. E.g. having an external palette is truly problematic when 72 (colored) piece types would have to be displayed next to the board. Not only for the designer to find space for it, but also for a prospective user, to actually find the icon of the piece he needs in the palette.

Left-click place the current-piece, but only if the square doesn't already contains the same piece; in that case it is removed.

This seems to exclude that you can select/grab pieces (of a new type) for moving.

Dragging a piece will also selects it as the current-piece (beside moving the piece), a piece dragged outside the board is removed.

This could indeed be useful if dropping the selected piece would be limited to empty squares. In fact it would then be a generalization of click-click moving: first click selects, subsequent click on empty moves that piece there, (i.e. removes the originally selected one), subsequent clicks on empty would drop more pieces of the same type. Until you click an occupied square, which would then select a new piece for moving. The first click after selecting a new piece could even be exempt from the rule that drops only work on empty squares, so that you could use it to capture other pieces.

You would lose the possibility to move empty squares. Which IMO doesn't really hurt, as you can remove pieces by draggig them off board, rather than capturing them with an empty square. So it is only a problem for dragging empty squares off board (to create a hole). But I suppose you can always do that before any piece got selected.

This basically does away with the use of the right button completely: selecting a type for dropping, which was the only function in the propsed scheme, has now become an automatic side effect of moving the pieces. The price is that you can no longer drop in an occupied square, replacing the piece there; before left-vs-right determined whether you wanted to replace or to select, and now you can only select. But replacing pieces should only be necessary if you goofed before, putting something where it did not belong. Removing pieces would have become more difficult, and can no longer be done in a single click. I am not entirely happy with that.

Don't forget that you have also to show somehow what the current-piece is.

Sure, I used the message field (the text line above the board) to show that.

If you have a Windows machine there is a free ChessBase Reader that you can try (open a new board and press <s>).

OK, I tried that, and my first impression was that it was pretty awful.

If you have a recent Debian based system you can try it in SCID:
sudo apt-get install scid
(click on the 3 lines under the board, click the pen icon, click set up the board)

No luck there yet, it seems this is not in the repository of my Ubuntu version (404 errors when it actually tries to get the packages).

[hgm]

I would suggest using ctrl/cmd+drag to copy a piece instead of moving it. This is equivalent to how it works with files and thus more familiar.

That was still included in the package. Plus the keyboardless way of grabbing with a double-click. The 'context popup' I had was this:



Some buttons could be added at the bottom for 'Clear Board', 'Start Position', and 'Piece Palette'.

Basically everything is left as it was, except for the way right-clicks work. Before there was a choice between the piece menu (for XBoard only working in the Xaw build) and sweep selection. This is a third mode, where right-click is used to 'take a piece in hand', from where you can then drop it multiple times.

The thing I am not sure of is how to best treat an attempt to drop on an occupied square. Should the drop succeed, or should this be treated as automatic termination of the multi-drop series, and select the clicked piece for moving? Now that I think about it, it seems the latter is better. It would simplify matters because an explicit termination of the multi-drop (for which I used right-click on empty) is no longer needed. And it makes the behavior of left-clicks more uniform across modes: it always grabs the piece (if no from-square was selected, and because selecting a piece for multi-drop removes it, no from-square is highlighted during multi-drop). Only the effect of 'from-clicks' on empty squares has changed, but in no other mode can you grab empty squares anyway. Selecting empty squares was only useful for obliterating pieces, and a right-click is now a faster alterative for that.