Re: ManualPlacement/Move Patch
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 +, 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 AltP 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.
Re: ManualPlacement/Move Patch
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 +, 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 AltP 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
Re: ManualPlacement/Move Patch
On 31 Aug 2005 21:42:20 +, 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.) Regards, Mikhael.
ManualPlacement/Move Patch
This is the ManualPlacement/Move patch I'm currently working on. Right now I've done as mush as possible without knowing how placments are intended to be aborted. This patch makes placement of windows using any button possible. The button used to place the window is stored, and can be checked for with the new window condition PlacedByButton. Left to be done is to add a way to cancel placment with the mouse. One thing that has come to my mind is the allow some sort of mouse binding (ala the tearoff button for menus) Or another configure command that controls which buttons are valid for placing, and which that cancel placment. Jsut doing it by button numbers, ignoring any modifiers wouldn't be that hard. But I'm open to suggestions here. /Viktor placement_button.patch.gz Description: GNU Zip compressed data