Dominik Vogt wrote:
> Should be fixed now. Please report back if you notice any
> unexpected behaviour.
Sure. Well, the buttons work fine now, thank you.
But some new bugs were introduced. Try doing something like
Mouse 1 T N Move
And then dragging the window (by the titlebar).
Well, normally you don't see it. The 'default' Mouse1<->Titlebar binding
works as expected. But if you redefine it, it goes crazy.
It's not much of a trouble for most people, but I am using a 5-button mouse
(plus wheel), and have been happily using those two extra side buttons to
move/resize windows.
<snippet>
Mouse 6 WTI A Move
Mouse 7 W A Resize
</snippet>
But now it won't work. In the past I could drag the window by simply
pressing and holding Mouse6 anywhere in the window (and moving the mouse,
of course). And that was very nice. Now the "move" function kicks in when
I release the button. And then I have to move the mouse, and press mouse
button _1_ to acknowledge the whole transaction. Which renders the whole
function very ugly.
It seems there's no simple solution to this. Context-dependency seems a nice
way out, but I don't know if that's that easy as it seems. In titlebar
buttons the functions should (i guess) get executed on a ButtonRelease. In
the "main" titlebar area (titlebar, but not a "normal" button) it should be
either ButtonPress (e.g. "Move"), or ButtonRelease ("Raise/Lower",
especially because the titlebar can be drawn "pressed-in", just like
a button)
So it already shows that context-dependency won't do the trick. So _maybe_
the best thing to do would be to revert the changes, and accept the idea
that some functions work on ButtonPress, and others on ButtonRelease. And
maybe we should simply start thinking which functions should be triggered on
"press", and which on "release". It isn't perfect, but it seemed to work.
Mostly. And it would be a good temporary solution.
The *ideal* solution would be to implement correct bindings, like it was in
the past with "Key -FOO". Maybe new commands, like KeyPress/KeyRelease, and
MousePress/MouseRelease, so that the user could decide how it should work.
That would a very flexible solution, but I guess also the most difficult to
implement. As I see it's no longer possible to assign a action to
KeyRelease, so suggesting to implement it on an even wider basis (including
Mouse and changing some of the Functions engine) is, well, not so good.
But I still think that a good KeyPress/KeyRelease, MousePress/MouseRelease
would be the solution to many problems. Sawfish is a nice example - in that
WM the user has access to a set of functions. The user binds events to
contexts not using simple Mouse/Key functions, but a series of commands,
including some that recognize double/triple clicks&releases. Sawfish however
doesn't recognize KeyRelease...
Alright, so 'Key -FOO' didn't work out and got removed from fvwm. Would doing
a MousePress/MouseRelease variations of the "Mouse" command be just as
difficult? Because such commands could be a nice, clean and flexible solution
to those issues. Keyboard handling could use those features as well, but
I guess that sane mouse handling is more urgent.
I don't know the internals of fvwm, but it would probably be a major change.
It would be a Good Thing, though.
This mail is more a feature request than a bug report, and I understand that
it has very low priority right now.
--
\hoppke
http://lubuska.zapto.org/~hoppke/
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
