Re: Refining the concept of focus

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.


Christopher Blizzard

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