Re: [Bug-XBoard] Xboard-4.5.3a bug: windows sliding

[Hans Aberg]

On 26 Feb 2012, at 18:02, h.g. muller wrote:

> At 23:41 25-2-2012 +0100, Hans Aberg wrote:
>> Also, I got some warnings:
>> xboard.c: In function 'MenuEngineSelect':
>> xboard.c:3901: warning: cast from pointer to integer of different size
>> xboard.c: In function 'AppendEnginesToMenu':
>> xboard.c:3926: warning: cast to pointer from integer of different size
>> 
>> At least in the first case, you assume that a pointer can be stored in an 
>> 'int', which is not true on OS X 64-bit mode - you need a 'long'. On OS X 
>> 10.6 and later, 64-bit is the default compile mode.
> 
> Well, an int had to be passed in a variable that was declared as a pointer, 
> so it was just getting its original size back. Having a 32-bit system, I 
> don't get these warnings. But I think they should be solved now, by doing 
> two-step casting, first to an integer the size of a pointer.

I did not get that warning anymore in a 64-bit compile.

The version number is not updated. I get
  $ xboard --version
  xboard version master-20120212
And after 'make pdf', the same version is mentioned in the manual.

> I did some more work on the -stickyWindows: touching auxiliary windows now 
> also adapt their size and position to size changes of the main window (due to 
> variant change).

I haven't tried variants yet, except FRC, because it is supported by the 
stockfish engine.

> New version is now both at hgm.nubati.net and the GNU Savannah website.

I used the first one.

>> If mean windows stacking, xboard does not stack, but xeyes does. That is, if 
>> one xboard is open, then next has windows in exactly the same position, 
>> whereas xeyes opens the next right-down a bit. The same if one alternates 
>> between sat xeyes and xlogo.
> 
> OK, so I understand that this actually is a feature. Now that the auxiliary 
> windows follow the displacement of the main window this is not so annoying 
> anymore.

Your model is incompatible with multiple open copies, because the data is saved 
to the same .xboardrc. Current, multiple copies of xboard end up exactly on top 
of each other.

It might be cool (and practical) to save data for multiple copies, but it takes 
some thinking.

Hans