On 25 Sep 2005 01:18:29 +0200, Viktor Griph wrote: > > On Sun, 25 Sep 2005, Dominik Vogt wrote: > > >On Sun, Sep 25, 2005 at 12:32:55AM +0200, Viktor Griph wrote: > >> > >>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. > > > >(It would be helpful to agree on common terms here: pressing a > >mouse button means to hold down the button without releasing it, > >while clicking a button means to press it and release it > >immediately.)
(But then terms like "on-press action", "on-release action" are meaningless. I think we may agree that in the context of the term "release", the term "press" means just that, not "hold" or "drag".) > >What is the bug you think of? I don't see anything I would not > >expect: > > > > * When I press the button and start moving immediately, > > releasing the button places the window, pressing button 3 > > places the window and any other button aborts the action. > > > > * When I press the button and hold for a moment before moving, > > it works exactly the same (except that the window is raised). > > > > * When I click (press and release) a mouse button, the move > > operation starts. Now, clicking button 1 and pressing button > > 3 places the window and pressing button 2 aborts the > > operation. > > My initial question was if it was desired to have different behaviour for > button 1 and 3 (or any other button). Like oyu say clicking button one > places wthe window, but pressing button 3 places it. The man pge does > nowhere state the difference, and unless you object I'll change it all to > click -> place window respectivly press -> abort operation. I already mentioned this in another message. I think it is acceptable to handle a free Move as if it is done by dragging with Mouse 1. So, yes, button 1 is special for the free Move (just pressing it does not finish the operation, unlike button 3). Personally, I see no problems with this, but I am also not against to make button 1 non special, if someone cares. > >As far as I know this is all documented in the man page, although > >it may not be very intuitive. > > > >(All of this works with "Emulate Mwm"; with "Emulate Fvwm", > >pressing button 2 places the window instead of aborting the > >operation). > > That is the 'bug' I referre to. I'm not using "Emulate Mwm", so I've never > been able to cancel a move with button two. It is documented, so it is not a bug, but I agree that it is bad that "Emulate fvwm" does not allow canceling using Mouse 2. I never liked it, but then I use "Emulate mwm", so I don't care enough. I think, this feature should not be configurable (actually it may be configurable by Move bindings suggested by Voctor) and should be excluded from "Emulate". Most of the users use Emulate in order to change the feedback window position. I think this feature deserves its own configuration command. I prefer to introduce "FeedbackWindowPosition pos" command that accepts a geometry or "center", "TopLeft" and similar arguments. Then we may suggest usage of this new command rather than enigmatical Emulate. Regards, Mikhael.
