discuss-gnustep
[Top][All Lists]
Advanced

[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: Dan Pascu
Subject: Re: Window Focus Problem (was Re: GNUstep Window Manager (was RE: I dea))
Date: Wed, 10 Jan 2001 13:17:51 +0200 (EET)

On 10 Jan, Richard Frith-Macdonald wrote:
> 
> On Wednesday, January 10, 2001, at 02:36 AM, Dan Pascu wrote:
> 
>> What puzzles me is that there is code to treat a gnustep app in a very 
>> particular way regarding focus. This means that a gnustep app: 
>> 1. Will not get focused. 
> 
> That can't be right - GNUstep apps plainly *do* get focussed by Window Maker

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).
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.

> 
> 
> Well, I added the code to permit GNUstep apps to control their titlebars - 
> after
> discussion on the window maker and gnustep mailing lists.
> This code may not be 100% correct ... but the focus problem with Window Maker
> existed *before* this change was made ...

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? 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?
 


-- 
Dan




reply via email to

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