Subject: Notification: incoming/476

From: [email-masked]
Date: Sat, 9 Oct 1999 18:42:36 -0500 (CDT)

FVWM Bug Tracking notification

new message incoming/476

Message summary for PR#476
	From: [email-masked]
	Subject: move/resize position/size window
	Date: Sat, 9 Oct 1999 18:42:34 -0500 (CDT)
	0 replies 	0 followups

====> ORIGINAL MESSAGE FOLLOWS <====

---

From: Mikhael Goikhman <[email-masked]>
Date: Mon, 11 Oct 1999 01:47:19 +0200

On 09 Oct 1999 18:42:36 -0500, [email-masked] wrote:
> Full_Name: Stuart Anderson
> Version: 2.3.9
> 
> The handy window that pops up in the upper left corner to notify the
> user of the current window position/size when moving/resizing a window
> does not become active when first selecting a window. It shows up
> once the cursor has been moved to indicate a change. However, I found
> it useful to see the initial value immediately upon selecting a window
> as is done in 2.2.

There was introduced MoveThreshold command since 2.2, so if you don't drag
a window fvwm can't decide whether it's Move or Click (if you have both).
Note, MoveThreshold 0 does not solve your problem, fvwm will ignore Click.

I dislike this too, but there is a solution for this problem and I am ok
with it. Put:
 + H Move

into your function and you will get a feedback window immediately
(after ClickTime seconds) as in 2.2.
Generally, you should duplicate all Move triggers (add Hold trigger):
 + M Action
 + H Action

in all your functions if you don't like fvwm waiting.

Regards,
Mikhael.
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 11 Oct 1999 02:45:10 +0200

> a window fvwm can't decide whether it's Move or Click (if you have both).

This has nothing to do with the MoveThreshold command.  It only made the
previously hardcoded value configurable.

> I dislike this too,

Like it or not - it's not going to change unless you can explain
to me why this automatic timeout is easier to understand or more
usable.  People with clumsy fingers (like me) may really have a
problem with this timeout.  On the other hand you can still get
the behaviour you were used to.

Bye

Dominik ^_^

-- 
Dominik Vogt, Hewlett-Packard GmbH, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/14-4596, fax: 07031/14-3883, [email-masked]
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Mikhael Goikhman <[email-masked]>
Date: Mon, 11 Oct 1999 03:17:27 +0200

> previously hardcoded value configurable.

I know this, but it is easier to explain by referring to this command.
BTW, I received your (better) answer immediately after mine.

> the behaviour you were used to.

I don't want it to be changed, I fully understand this defense against
move. I also often move an icon by a mistake (and then it becomes
sticky).

fvwm is wonderful, because it serves opposite tastes. The reason I don't
like the new behaviour is that in fvwm-2.2 the ClickTime was a time
before a click was decided, now it is not. I used to the old behaviour.
Just a matter of taste.

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 11 Oct 1999 03:34:32 +0200

On Mon, Oct 11, 1999 at 03:17:27AM +0200, Mikhael Goikhman wrote:
> before a click was decided, now it is not.

I think this was always an undocumented application of ClickTime. As
far as I can remember the man page stated that it was used for double
clicks, not single clicks (correct me if I'm wrong).

> I used to the old behaviour.  Just a matter of taste.

I hope that only a few people notice it at all.  In my eyes it's a
big improvement, but if somebody relied on the old behaviour it may
annoy him or her.  BTW, can you still remember the uprise when I
changed the menu selection cursor?  I bet nobody notices the new
cursor anymore :-)

Bye

Dominik ^_^

---

From: Michael Han <[email-masked]>
Date: Sun, 10 Oct 1999 21:23:13 -0700

Previously...
>clicks, not single clicks (correct me if I'm wrong).

Hmm. I remember fussing over this change, mostly because I had always
read the manpage as describing the existing behavior accurately. Hmm,
found this in fvwm2.1, CVS revision 1.1:

    .IP "ClickTime \fIdelay\fP"
    Specifies the maximum delay (in milliseconds) between a button press
    and a button release for the Function built-in to consider the action
    a mouse click.  The default delay is 150 milliseconds.

Anyway, it's no big deal, given that to my way of thinking "H" means
the same thing as "C" used to.
-- 
[email-masked]                         http://www.best.com/~mikehan/
coffee achiever                              San Francisco, California
A double negative is a no-no.
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Mikhael Goikhman <[email-masked]>
Date: Mon, 11 Oct 1999 06:29:32 +0200

> clicks, not single clicks (correct me if I'm wrong).

I correct you. In fvwm-2.2 a 'M'ove was considered after the ClickTime
seconds, never a 'C'lick.

> changed the menu selection cursor?  I bet nobody notices the new

I always defined all cursor shapes (and later cursor colors).
I use red-on-white left_ptr in most cases if someone worries.
Relying on defaults is a way to be involved in flame wars. :)
I agree with any default, accepted by at least one man (woman?).

Regards,
Mikhael.