On Sun, 25 Sep 2005, Mikhael Goikhman wrote:
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".
Reading through the man page again I must say that it is nowhere stated
how button 2 affects non-initial placement of windows. The Emulate command
description however states that it changes how placement are canceled, and
referres to ManualPlacement for more info. I'm going to go through my
changes to the man page and make sure it currently correctly describes the
way placment works after my changes. I'll then commit them and it will be
easier to see if anything else should be changed. As for now I'm leaving
the control of how windows are resized during manual placement to the
emulate xommand, since I don't have the framework to handle modifiers for
the placement mouse bindings yet.
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.
I think it would do better as a style. Then it would be possible to have
different feedback positions for different windows. Most users would
probably use it in "Style *", but it would be in the spirit of high
configurability to allow it to be set on a per style basis.
/Viktor
