How about this WinBoard look?

[hgm]

I always liked the flexibility the separate windows offer. It allows me to only open those windows I of interest for the thing I am doing. And not forcing the overall outline to be rectangular allows you to embed external applications in the layout as well (PSWBTM, task manager).

E.g. when I was playing last week in the on-line blitz tournament, I had veritcally divided my screen in three: the two right-most sections were for the Chess boards of micro-Max and Joker, respectively, and in the left-most section I had the two engine-output windows above each other. Below all that I had two ICS interaction windows, that I wanted to be very wide (full screen width), but did not need too many lines.

No way I could have fitted all that info on one display if it had to be presented as two identical rectangular areas, one for uMax, the other for Joker!

[Zlaire]

Yeah different taste I guess. I guess I want it like that since I want to be able to move all the windows at once if needed.

Perhaps a 'lock window' feature that forces two or more windows to stay connected even if one of them are moved.

Just my opinion of course.

[hgm]

This 'stickyWindows' option is supposed to be there (implemented by Alessandro Scotti): if you move the main window, all auxiliary windows touching it should move with it. This works for me in Win2k. But in XP and Vista it does not seem to work anymore. I have no idea why. The window placement and position interrogation routines must still work, as the window position is correctly written to the winboard.ini and restored next time. So it must be the 'onSizing' and 'onMoving' messages that are no longer sent to the event handler for the auxiliary-window dialog callback routines. Problem is that I really don't know anything about these matters other than what I have learned from studying the WinBoard sources. So if that no longer works...

[michiguel]

This is the design that is useful for a human player, provided the player is white::

Code: Select all

|- - - - - - - -| Black
|               | Clock 
|               |
|    BOARD      | 
|               |
|               |
|               | White
|_ _ _ _ _ _ _ _| Clock

I always wondered why most of GUI did not have that set up, which is the most natural for the player.

Miguel

[Matthias Gemuh]

This is the design that is useful for a human player, provided the player is white::

Code: Select all

|- - - - - - - -| Black
|               | Clock 
|               |
|    BOARD      | 
|               |
|               |
|               | White
|_ _ _ _ _ _ _ _| Clock

I always wondered why most of GUI did not have that set up, which is the most natural for the player.

Miguel

Looks like board is not optimally large.


Matthias.

[Zlaire]

This 'stickyWindows' option is supposed to be there (implemented by Alessandro Scotti): if you move the main window, all auxiliary windows touching it should move with it. This works for me in Win2k. But in XP and Vista it does not seem to work anymore. I have no idea why. The window placement and position interrogation routines must still work, as the window position is correctly written to the winboard.ini and restored next time. So it must be the 'onSizing' and 'onMoving' messages that are no longer sent to the event handler for the auxiliary-window dialog callback routines. Problem is that I really don't know anything about these matters other than what I have learned from studying the WinBoard sources. So if that no longer works...

Ok, yes I suspected it was supposed to work like that. However as you say it's rather sporadical at the moment (I'm using XP).

What I meant with 'lock window' is basically telling the gui that you're happy with the current setup and it's not supposed to change whatever window you drag.

[Matthias Gemuh]

This is the design that is useful for a human player, provided the player is white::

Code: Select all

|- - - - - - - -| Black
|               | Clock 
|               |
|    BOARD      | 
|               |
|               |
|               | White
|_ _ _ _ _ _ _ _| Clock

I always wondered why most of GUI did not have that set up, which is the most natural for the player.

Miguel

Looks like board is not optimally large.


Matthias.

BTW, I do not claim that the board is optimally large in my ChessGUI

[hgm]

The probem is that numerical clocks are very wide, and hardly high. Attaching such appedixes is very awkward, unless there is something with which to fill up the space in between the clocks, which you want to always display.

I think the only workable way to provide such a layout is to put the clocks in separate windows. But windows have these nasty title bars at the top, over which you have only little control. Even if you would use those to contain the words black and white, I think it would look rather ugly.

Printing the clocks vertically, right of the board, would fit much better. But it is questionable if you would want to look at 90-degree rotated tekst. Although it does mimic the situation of a real chess board with a clock next to it, where you would also have to look sideways to read the clock.

[michiguel]

The probem is that numerical clocks are very wide, and hardly high. Attaching such appedixes is very awkward, unless there is something with which to fill up the space in between the clocks, which you want to always display.

I'd rather have empty space than having any other design. However, the empty space can be easily filled up with other useful things. You can have a pause button (very similar to real "over the board" clocks), a resign button, an offer draw button, flag, claim draw etc. But the most useful of all would be an analogical display.For instance, a vertical bar indicating how much of the last minute is left etc. Humans perceived analogical displays faster than digital.

Miguel

I think the only workable way to provide such a layout is to put the clocks in separate windows. But windows have these nasty title bars at the top, over which you have only little control. Even if you would use those to contain the words black and white, I think it would look rather ugly.

Printing the clocks vertically, right of the board, would fit much better. But it is questionable if you would want to look at 90-degree rotated tekst. Although it does mimic the situation of a real chess board with a clock next to it, where you would also have to look sideways to read the clock.

[hgm]

I wouldn't mind that asimmetry. The logos side by side would look crowded, I believe.

There is also a possibility to do the logos on the outside, of course. So in fact very similar to the screenshot, but with two-line clocks next to each other, rather than single-line clocks above each other:

Code: Select all

| logo  | White:  | Black:  | logo  |
| space | 1:00:00 | 1:00:00 | space |

Originally I picked the stacked clocks because I thought it would be more intuitively clear to associate the upper clock with the 'upper' player (i.e. he who starts with his pieces at the top of the board display). In filpView the clocks would exchange. For left and right clocks it is much less obvious which clock to associate with which player, and indeed I built in an option some releases ago (I think it was 4.3.13) to swap them. (When operating at an OTB tournament I percieved it as very annoying if, with the display standing next to the board, my time would appear on the opponent's side of the table.)