On Tue, Mar 11, 2003 at 01:00:49PM +0100, Grzegorz Nieweglowski wrote:
> 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)
The only exception seem to be title buttons. In all other cases
you want a certain set of actions to be executed immediately. If
I did not have to think about backward compatibility, I'd say the
current code does the right thing. After all, you can achieve the
dragging effect with
AddToFunc titlebar_move
+ M Move
Mouse 1 T N Function titlebar_move
But of course we have to think about old configurations too.
> 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.
You forget that the functions working on ButtonPress fail to work
without a context window. You can not pick a target window when
invoking them from a non-window context.
> The *ideal* solution would be to implement correct bindings, like it was in
> the past with "Key -FOO".
Key release bindings are too unreliable. They *will* screw up
the keyboard focus in no time.
> 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.
This functionality is already available through complex functions.
> 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...
It is extremely difficult to code right. I'd be surprised to see
a (fairly complex) window manager that can handle key release
bindings right.
> 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.
Complex functions. See above.
> 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.
Quite contrarily, it has the highest possible priority for me.
These are the first problems that will surface once a release is
made. It is better to catch them before.
Bye
Dominik ^_^ ^_^
--
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]
