Subject: Latest functable.c changes

From: Grzegorz Nieweglowski <[email-masked]>
Date: Tue, 11 Mar 2003 08:49:23 +0100

Concerning: FVWM, current CVS version

I have a request: 
_Please_ make the functable.c the way it was before 2003-03-03.

Why? Let me explain:
On that day Dominik introduced a slight modification ("trigger
on ButtonPress for many of the functions"), and it's been causing trouble
ever since. I don't know what was the purpose of those changes, but I know
one for sure - the "decoration button pressed-in" behaviour has gotten
really bad.

Example: Imagine you have a title bar with a "Close" button. In the good old
days if you pressed the button, the "Close" action wouldn't get executed
until you actually released the mouse button. This allowed fvwm to show the
alternate "ActiveDown" decoration, and also to cancel the "Close".

But now things have changed - it is enough for the user to press the button,
the action gets executed immediately. Fvwm has hardly time to draw the
"pressed" button pixmap, the user just sees it "flash" for a microsecond
- so the Up and Down button states are quite useless (if you can't see it
clearly, then it's useless. And I can't see it clearly.)

And secondly, you can no longer cancel the function after pressing the
button. Which is a bad thing - canceling the "Close" action in the last
second has saved some of my windows.

If those two arguments aren't convincing, then I have a third one - all
other windowmanagers do it the other (old-fashioned) way round. You click,
the titlebar button gets pressed, and it _waits_ for the user to release the
button (or cancel the action).

I presume that Dominik was (and still is) following some Brilliant Master
Plan, and simply overlooked some of the consequences, but the current
"pressing is enough to trigger" behaviour really breaks many things when it
comes to titlebar buttons.

Dominik? Could you _please_ explain what you're trying to achieve?

-- 
\hoppke
(Grzegorz Niewęgłowski)
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-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 11 Mar 2003 09:29:35 +0100

> Dominik? Could you _please_ explain what you're trying to achieve?

I changed it because some functions worked on ButtonRelease (e.g.
iconify) and others on ButtonPress (e.g. Move).  All the
ButtonRelease functions did not work when invoked outside a window
context:  the window selection cursor just flashed and whatever
was under the pointer at that time was immediately selected as the
context window - usually no window, making the action fail.

But as we see now, this removed one bug and made another one
worse.  I will try to fix both problems at the same time.  Perhaps
the Press vs. Release decision can be made based on whether there
already is a context window or not.

Bye

Dominik ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 11 Mar 2003 09:58:08 +0100

> comes to titlebar buttons.

Should be fixed now.  Please report back if you notice any
unexpected behaviour.

Bye

Dominik ^_^  ^_^

---

From: Grzegorz Nieweglowski <[email-masked]>
Date: Tue, 11 Mar 2003 13:00:49 +0100

> Should be fixed now.  Please report back if you notice any

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.

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 11 Mar 2003 13:30:35 +0100

> especially because the titlebar can be drawn "pressed-in", just like

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.

> 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 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

This functionality is already available through complex functions.

> 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.

> I guess that sane mouse handling is more urgent.

Complex functions.  See above.

> 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 ^_^  ^_^

---

From: Grzegorz Nieweglowski <[email-masked]>
Date: Tue, 11 Mar 2003 14:47:54 +0100

Dominik Vogt wrote:
> After all, you can achieve the dragging effect with
> 
>   AddToFunc titlebar_move
>   + M Move

Well, the complex function is a acceptable solution.

> invoking them from a non-window context.

Oh, you're right. 

> a (fairly complex) window manager that can handle key release

And Sawfish is no exception. It actually uses libgdk to get the events, and
this was also one of the reasons why I dumped it for fvwm. Whilst it works
quite fine most of the time, libgdk is unable to handle mouse buttons >3
correctly. It recognizes "clicks", but not "drags". So my side buttons could
only invoke functions that didn't require cursor movement. Popping up menus
etc. But I wanted a WM that would allow me to drag a window with Mouse5. And
fvwm could.

>> This mail is more a feature request than a bug report, and I understand
>> that it has very low priority right now.
> 

So it works OK now, but some commands need to be wrapped in complex
functions. That isn't much trouble... the important thing is: it works.