Re: Refining the concept of focus
- From: Christopher Blizzard <blizzard redhat com>
- To: Owen Taylor <otaylor redhat com>
- Cc: gtk-devel-list gnome org
- Subject: Re: Refining the concept of focus
- Date: Wed, 22 May 2002 12:09:52 -0400
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/
------------
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]