Ad blocker interference detected!
Wikia is a free-to-use site that makes money from advertising. We have a modified experience for viewers using ad blockers
Wikia is not accessible if you’ve made further modifications. Remove the custom ad blocker rule(s) and the page will load as expected.
|Browse all patches|
Another KDE system tray fix. The diff is against 1.3.2. The essential content is the one-line change in wm-spec.jl but I am bundling it with some other cleanups.
As of 3.5.8, KDE has still not completely replaced their old wm-dependent system tray protocol with the freedesktop.org one. They just kluged it: KDE apps continue to use the old protocol, but a kded module called kdetrayproxy tries to perform the part of the wm in that protocol and docks the tray icons using the freedesktop.org protocol.
It turned out that kdetrayproxy watches for new windows not by monitoring MapNotify events but by monitoring changes in the _NET_CLIENT_LIST root window property. Sawfish added windows to that list at a very early stage, before they had even been decorated. The result was kdetrayproxy being confused by the events caused by Sawfish decorating the window and Sawfish being confused by interference from kdetrayproxy. This patch delays the update of _NET_CLIENT_LIST to map-notify-hook. At that time the new window is already mapped (unless it starts iconic - map-notify-hook is executed even in that case).
This patch also fixes a potential problem of reparent-notify-hook getting called with a removed window. I have never seen anyone use that hook though. I also modified unmap_notify so that removal of WM_STATE is the very last action there. That property change indicates to the client that we are done processing the window withdrawal. The client may then reuse the window, e.g., remap it.
You can also get this patch with Git from http://www.elisanet.fi/tkorvola/sawfish.git, branch kde-tray-fix-2.
diff --git a/lisp/sawfish/wm/state/wm-spec.jl b/lisp/sawfish/wm/state/wm-spec.jl index 4df1c2e..08ea616 100644 --- a/lisp/sawfish/wm/state/wm-spec.jl +++ b/lisp/sawfish/wm/state/wm-spec.jl @@ -630,7 +630,9 @@ (add-hook 'workarea-changed-hook update-workspace-hints) (add-hook 'configure-notify-hook update-on-configure-notify) - (add-hook 'add-window-hook update-client-list-hints) + ; Better not expose work in progress. map-notify-hook gets + ; called after this anyway. + ;(add-hook 'add-window-hook update-client-list-hints) (add-hook 'destroy-notify-hook update-client-list-hints) (add-hook 'map-notify-hook update-client-list-hints) (add-hook 'unmap-notify-hook update-client-list-hints) diff --git a/src/events.c b/src/events.c index 4b58c7c..bd9a058 100644 --- a/src/events.c +++ b/src/events.c @@ -799,10 +799,15 @@ reparent_notify (XEvent *ev) w->reparented = FALSE; XRemoveFromSaveSet (dpy, w->id); + Fcall_window_hook (Qreparent_notify_hook, + rep_VAL(w), Qnil, Qnil); + /* Not us doing the reparenting. */ remove_window (w, FALSE, FALSE); } - Fcall_window_hook (Qreparent_notify_hook, rep_VAL(w), Qnil, Qnil); + else + Fcall_window_hook (Qreparent_notify_hook, + rep_VAL(w), Qnil, Qnil); } } @@ -887,14 +892,16 @@ unmap_notify (XEvent *ev) } Fcall_window_hook (Qunmap_notify_hook, rep_VAL(w), Qnil, Qnil); - XDeleteProperty (dpy, w->id, xa_wm_state); - /* Changed the window-handling model, don't let windows exist while they're withdrawn */ if (being_reparented) reparent_notify(&reparent_ev); else remove_window (w, FALSE, FALSE); + + /* This lets the client know that we are done, in case it wants + to reuse the window. */ + XDeleteProperty (dpy, ev->xunmap.window, xa_wm_state); } }
Community's reasons for inclusion or rejection Edit
Patch submitters, please vote also! Yes, obviosuly your vote will be positive, but it's the place to give your explanation why this patch is good for all Sawfish users, and why it is correct - good reasons for inclusion.
When voting anonymously please write your name, so that it can be associated with your posts on the mailing list. If you are logged in you can sign yourself by typing four tilda characters: ~~~~.
- vote: yes. The whole kdetrayproxy scheme is rather flaky, but results with this patch seem encouraging so far. - Tkorvola 19:27, 13 February 2008 (EST)