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. > 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 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. > 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. 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 think I have to move the assignment of PlacedByButton to the start of > ButonRelease instead of the end of ButtonPress for best functionality. > I'll not sublit a new patch for just that until I know if you want the > ability to place dragged windows with another button than the drag started > with or not. Regards, Mikhael.
