On Thu, 1 Sep 2005, Mikhael Goikhman wrote:
On 01 Sep 2005 07:10:25 +0200, Viktor Griph wrote:
On Wed, 31 Aug 2005, Mikhael Goikhman wrote:
On 31 Aug 2005 21:42:20 +0000, Mikhael Goikhman wrote:
This is not enough, To emulate the current logic you should also add:
Mouse 1 P N CancelPlacement
Mouse 2 P N CancelPlacement
I.e. if you started the Move using button 1, then button 2 cancels it and
vice versa. Since you can't press button 1 again while dragging using
button 1, these binding would be ok although not immediately intuitive.
Well, actually these will not be ok if the Move is started on mouse click
(not drag) or on key press. So either we conclude your idea can't work or
we may try to somehow save it using, say, this extension:
Mouse 0 P N PlaceWindow
Mouse 1 P(d0) N CancelPlacement
Mouse 2 P(d0) N CancelPlacement
Mouse 1 P(d1) N PlaceWindow
Mouse 2 P(d2) N PlaceWindow
Mouse 2 P(c) N CancelPlacement
Where "dN" means dragging using button N and "c" means mouse click or key
press. No, I am not a big fan of such idea, but I am not against either.
(I think the current logic about Move cancelation is good.)
I've not changed the logic for dragging of windows. IT's only the
interactive movment that my patch affects. I maybe should make that more
clear in the manual page. I did see no need to try to change the drag
logic, as all feeling on how it should work matches with how it currently
does. I.e you hold down the button the drag started with and calcel the
movement by pressing any other button.
Well, this is not exactly what happens now. If you drag using mouse
button 1 or 2, then button 3 places the window, rather than cancels.
I suppose Dominik intentionally did it to allow PlacedByButton3 using
dragging too.
Yes, you are right. I missed that while rewriting the logic. It shouldn't
be that hard to handle.
If you want to be able to use some buttons for placing the window evenif
it is being dragged it could probably be conficured by also changing
PlaceWindow to always place the window and add PlaceWindowInteractive and
PlaceWindowDrag as well as CancelPlacementDrag/CancelPlacementInteractive,
and maybe also add CancelPlacement for completness, even if it would be
the same as -. However, I think that just would comlicate things. But if
you think it would be better to be able to define that you want to be able
to place a window you are dragging by clicking on another button as well I
can try to add that.
You see, this is not enough. There should be at least the special notion
of "the same button that started the drag". The bindings quoted above
should be implemented in one or another way (either configurable or
hard-coded).
I see no reason to ever want to have the button that started the drag to
cancel a move. (And it would require new tests in the ButtonRelease even
handling to implement) What seems to be the spimplest to solution is to
"hardcode" (actually not handle specially) that if you release the button
the move started with the window is placed - regardless of whatever
bindings you have set up for Pressing the button during the move.
Then I would only need for one more binding action. And possible some
deactivating actions. The only thing that would have to be defined, in one
way or another, is buttons pressable without movement cancelation while
dragging. That together with buttons that can be used to place
interactivly moved windows also defins buttons canceling movement.
Mouse 0 P N PlaceWindow
Mouse 1 P N CancelPlacementDrag
Mouse 2 P N CancelPlacement
Would then match the current default
Suggested allowed Actuiions would be
PlaceWindow / PlaceWindowInteractive / PlaceWindowDrag
CancelPlacement / CancelPlacementInteractive / CancelPlacementDrag
With - being equvalint of CancelPlacement
PlaceWindow equvalent of PlaceWindowInteractive and PlaceWindowDrag
with the CancelPlacement counterparts. If you see any case where that
wouldn't be enough (given that the check is for button press and not
release, and you can't press a button being held).
I am not sure the flexibility you want to add is either needed or easy to
implement (if possible at all). It is like to allow a user to create a
new menu feel (key and mouse bindings) using a configuration. The menu
code is messy and there are many actions and special cases already
without configurable bindings. I don't know whether users want or have
the ability to replace the placement feel with some usable alternative.
Can you partition the exact current feel into configurable commands and
estimate the work needed to implement this? Something along lines:
Key Return P A PlaceWindow
Key Space P A PlaceWindow
Key Escape P A CancelPlacement
Key Right P A MoveWindow +10p 0
Key Right P S MoveWindow +100p 0
Key Right P C MoveWindow +1p 0
Key Alt P C ToggleSnapAttraction # well, this is a modifier, not a key
If you show this is possible, then we may think to add a half-hardcoded
command like CancelWithOppositeButton1Or2 to support the "drag" mode.
I don't really see a need to try to reimplement the entire placement feel
with keybindings. As soon as I start looking at modifiers and/or keys I
would need a mush more complex binding system then the one I'e
been looking to implement, to just change the mouse placement logic. To do
something more than the control of buttons useanle for placement/cancel
would require me to learn the current fvwm code more and fully understand
how the true bindings work. It is possible that I'll be looking into that
next summer, but it's nothing I'm goig to do now.
How should the PlacedByButton n condition be affected by a drag move?
I think the flags should be immediately reset on any Move and only set
when the placement was not canceled.
This feels most convinient to me too. I'm thinking of a short syntax for
(!PlacedByButton 1 !PlacedByButton 2 ... !PlacedByButton n) that would
match windows that had placement canceled or done by fvwm. Maybe just
!PlacedByButton with no argument, or use button 0 for it.
Also, just for info, I think it is acceptable that currently "Pick Move"
and "Move" work differently in no window context. The first does
interactive Move. The second starts dragging on mouse click and does
interactive Move on key click (Enter).
I've no plans on changing how moves are started.
