[bug #27715] 2 (minor) graphic issues

[Sylvain Beucler-4]

URL:
  <http://savannah.gnu.org/bugs/?27715>

                 Summary: 2 (minor) graphic issues
                 Project: XBoard
            Submitted by: None
            Submitted on: Fri 16 Oct 2009 08:53:33 AM UTC
                Category: None
                Severity: 3 - Normal
              Item Group: None
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

I tested these also on a more recent system to reduce the risc of another
Xlib related problem. The effects are identical on both systems, so here they
are:

1. Logon to fics, and switch the board to bug- or crazyhouse mode, afterwards
observe a classic game, e.g.:

ex BugBug 20
unex
ob -b

Some square colors an a and b files are wrong (black or light squares
remaining from the bughouse mode). A "Filp view" repairs the board. Try
severel times because sometimes it's correct.

2.  Whenever the board gets enlarged (e.g. with the above switch to bughouse)
the white rectangular area behind the menu items ("File" "Mode" ...) gets
enlarged too and extends to right of "Help".





    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?27715>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[Sylvain Beucler-4]

Follow-up Comment #1, bug #27715 (project xboard):

I tried this on a third system:

ad 1) : I wasn't able to reproduce this effect on that system.

ad 2) : The white rectangle isn't even visible there. But the bug shows when
doing this:

xboard -variant courier

Then switch to variant "normal". The "Options" and "Help" menu items get cut
off, when the board shrinks (on all 3 systems).

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?27715>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[Sylvain Beucler-4]

Follow-up Comment #2, bug #27715 (project xboard):

Effect (1) suggests that the display is not updated after a size switch, and
that perhaps a call to DrawPosition shoud be added somewhere to make certain
it always is updated.

I will look into the resizing of the menu bar.

H.G. Muller

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?27715>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[Sylvain Beucler-4]

Follow-up Comment #3, bug #27715 (project xboard):

OK, apparently the menu bar (which in my system is unobservable against the
background) apparently did not stretch all the way to the right edge of the
window, but was just the size of the menu strings. As a result scaling the
window would scale the width of the menu bar proportionally, producing the
effects you described.

I will fix it by chaining the right edge of the menu bar to the left edge of
the window, so that the width of the menu bar will no longer vary when the
window is resized.

Effect (1) I could not reproduce, but I have added a DrawPosition call to the
function VariantSwitch for another reason, and that quite likely fixes this
problem too.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?27715>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[Sylvain Beucler-4]

Follow-up Comment #4, bug #27715 (project xboard):

I debugged (1) a bit, because I feared it might be not reproduceable. I saw
that when switching to bughouse mode "DrawPosition" is called twice. First
with fullRedraw=1, then with fullRedraw=0.
When switching back to normal mode, "DrawPosition" is called only once with
fullRedraw=0. Forcing fullRedraw to 1 in that case repairs that bug for me.

Also note, that in (2) there is a title bar (with -title) between menu bar
and right window edge, that has issues with resizing.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?27715>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[Sylvain Beucler-4]

Follow-up Comment #5, bug #27715 (project xboard):

Can you tell which call to DrawPosition exactly you had to fix? The one in
VariantSwitch, which is invoked whenever XBoard receives a board from the ICS
that does not fit the current variant, now does a full redraw. Which is the
other one?

The fix I made to the menu bar (chaining the right edge to the left window
edge) should preserve the size of the menu bar for all re-sizings of the
window, even if there is a title bar next to the menu bar. All width change
should be taken out of this title bar.

H.G. Muller

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?27715>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[Sylvain Beucler-4]

Follow-up Comment #6, bug #27715 (project xboard):

I did just a dirty change to see, if that helps:

void DrawPosition(fullRedraw, board)
     /*Boolean*/int fullRedraw;
     Board board;
{
    printf("FullRedraw: %dn",fullRedraw);
    XDrawPosition(boardWidget, 1/*fullRedraw*/, board);
}

So I didn't see, where the calls are coming from, just which paramters are
coming in at which time . And passing a 1 to "XDrawPosition" removed the
effect.
On a switch to bughouse I saw:
FullRedraw: 1
FullRedraw: 0
On a switch back to normal I saw:
FullRedraw: 0
---------
So if you always do a fullredraw now, that must be sufficient.





    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?27715>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[Sylvain Beucler-4]

Follow-up Comment #7, bug #27715 (project xboard):

Yes, doing a complete redraw every time will of course help. But the whole
idea of having this parameter is to not waste time on unnecessary redraws.

H.G. Muller

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?27715>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[Sylvain Beucler-4]

Follow-up Comment #8, bug #27715 (project xboard):

That's clear. My change wasn't meant to be a permanent fix. :)

My last sentence was badly formulated, should have been:

So if you do a fullredraw on any variant switch, that must be sufficient.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?27715>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[Sylvain Beucler-4]

Update of bug #27715 (project xboard):

                  Status:                    None => Ready For Test        

    _______________________________________________________

Follow-up Comment #9:

issue nr 2) should be fixed... the other one couldn't be reproduced. Please
test.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?27715>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[Sylvain Beucler-4]

Follow-up Comment #10, bug #27715 (project xboard):

Ad 1 : I don't see that "VariantSwitch" gets called when you switch from
bughouse to normal in ICS-mode (with smoves command).
But exactly that would repair the problem. So I further investigate this.

Ad 2 : The menu bar is ok now. The title bar is not, but as I don't use the
title bar, I don't really care.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?27715>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[Sylvain Beucler-4]

Follow-up Comment #11, bug #27715 (project xboard):

Correction: "VariantSwitch" gets called, but drops out at the beginning:

if(gameInfo.variant == newVariant) return;

Because "gameInfo.variant" is always 0 on that position, any switch to normal
doesn't execute the remaining code.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?27715>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[Sylvain Beucler-4]

Follow-up Comment #12, bug #27715 (project xboard):

What happens (when doing a "smoves"-switch from bughouse to normal) is this:

in read_from_ics() the following is done:

Reset(FALSE, TRUE);  <-  This sets gameInfo.variant to 0
gameMode = IcsObserving; <- just before changing the game mode

Afterwards VariantSwitch() is called, which skips the required code, because
it thinks the current variant is normal instead of bughouse.

Strange that this bug has only visual effects on my system, so I do a
quick/dirty fix for my "special edition".


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?27715>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[Sylvain Beucler-4]

Follow-up Comment #13, bug #27715 (project xboard):

OK, it seems that indeed it is better to change the call here to Reset(TRUE,
TRUE);. This would force Reset to do a complete redraw of the new position.

I guess in 4.2.7 this was not needed, as one only gets here from modes
IcsIdle or BeginningOfGame, and in both cases this would already display the
initial position of VariantNormal, or at least an 8x8 board with normal
checkering.

To make the code a little safer in this respect, I will ask for a total
redraw on two calls to Reset from the ICS code when changing games.

H.G. Muller

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?27715>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[Sylvain Beucler-4]

Follow-up Comment #14, bug #27715 (project xboard):

I even do this:
  if(gameInfo.variant)
    Reset(TRUE, TRUE);
  else
    Reset(FALSE, TRUE);

This avoids the short popup of the initial position when going from normal ->
normal, which should be the most common case.

ad (2):
There seem to be 2 typos in xboard.c line 2780-2781:
    XtSetArg(args[1], XtNright,  XtChainLeft);
    XtSetValues(menuBarWidget, args, 2);
Changing that to:
    XtSetArg(args[2], XtNright,  XtChainLeft);
    XtSetValues(menuBarWidget, args, 3);
removes uglinesses in the menubar when vertical resizing is done.


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?27715>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[Sylvain Beucler-4]

Follow-up Comment #15, bug #27715 (project xboard):

I see in my enthusiasm, I regressed something. VariantSwitch should force a
full redraw of the current board (boards[currentMove]), not of the initial
position (what InitPosition(TRUE) would do.)

To prevent the flicker when giving an smoves command by hand, it would be
better to leave Reset(FALSE, ...) in the mentioned position, and force it
after the full move list has been read in stead (slightly after
FeedMovesToProgram() is used to send the moves to the program):

                    if (gameMode == IcsObserving && ics_gamenum == -1) {
                        /* Moves came from oldmoves or moves command
                           while we weren't doing anything else.
                           */
                        currentMove = forwardMostMove;
                        ClearHighlights();/*!!could figure this out*/
                        flipView = appData.flipView;
                        DrawPosition(TRUE, boards[currentMove]);
                        DisplayBothClocks();

I will change it accordingly.

H.G. Muller

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?27715>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[Sylvain Beucler-4]

Follow-up Comment #16, bug #27715 (project xboard):

new version uploaded should be fixed now... please test again

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?27715>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[Sylvain Beucler-4]

Follow-up Comment #17, bug #27715 (project xboard):

All ok for me in xboard-4.4.1.20091022. Thanks

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?27715>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[Sylvain Beucler-4]

Update of bug #27715 (project xboard):

                  Status:          Ready For Test => Fixed                  
             Open/Closed:                    Open => Closed                


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?27715>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard