GNOME Bugzilla – Bug 601228
rdesktop does not get keypress signals
Last modified: 2009-11-12 20:21:30 UTC
Hi, I;'m not sure if you're interested in this kind of 'issue'; it's certainly easy to point it around to other componentes. But let me explain: I'm running gnome-shell at the moment for some early testings. -> open gnome-terminal -> use rdesktop to connect to a windows server (not a gnome component... ) While rdesktop is the active window and you can perfectly navigate inside with the mouse, every keystroke that is sent to it ends up in the gnome-terminal that was used to start the rdesktop session. (in fact it always ends up in the last window that had focus).
Reassigning to Mutter as the problem probably lies there. - Can you attach the output of typing 'xprop' then clicking on the rdesktop window? - Does the rdesktop window show focus? (That is, does the titlebar change color?)
dle3ams@3120-2914:~> xprop WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW, WM_TAKE_FOCUS XKLAVIER_STATE(INTEGER) = 0, 0 _NET_WM_STATE(ATOM) = WM_STATE(WM_STATE): window state: Normal icon window: 0x0 _NET_FRAME_EXTENTS(CARDINAL) = 2, 2, 22, 4 _NET_WM_DESKTOP(CARDINAL) = 0 _NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_MOVE, _NET_WM_ACTION_MINIMIZE, _NET_WM_ACTION_SHADE, _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_CLOSE, _NET_WM_ACTION_ABOVE, _NET_WM_ACTION_BELOW WM_NORMAL_HINTS(WM_SIZE_HINTS): program specified minimum size: 800 by 600 program specified maximum size: 800 by 600 WM_CLASS(STRING) = "rdesktop", "rdesktop" _NET_WM_NAME(UTF8_STRING) = 0x72, 0x64, 0x65, 0x73, 0x6b, 0x74, 0x6f, 0x70, 0x20, 0x2d, 0x20, 0x31, 0x30, 0x2e, 0x33, 0x2e, 0x30, 0x2e, 0x36, 0x39 WM_NAME(STRING) = "rdesktop - 10.3.0.69" dle3ams@3120-2914:~> Regarding the focus: no, the focus stays on gnome-terminal (or whatever else it is at).
Created attachment 147292 [details] Simple Xlib-based reproducer OK, reproduced with a simple Xlib test case. Problem is: WM_TAKE_FOCUS present in protocols WM_HINTS not set at all Looks like we are treating that as "globally active" rather than "locally active" (ICCCM section 4.1.7) The ICCCM actually makes no guarantees about what will happen in this case; section 4.1.2.4: Window managers are free to assume convenient values for all fields of the WM_HINTS property if a window is mapped without one. But there was no intentional change here from Metacity - I expect that it has something to do with changes to the code paths for initially reading the values of properties - perhaps if the property wasn't present we changed from calling the callback with META_PROP_VALUE_INVALID to not calling the callback at all.
Created attachment 147305 [details] [review] Correctly initialize window->input field With the change from bug 582639, we no longer call the reload functions for properties that are not initially set, so the initialization of fields in window.c has to match what window-props.c would set for a missing property. There was only one discrepancy, window->input, which needs to be set to TRUE by default (or a window missing a WM_HINTS property won't get focus); we also add explicit initializers for a couple of fields that were getting 0-initialized to the correct default value of FALSE for consistency with the explicit intialization of the rest of the fields. Bug reported by Dominique Leuenberger
Review of attachment 147305 [details] [review]: Might consider deleting all of the ->foo = FALSE bits since we're guaranteed g_object_new does that, but this patch looks fine as is too.
Review of attachment 147305 [details] [review]: x
There's certainly some performance impact from all the iniitalizations to FALSE and NULL, but on the other hand it's easier to understand if all the initializations are there and not just the ones that don't correspond to a bit pattern of 0. Don't think it's worth a major switch anyways. Attachment 147305 [details] pushed as fb45b8f - Correctly initialize window->input field
Thank you all very muc for this speedy resolution. Highly appreciated.