Re: fun with window managers.. (help!)



----- Original Message -----
From: "Bill Haneman" <bill haneman sun com>
To: "Matthias Clasen" <matthiasc poet de>
Cc: "Havoc Pennington" <hp redhat com>; <gtk-devel-list gnome org>;
<wm-spec-list gnome org>
Sent: Monday, November 12, 2001 4:02 PM
Subject: Re: fun with window managers.. (help!)


>
> Part of the problem I am having with GDK (and GTK+) is that GDK windows
> always set WM_TAKE_FOCUS as one of their protocols, and gdk_window_new
> always sets wm_hints.input to TRUE.  Thus it appears that GdkWindows are
> always "LOCALLY ACTIVE" in ICCCM terms.
>

Yes, it looks like that. And looking closer there are some places which look
dubious
wrt. to the focus handling sections of the ICCCM.

In gdkwindow-x11.c (gdk_window_focus):

      XRaiseWindow (GDK_WINDOW_XDISPLAY (window), GDK_WINDOW_XID (window));

      /* There is no way of knowing reliably whether we are viewable so we
need
       * to trap errors so we don't cause a BadMatch.
       */
      gdk_error_trap_push ();
      XSetInputFocus (GDK_WINDOW_XDISPLAY (window),
                      GDK_WINDOW_XWINDOW (window),
                      RevertToNone,
                      timestamp);
      XSync (GDK_WINDOW_XDISPLAY (window), False);
      gdk_error_trap_pop ();


This is against section 4.1.7 of the ICCCM, which states that
Clients that invoke a SetInputFocus request should set the revert-to
argument to Parent .

Looking further, I find that gdk_window_focus() is called from
gtk_window_present() in the following way:

    gdk_window_focus (widget->window, gtk_get_current_event_time())

and gtk_get_current_event_time() may return CurrentTime if there is no
current event. But section 4.1.7 states that

Clients that use a SetInputFocus request must set the time field to the
timestamp of the event that caused them to make the attempt. This cannot be
a FocusIn event because they do not have timestamps. Clients may also
acquire the focus without a corresponding EnterNotify . Note that clients
must not use CurrentTime in the time field.


> GtkWindows that are created with type=POPUP are ignored entirely by the
> WM, but that's not exactly what we need for an onscreen keyboard.
>
> What is the opinion of gtk-devel as to how we should proceed?  I may
> well be missing pieces of API here, but so far my experiments suggest
> that although sawfish respects output-only windows if the protocols and
> input flag are set appropriately at creation time, if these flags are
> reset after the window is mapped to the screen they are ignored.  (Note
> that I am not 100% sure of this yet, I may not be calling the API
> correctly to reset these parameters).


The ICCCM states that wms must look for the client properties when the
toplevel
window leaves the WITHDRAWN state and may monitor them while the window is
in
NORMAL or ICONIC state. Seems that sawfish doesn't monitor them.

You could try to create a GtkWindow, then adjust the properties and then
cause a
NORMAL->WIDTHDRAWN->NORMAL cycle, but a) this would cause flickering
and b) I expect this would disturb gtk badly.

>  Setting these properties before
> the windows are mapped to the display does not appear to be possible via
> Gtk+.

I think this is a gap in the API. Although they are rarely needed, it should
be possible
to create unfocusable (not quite output-only, since I guess you still want
pointer-input for
your GONK, just no keyboard input) windows in gtk.

> GDK would seem to allow this via use of foreign windows, but how
> then would one tell GTK+ to use a particular GdkWindow to create its
> GtkWindow?
> The alternative would be to bypass GTK altogether and resort to X API
> for creation of the onscreen keyboard, which seems very unattractive for
> something that calls itself "Gnome" and lives in Gnome CVS, and would
> present portability problems.
>
> Regards, and suggestions solicited ;-)
>


Would it be enough to create a new toplevel with the right properties
through the
X API and reparent the GtkWindows underlying X window to it ? Does gtk cope
with such a treatment ?

Matthias




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