Re: Refining the concept of focus

[Christopher Blizzard <blizzard redhat com>]

Owen Taylor wrote:
> To fully implement the XEMBED spec, some refinement of how GTK+ deals with focus
> was necessary.
>
> The following patch adds three properties:
>
>  GtkWidget::is_focus - is this focus the focus widget within it's (in-process) GtkWindow
>  GtkWindow::is_active - is the (possibly out-of-process) toplevel of the window the X focus
>  GtkWIndow::has_toplevel_focus - does this toplevel window contain the focus widget
>
>
>  +----------- GtkWindow (A)--------------+
>  |                                       |
>  | GtkPlug (B)------+ GtkPlug-(D)------+ |
>  | | GtkEntry (C)-+ | | GtkEntry (E)-+ | |
>  | | |            | | | |[focus here]  | | |
>  | | +------------+ | | +------------+ | |
>  | +----------------+ +----------------+ |
>  +---------------------------------------+
>
> So, in a situation like the above, we might have 
>
>  is_focus set on C and E
>  is_active set on A, B, and D
>  has_toplevel_focus set on A and E 

Do you mean A and D here?

> has_toplevel_focus is really an internal implementation detail.

Actually, this will be really useful in Mozilla.  I'll use it since we 
don't generate GetFocus calls for windows that don't have toplevel focus.

Related to the XEMBED spec, have you guys thought about what it might 
take to make it possible for an embedded window to request that the 
owning window become inactive, for supporting window modality?  You 
might need something else for complete app modality as well.

Just wondering.

--Chris

--
------------
Christopher Blizzard
http://people.redhat.com/blizzard/
------------