On Sat, Aug 27, 2011 at 6:09 AM, hannes.janet...@gmail.com <hannes.janet...@googlemail.com> wrote: > 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..
Actually, your solution is perfect, it does not need to stay visible to the compositor, only the backing window need to remain mapped (since its just an input handling window) > > >> 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 > -- Sam Spilsbury _______________________________________________ wm-spec-list mailing list wm-spec-list@gnome.org http://mail.gnome.org/mailman/listinfo/wm-spec-list
