Re: [rox-devel] OroboROX-0.9.6-11

[Guido S. <__g...@we...>]

On Thu, 07 Apr 2005 12:34:54 -0700
Ken Hayber <ke...@ha...> wrote:

> Guido Schimmels wrote:
> 
> >On Wed, 6 Apr 2005 22:28:09 -0300
> >Jonatan Liljedahl <th...@ho...> wrote:
> >
> >  
> >
> >>On Wed, 06 Apr 2005 08:16:30 -0700
> >>Ken Hayber <ke...@ha...> wrote:

> I played around with the usleep value, but 1000 is worse and <50 makes 
> no difference.  I can see that if I hold the mouse perfectly still while 
> double-clicking it happens ~100%, but if I move the mouse it is OK.

Ken, are you referring to your specific problem, or do you also experience general lag compared to previous releases?
And Jonatan, if the problem is really so significant, you won't have a problem to pinpoint the exact OroboROX version that introduces this. That would be extremely helpfull.

I would like to get rid of the usleep(). It's really only the raise delay which necessitates that.
I will make a change, so that only in case of a pending raise we use the usleep hack. Else I'll sent OroboROX to sleep via
XNextEvent(dpy, &ev)

Of course this means, glib mainloop integration is void and nil, so I'll get rid of that. This means, I can't use some glib features, and dbus integration will not be possible. But I think all this is not needed. There is already a message bus integrated into the xserver, makes sense to use that for an X-Windows window manager, doesn't it? And for a simple pat on the neck, OroboROX listens to the standard Unix signals, which is what we use for configuration change notification. Works well enough.

If the XServer provided a timeout event, I would use that. What we really want is to be woken up immediately when an event arrives. The unconditional slepping is ugly. But I couldn't find anything of that sort in my X11 docs.


> After some snooping in the code, I added apply_focus_policy(NULL); at 
> the end of HandleMapNotify() and it fixes my problem.  What I don't know 
> is whether this could cause another problem or is the ideal solution.
> 
> Suggestions?

Ah, you are right. This function I took from xfwm4. It fixed erratically withdrawn "ghost windows".
Your fix is probably correct. But could you try instead:

	...
	c = client_of_window(ev->window);
	if (c)
	{
		//TRACE ("MapNotify for \"%s\" (0x%lx)", c->name, c->window);
		if (c->map_pending)
		{
			c->map_pending = FALSE;
			apply_focus_policy(c);
		}
	,,,

and tell me if it's still OK?
If it doesn't work that way, could you experiment a little with this function call inside handleMapNotify()?
I think you understand what I'm getting at. Trying to avoid unneccessary calls.
Your fix certainly does play it save.