bug-xboard
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-XBoard] Latest developments


From: Byrial Jensen
Subject: Re: [Bug-XBoard] Latest developments
Date: Wed, 04 Apr 2012 01:20:05 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120313 Thunderbird/11.0

Den 03-04-2012 22:51, h.g. muller skrev:

BTW. I cannot compile the git master branch right now:

[...]

This is weird. Especially since the above error messages seem completely
non-sensical. When I print backend.c from the current master branch in
the savannah repository, There is no N_ macro anywhere near that line
number. (It is in HandleMachineMove, though):

Sorry! I had some local changes in the code, that I was not aware of.
Problem is solved by using the right code.

I am glad the clock bug seems to have gone away. I really could not find
anything wrong remaining.

During rewriting the file browser in my 'refactor' branch, I stumbled on
a another problem, and I am not sure if v4.6.x is currently free from
that. I got very erratic behavior as to which became the active window
after pop-up or pop-down of dialogs. I remember I had problems with that
before, but I thought they went away after I popped up file-browse and
error-popup shells as children of the dialog that had focus, rather than
as children from the main window. This, however, seemed no longer
sufficient when I used GenericPopUp to generate the file-browse dialog:

When I invokes it from the Browse button of a dialog (say Match
Options), the first time it popped up on top (as it should). But after
closing it, focus revert to the main board, rather than the Match
Options dialog, although I created it as a child of the Match Options
shell. And even worse, if I invoked it again from the Match Options
dialog after that, it would consistenly pop up in the background (often
completely invisible), while the Match Options dialog would retain focus
and stay on top. This always happened after the main window had obtained
focus once.

No amount of XtSetKeyBoardFocus, XSetFocus, or even XRaiseWindow could
alter that pattern.

After some Googling, I found that it is a known problem that
XRaiseWindow does not work on Gnome. Presumably the Xaw routines to
create and popup windows suffer from that as well. It seems to have
something to do that XRaiseWindows cannot be used to raise windows of
another application, and that Xaw apparently does not tell the window
manager to which application the windows belong, so that it assumes they
are from different applications. I dug up some code that seems to
achieve the raising by sending a _NET_ACTIVE_WINDOW message to the root
window. To get my file-browser rewrite work aceptably, this was
essential. I wonder if it would be needed to port this to 4.6.1.

I have no problem with wrong windows having focus. Never happened for me.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]