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: Richard Frith-Macdonald
Subject: Re: Window Focus Problem (was Re: GNUstep Window Manager (was RE: I dea))
Date: Wed, 10 Jan 2001 06:49:32 +0000

On Wednesday, January 10, 2001, at 04:00 AM, Sungjin Chun wrote:

> Hi, 
> Why such special treatment is needed ? 

I'm tired at the moment - three days work with 4 hours sleep a night ... I hope
that at least partially excuses the fact that I'm sending (at least) three 
emails
where one should have been sufficient.

The GNUstep/OpenStep/MacOS-X architecture does not expect to have to work with 
an
X style window manager.  It is designed to handle focus etc itsself, and 
determines
how window borders are drawn by setting a window to be 'key' (black titlebar) or
'main' (dark grey titlebar), or neither (light grey titlebar).

A GNUstep application should be 'active' when it has the X keyboard focus in 
*any*
window.  An 'active' application should have one (and only one) 'key' window and
may have zero or one 'main' windows ... neither necessarily bear any relation to
the window that has the X keyboard focus.

If the applcation loses X focus in all it''s windows, it should become 
'inactive',
and should have neither a 'key', nor a 'main' window.

A GNUstep application *must* be able to decide which if its windows is 'key'.
The default behavior built into the system is that, when a window receives a
mouse click, it makes itsself 'key' ... but not all windows should become 'key'
when they receive a click.   Under Window Maker, the GNUstep window simply 
doesn't
change its titlebar color when it receives X focus, but changes it when it 
becomes
'key'.  Under other window managers, clicks on a window that dooesn't want to
become key will result in flicker, as the window manager redraws the titlebar, 
then
has to redraw another window when the app immediately sets focus back to the
window that should actually have it.
Is there a way to solve this problem in general for X window managers?

A major problem area in X is, if a user clicks on a window border ...
The window manager wants to redraw the titlebar, but no click has been sent to
the window, so the gui frontend is not in a position  to decide whether to
become 'key' or not.  Probably the backend should send a simulated mouse click
to the frontend when a window is asked if it wants focus.


Anyway, I have to go catch a train now ... I hope this has given you some 
flavour
of the problem.  Even more, I hope you might be able to suggest solutions.  
Preferably
ones that are actually window manager independent.


reply via email to

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