On Sat, Aug 27, 2011 at 12:02 AM, hannes.janet...@gmail.com <hannes.janet...@googlemail.com> wrote: > On Thu, Aug 25, 2011 at 8:06 AM, Sam Spilsbury <smspil...@gmail.com> wrote: >> Hi, >> >> I was doing some work on Unity the other day and noticed an >> interesting problem - we have a situation where we need to keep a >> window mapped but at some points remove its input shape or move it >> offscreen. At this point, it makes no sense for that window to keep >> the input focus, but it doesn't seem like there's a model in the ICCCM >> or EWMH for handling the case where a client wants to remove its input >> focus without explicitly setting the input focus to something else >> (which is wrong). >> > > If I understood correctly you want to make a window make itself > invisible and take no focus while keeping it mapped. Why not reparent > the window in the beginning and then just map/unmap the parent? >
ah I guess you meant it should stay mapped as top-level window to be visible for the compositor.. > Regards, > Hannes > >> I'd like to be able to have some kind of protocol to handle this case, >> and initially I thought that maybe I could change the input hint on >> the client window to FALSE and then send a synthetic FocusIn event to >> the client window, at which point the window manager would receive >> that and move the focus off to something else since that window is not >> allowed to be focussed. However, the ICCCM is vague on this point, and >> says that where WM_TAKE_FOCUS is not present in WM_PROTOCOLS and >> InputHint is FALSE in WM_HINTS then the window has "No Input - The >> client never expects keyboard input. An example would be xload or >> another output-only client. ". However, it does not state what should >> happen should the client explicitly request input focus, which is what >> is going on here. I would imagine in this case that should a client >> request input focus to a window that does not allow input, that the >> window manager should focus the next appropriate window, whether that >> be a transient window, an ancestor, a group member or the next most >> active window. >> >> What does everyone think of something like the following: >> >> * Client changes InputHint to false and removes WM_TAKE_FOCUS from >> WM_PROTOCOLS >> * Client sends a synthetic FocusIn event to its own window with the >> window member being set to the client, mode being NotifyNormal and >> detail being NotifyDetailNone >> * WM gets the FocusIn event on the client window, sees that InputHint >> is false, moves the focus off to the next appropriate window. >> >> Regards, >> >> Sam >> >> -- >> Sam Spilsbury >> _______________________________________________ >> wm-spec-list mailing list >> wm-spec-list@gnome.org >> http://mail.gnome.org/mailman/listinfo/wm-spec-list >> > _______________________________________________ wm-spec-list mailing list wm-spec-list@gnome.org http://mail.gnome.org/mailman/listinfo/wm-spec-list
