Re: menu bug solved?
- From: mmc maruska dyndns org (Michal Maruška)
- To: John Harper <jsh unfactored org>
- Cc: sawfish-list gnome org
- Subject: Re: menu bug solved?
- Date: Tue, 08 Feb 2005 03:58:42 +0100
John Harper <jsh unfactored org> writes:
> On Feb 6, 2005, at 3:57 PM, John Harper wrote:
>> On Feb 6, 2005, at 2:57 PM, Michal Maruska wrote:
>>> i think, that XFlush is not enough. XSync is needed, b/c X server could first
>>> serve the requests of the sawfish-menu client, and deny it the grab.
>> I don't think that Xsync will make any difference here, the flush ensures that
>> the wm process has ungrabbed by the time the menu process attempts to grab.
> on second thoughts, I take that back, it relies on the X server processing
> requests in the order they're flushed, which isn't necessarily true. Does this
> patch work?
even though i don't use the SF menus, i took the time to look into the issue,
because i have the tools to do it, and the knowledge.
I would appreciate, if you mentioned the fact that I found this bug, which
dates back long, in the CVS Changelog. Even if i didn't bother to provide a
* sawfish/wm/menus.jl (popup-menu): synchronize with the server
after ungrabbing, just to be sure, instead of flushing
and i disagree with "just to be sure" formulation. My email explains what can
(and does) happen without it.
>>> what does (x-server-timestamp) do is a different issue....
>>the timestamp from the current event is passed through to gtk_menu_popup (),
>>it's used when trying to grab the keyboard and pointer to avoid cancelling a
I know. But simple CurrentTime might do as well (unless we want to fail if some
client grabbed/ungrabbed in between). If called from sawfish-client,
last_event_time might be meaningless.
] [Thread Prev