On Wed, 12 Apr 2006, Dominik Vogt wrote:
On Wed, Apr 12, 2006 at 12:02:08PM +0200, Viktor Griph wrote:
On Mon, 10 Apr 2006, Serge (gentoosiast) Koksharov wrote:
On Fri, Apr 07, 2006 at 05:55:25PM -0400, Dan Espen wrote:
When I turn on edit lock, fvwm interprets the first click
(and every click) as a request to move the window.
The window-move feedback window appears.
Yes, exactly. But in other WMs which I tried, double LMB click allows you
to
edit note's text. So, it's xpad behaving incorrectly or FVWM lacks some
functionality?
I don't think niether fvwm nor xpad behaves incorrectly. However, the way
fvwm deals with xpad's request to move the window causes xpad to recive a
focus out event, and then lock the edit box again. So while no party
really doesn't do anything wrong they don't work well together. The focus
change occurs as fvwm grabs the keyboard to allow for keyboard movement of
the window.
I beleive that a client should not expect not to lose focus during a
movement, but the EWMH-specification dodn't state anything about it.
But if xpad triggers an action on the first button press and still
expects to be able to detect double clicks it *is* doing something
wrong.
Well, it is still able to detect double clicks. At lest as long as the
action triggered on button press is finished if the user releases the
button. I wouldn't trust it for an EWMH request to move the window thou.
Some window mannagers might use some otherway to complete the move
operation than releasing the button held down when the move message was
recived. I don't know mush about gtk, but from a quick look at xpad's
source it looks as if it will request movement on buth button press one
and two of a double click, and then allow editing on the second press as
well. However it disaloows editing on focus out events, and it seems that
there is no mode member to check in gdk equivalent of XFocusChangeEvent.
At least it's not a fvwm problem, and I don't think it's convinient to
check for double clicks in that way, but it obviously works.
/Viktor
