[Sawfish] Testing a workaround for GTK3 random resizes

[ Thread Index | Date Index | More lists.tuxfamily.org/sawfish Archives ]


Updated a program, and it uses GTK3 now. And so managed to see what
others mentioned a year or so ago about mouse getting stuck into
resize mode. After some web searchs it seems the issue hit other
window managers and clients (audacious, xfce4, i3, openbox, etc) in
diverse ways (crashes, jumps, resizes, etc). With that info, I tried
something. So far, it works.

See attached file (for simplicity) and patch ready for git am (for
easy integration into tree). In case list drops them use this diff
adapted to latest Sawfish tarball, just patch the file
sawfish_1.12.0/lisp/sawfish/wm/state/wm-spec.jl with the following:

--- wm-spec.jl	2017-07-11 05:09:12.356975626 +0200
+++ wm-spec.jl-1.12.0	2016-08-13 10:26:23.000000000 +0200
@@ -58,7 +58,6 @@
   (defconst _NET_WM_MOVERESIZE_MOVE 8)
-  (defconst _NET_WM_MOVERESIZE_CANCEL 11)
   (defconst _NET_WM_STATE_REMOVE 0)
   (defconst _NET_WM_STATE_ADD 1)
@@ -95,7 +94,6 @@
@@ -524,11 +522,7 @@
 			    ((eq mode _NET_WM_MOVERESIZE_SIZE_RIGHT)
-                 ;; XXX ignore CANCELs for now
-                 ;; XXX see reports about GTK3 going into resize randomly
-                 ;; XXX probably need to rework all this block
-                 (if (not (eq mode _NET_WM_MOVERESIZE_CANCEL))
-                     (resize-window-interactively w))))))
+		 (resize-window-interactively w))))))
 	 (set-number-of-workspaces (aref data 0)))

You can also put a patched file in ~/.sawfish/lisp/sawfish/wm/state/
and it will override the default one. Tests can be done live with
",reload sawfish.wm.state.wm-spec" in sawfish-client. No need of
(re)building SF to just test the idea.

Now I get moves when dragging (not plain click) from different blank
spaces (if that is also a bug and not WinAmp-philia... *sigh*). I
tried gtk3-widget-factory program and even managed to drag by clicking
with care between the client top buttons. In Firefox space in menu &
tab bar allows moving, but other places don't. What rules decide which
empty space becomes "move all window" and which doesn't? Where are the
visual clues to represent it? Resize areas are also invisible (near
window edges), but at least the cursor changes when passed over them.

I am still trying to figure the technical whys and hows behind the new
thing (the non technical points to CSD and the WinAmp way, because
their way or the highway). Probably best explanation so far is
With that and the spec, it seems to be something like user pressing
Esc (SF default) but initiated via client program.

Inspiration for patch came from things like:
Just in case anyone wants to investigate more.

Please test and report results,

Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/