Re: [XBoard-devel] some warnings during compiling

[h . g . muller]

Op Za, 12 maart, 2016 6:17 pm schreef Arun Persaud:
>
> The right-click works well for me, I would add some text somewhere
> pointing to it. A natural area would be the area above the board where we
> show the moves, however that area gets partly covered by the menu. Might
> be still the best place though... otherwise I could imagine the window
> title, e.g. add a "right click on menu to get help" when you in a menu and
> remove that text otherwise... but some window managers can be configured
> to not show a title if IIRC, so that would not be the best place... so not
> sure where to advertise this new feature when you are in a menu.
>

I have been thinking about this too, and the ability of people to notice
messages in the field above the board has been disappointing, not to say
dismal. To shake people up in a way they cannot overlook, I thought of the
following:

When XBoard starts up, and shows the board for the first time, we write a
message all over the empty part in boldface white letters of about half
the square size. And mark the whole board as 'dirty' so that any redraw of
the board would erase that. This feature could be used as a kind of
'message of the day'; if a release has shocking new features we think
people should absolutely know about, we could announce them there. A
sentence with permanent presence in this message could be: "right-click
dialog texts and menus for help".

> I also had some issues with resizing the window... making it bigger
> worked, but making it smaller sometimes ended up with a cut off board (see
> screenshot). Sometimes making it smaller actually showed the full board,
> but that only worked in roughly 1 out of 20 or so. Not sure, if we want
> that or if we want to always show the full board. I think the full board
> would be nicer.
>

I will check it out. Normally it should calculate the largest square size
that makes the board fit in the given window, and then constricts the
window to fit exactly around it. It could be that I set a certain minimum
size to the squares, though. The vertical size your screenshot shows does
look a bit too small to be viable, no matter what you do.

What annoys me most in XBoard is that the clocks and other elements do not
adapt with the interactive sizing, but can only be adjusted with the -size
option. This would require having a mapping (either through formula or
table) from square size to font point size, however.

> Wondering if we can make the menu smaller by going to only a single menu
> box that then has the main menu as submenu... similar to how webpages do
> that nowadays for mobile (e.g. the 3 horizontal bars)
>

I have no doubt this can be done, but actually I hate that. We could also
make the menu bar appear as soon as you hover the mouse over the message
widget (or menu bar). I think in GTK you can hide or show any widget, and
the rest of the layout then simply adapts. (E.g. all non-top-level dialogs
have OK and Cancel buttons, and for those that should not have them we
just hide them.) So we could hide the message widget and button bar while
at the sme time showing the menu bar in a mouse-move callback on the
message widget, and the reverse (if it was not already so) on the
mouse-move callback that we already do attach to the board.

> Another thing we could add would be tooltips, e.g. if you hover over a
> button it shows a very short help (just a few words). gtk has that
> built-in
>
> https://developer.gnome.org/gtk2/stable/GtkTooltip.html
>

Well, that would be an alternative to the right-clicks. We don't need
both. But unless we made an entirely new set of such short help messaged,
I think the regular manual decriptions are a bit too long to display in
this form. I could of course also attach the popup of a help dialog to
hover events rather than button3 pressor release. The advantage of the
tooltips is that they don't seem to grab events themselves, so that they
automatically disappear when you move the mouse away. (I am not sure if
that is when you move it away from the element they describe, or from the
tooltip message itself, which would matter if the latter became very
large.)

>
> That way we could add some help to << < P > >> and perhaps also to the
> clocks (white time, black time)...

Well, in principle these buttons also have the button3 help clicks now
(like any buttons other than OK/Cancel). But the way the manual lookup
currently works is that it only takes the label upto the first
non-alphanumeric, non-hyphen as lookup key, which in this case leaves just
a P or an empty string. It would not find sections with header < or << in
the manual anyway. Of course we could make such sections in the manual.

> that way, if we make the window smaller,
> we could remove "white" and "black" from the clocks and save some space.

In the old Xaw front-end the various sizes were divided into tiny, small
and normal layout. In the smaller layouts the texts on the menu bar were
abbreviated to single letters, and the color indicators in the clocks
would be just W: and B:. I think that was a better solution then writing
nothing at all. I am not sure it is really helpful, though. Even at -size
21 a clock font small enough to not exceed the width of an 8x8 board is
very well readable.

> We could also have a toggle button under the view menu (or
> somewhere else) that removes the text area and the << < P > >> buttons.
> This might be useful, if someone uses xboard to just follow games for
> example on fics.

I am not sure why this would be useful; these elements should require only
a very small fraction of the size of an 8x8 board. If that is not the
case, it is because the font used in them is too big. The font issue has
never been really addressed well in GTK.

H.G.