[Sawfish] CSD and window resizing, once again |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/sawfish Archives
]
- To: sawfish@xxxxxxxxxxxxxxxxxxx
- Subject: [Sawfish] CSD and window resizing, once again
- From: Allin Cottrell <cottrell@xxxxxxx>
- Date: Sun, 30 Aug 2015 15:54:30 -0400 (EDT)
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wfu.edu; s=google; h=date:from:to:subject:message-id:user-agent:mime-version :content-type; bh=y8bqnV9k6FqnYwQxT5/zfa8x4VkbXN3OFlXfNpq2SqY=; b=EiK5tMZi/2dkLaOZDRyypseLXGSb7Nmfv89Sj31PNjAY5oiTwvzW2zBuwRXkgUeJiz nEfkeOAPBHXTGpFTcQ0UGy7VOOB5EqMpWv+miXeRHAw1o7TrLkywCueqYb41RbuqaAHC unzA/+YC7DmT+Xm9GJNYHngtrgYoYWTKGq+S8=
I'm referring back to
http://listengine.tuxfamily.org/lists.tuxfamily.org/sawfish/2015/07/msg00007.html
I've not worked on coding window managers so I'm not confident about
much of the following, but anyway, here goes...
1) The problem I spoke of -- namely GTK CSD windows wanting to
resize themselves arbitrarily when handled under Sawfish -- seems
almost a Heisenbug: when I'm just going about my business it seems
to happen a lot, but when I stop to ask, under exactly what
conditions does this occur?, the problem mostly goes away. I take
this to mean that at some subconscious level I must be using the
mouse a bit differently when I'm thinking about what exactly it's
doing. But I'm not a specially sloppy mouse user and I maintain that
this is a real problem.
2) At a "phenomenological" level, it seems you can tell something
has gone wrong if the cursor turns into a "+" shape: this seems to
mean that a CSD window is now going to resize itself when you next
move the mouse (even if this doesn't make any sense, given what
you've clicked on to date).
3) In the sawfish C code, I took a look at button_press() in
events.c, and the most relevant part seems to be the call to
find_frame_part_by_window(). Here's my understanding: if the button
press relates to a "frame_part" (i.e. part of a window frame) then
it's something that Sawfish should act on. So I put in a print to
stderr when find_frame_part_by_window() returned non-NULL. Most of
the time this triggered under the right conditions (e.g. when I
click somewhere on a Sawfish window-frame), but... it sometimes
triggered when I clicked on a control within a GTK CSD window.
4) It seems to me that find_frame_part_by_window(), as called from
the button_press event, should NEVER return non-NULL if you're
clicking within a CSD window, since no part of that window
corresponds to part of a Sawfish-handled window frame.
5) It therefore seems that there's some conditionality missing from
the Sawfish function find_frame_part_by_window(). Now, as regards
what exactly that conditionality ought to be, I'm afraid I run out
of gas. Except that I think it should involve detecting CSD via mwm
hints. So far as I can tell, there's no mechanism in the Sawfish
code to detect mwm hints, and I suspect that's the problem.
--
Allin Cottrell
Department of Economics
Wake Forest University
--
Sawfish ML