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

[Hans Aberg]

On 25 Feb 2012, at 22:57, h.g. muller wrote:

> At 15:49 25-2-2012 +0100, Hans Aberg wrote:
>> If I try xwininfo on the command line (example below), and compare the data 
>> of different windows, then the parameters have the same value as follows:
>>  -frameX  <->  Relative upper-left X
>>  -frameY  <->  Relative upper-left Y
>> 
>> There is a source file xwininfo.c for this program.
> 
> Hans, did anyone ever tell you you are a genious! :-)

Yes, sure. :-)

> Not only does the routine XGetWindowAttributes they use there provide the 
> info about frame size we need; it also seems to work much more reliably for 
> getting the actual coordinates.

I saw XSetWindowAttributes(), but I could not find any hits on 
XSetWindowAttributes(), so I did not mention it.

> I pushed a new version now to the http://hgm.nubati.net/cgi-bin/gitweb.cgi 
> repository (master branch). I removed the -frameX/Y options there, and used 
> the new routine.

I compiled it, it works. Nice!

Note that 'make install-pdf' does still not work. It works in xboard-4.5.3a.

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.

> I also made a first attempt to implement the -stickyWindows options: the 
> auxiliary windows Engine Output, Move List, Eval Graph and Game List will 
> then move together with the main window, if you drag the latter. (That is, 
> until they bump into the edge; the window manage is really very reluctant to 
> do as it is told...) A checkbox in the General Options dialog can switch it 
> on or off. In WInBoard the option is a bit smartr, and only co-moves 
> auxiliarry windows that actually touch the main window In WB it is also smart 
> enough to move attached windows when the main board resizes (e.g. wnhen you 
> switch from normal to gothic), doesn't do that here yet either.

It works, and it is in fact nice.

> I still have the problem when I position in (0,0). This works fine if the 
> background is the desk top, but if there is another window behind, it moves 
> to (0,25).

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.

Hans