[Top][All Lists]

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

Re: Window Focus Problem (was Re: GNUstep Window Manager (was RE: I dea)

From: Richard Frith-Macdonald
Subject: Re: Window Focus Problem (was Re: GNUstep Window Manager (was RE: I dea))
Date: Thu, 11 Jan 2001 11:41:28 +0000

On Wednesday, January 10, 2001, at 11:17 AM, Dan Pascu wrote:

> We don't speak about the same thing. You most likely refer to input 
> focus, and yes gnustep apps get input focus, because they take that by 
> themselves (the window manager do not give input focus to a window).

Yes- that's what I was meaning.

> But I was speaking about an internal track that wmaker keeps about 
> focused/unfocused windows, which means much more than just the input 
> focus. 
> Your patch disable the calls to wWindowFocus() and wWindowUnfocus() in 
> the case of gnustep apps. those calls are not made only for the 
> currently focused window, but also for the previously focused window, 
> when the focus switches from one window to another. Those calls do a 
> lot of things and skipping them may cause trouble. 


> I no longer see it with the test program Adam sent to the list. But I 
> cannot compile gnustep at this moment to test with a real gnustep app. 
> But the problem may be in the fact that while in "click to focus" mode, 
> gnustep apps still take input focus when the mouse pointer enters their 
> window using the XSetInputFocus() call. Is this true?

Not on pointer entry of a window, but at other times - mostly when a mouse-click
occurs in a window.

> Because if so, 
> this means doing things of which wmaker is not aware of, because it 
> doesn't expect apps to take focus like in "focus follows mouse" while 
> they are in "click to focus". I've seen something similar with dockapps 
> that take focus this way and cause a focused xterm's cursor to become 
> empty (which means it lost input focus) while the titlebar remains as 
> if the xterm is still focused. Is this what you mean by this focus 
> problem? 

I don't think so.  There is no focus problem while a GNUstep app is running,
but once it exits, focus is not returned to any other window (minor problem)
and clicking on any window fails to set focus to that window (big problem).

Perhaps if I describe what we need to achieve, you can tell me how we can do it.
If we can achieve what we want from *any* wm, it would be ideal, since it would
mean that some GNUstep-specific code could be removed from Window Maker, leaving
it a bit simpler/more maintainable.

1. The GNUstep app needs to know when any of its windows *or* their borders have
been clicked on, so that it can make itsself 'active' - mapping some windows 
are normally unmapped while thee app is 'inactive'.
NB. an 'active' app should have keyboard focus.

2. The GNUstep app needs to know when it should become 'inactive' and unmap some
of its windows.  This is presumed to be whenever the app loses keyboard focus.

3. The app needs to be able to control which of its windows has its border
highlighted.  When a mouse click occurs on a window *or* its border, the app 
be able to control whether the clicked window gets the border highlighted or the
highlighting remains on the old window.

It doesn't actually sound too complicated does it?

reply via email to

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