On Sun, 25 Sep 2005, Dominik Vogt wrote:
On Sat, Sep 24, 2005 at 11:50:39PM +0200, Dominik Vogt wrote:
On Sat, Sep 24, 2005 at 01:29:52AM +0200, Viktor Griph wrote:
On Wed, 21 Sep 2005, Dominik Vogt wrote:
On Wed, Sep 21, 2005 at 12:05:15AM +0200, Viktor Griph wrote:
2. What is the reason for windows dropped by button 1 to not fall over
to
button release, as windows dropped by button three. I know that not
doing
so allows to keep moving the window until you release the button, but
why
different behaviour for different buttons?
Can you post a config and some instructions to demonstrate the
problen, please?
It's not really a configuration problem, but a code related one. With the
current code placing with button three imedeatly finishes the placement
(i.e fallthroug to button release in the button event, but placing with
button 1 allows the window to be moved until the button is released. I
think it's strange to have two different types of bavaviour depending on
what button you place the window with. Is there any reason for this, if
not, which is the desired functionality?
Yes, there is a reason. I can't fully remember how all of this
works, but look for the work "PlacedByButton3" in the man page.
It occurs in several places.
There is no where in the man paer an explaination why (or even statement
that it is that way) when placing a window, moved without holding a mouse
button, the window may be kept moving until the button is released if
pressing (and holding) button one, compared to the effect that the window
locks at the position it were when the button was pressed if pressing
button three.
The difference between button 1 and 3 has historical reasons.
Normally, actions are triggered by a button release. This allows
to change your mind while the button is pressed and abort the
action by pressing Escape or another mouse button. However, when
you place a window with button 3 this indicates that you want to
resize the window immediately. Hence the move ends and the resize
starts when you press the button. Releasing the button ends the
resize.
Actually what I described is true for button 2, not 3 :-P
Your reply made me see that there was a reason (ability to cancel
palcement after you have pressed the button, and I think I will make all
button press that places windows work as button one currently in that
aspect, and have all canceling buttons work the other way around)
Usually you have a button pressed when you move a window, so
releasing the button ends the motion. That is not true during
initial window placement. In this case the move could end on
button 1 press. However, finding out if any button is pressed
when the move-operation starts is not trivial.
Now, this is a configuration question. I tend to have something like
DestroyFunc MoveFunction
AddToFunc MoveFunction
+ M Move
+ H Raise
+ H Move
+ C Move
which I bind to a button on the title bar. That makes it possible to move
a window by either click once and release the button or my press and hold
the button while moving. If I click and release the button the window will
be moved until I press a button again to place it. With the current code
it will be placeable by button 1, 2 (this is a bug, but need for anyone
to fix it. It will be fixed with the feature I'm almost done with) or 3.
The best approach would be to look at the mask of pressed buttons
when the first ButtonPress or ButtonRelease event arrives. There
are three cases:
1) ButtonPress, only the pressed button is down
2) ButtonPress, another button is down too
3) Button Release
In cases (2) and (3) a button was held when the move started, but
not in case (1).
I myself find the way button 3 woks now the nicest, since I then can place
the window where I wan't it without risk of dragging it away upon a sudden
movement just after release. If you really want button one to keep
dragging the window until the button is released I can hardcode that into
the placemnt changes I'm working on, but I still see no real reason to do
it.
I prefer that everything stays as it is. It's sometimes hard to
remember what it is, but in fvwm almost everything has a reason.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
