Subject: FVWM: window resize in 2.5.7

From: "Jules Alberts" <[email-masked]>
Date: Wed, 23 Jul 2003 09:55:17 +0200

Hello everyone,

I just did an upgrade from 2.4 to 2.5.7 and now I have some strange 
window resize behaviour. When I place the mousecursor on the border of 
any window and drag, nothing happens. When i release the button, I can 
resize until I click again. The same happens with a single click o a 
border, I can resize until I click again.

My rc's haven't changed when I did the upgrade, is this normal 2.5 
behaviour? How can I get back to a "normal" window resizing? Thanks!
--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 23 Jul 2003 10:14:21 +0200

> behaviour? How can I get back to a "normal" window resizing? Thanks!

It's a side effect of a bugfix we are still discussing.  We have
not yet decided whether we leave it this way in 2.6 or switch back
to the old (wrong) behaviour.  To be safe, you should replace

  mouse 1 sf n resize

(or similar) with

  AddToFunc my_resize
  + I resize
  mouse 1 sf n my_resize

This works as you would expect.

Bye

Dominik ^_^  ^_^

---

From: Ben Winslow <[email-masked]>
Date: 23 Jul 2003 04:13:33 -0400

> behaviour? How can I get back to a "normal" window resizing? Thanks!

What you're probably seeing is the result of a bugfix (i.e. the old way
isn't supposed to have worked, but it did, and it seems that it's been
widely used.)

On Mon, 2003-03-17 at 05:01, Dominik Vogt wrote:
> I see, this change is not going to make me happy.
> 
> BEGIN THEORY
> 
> For some reason, a more or less random number of commands worked
> on button press while other commands worked on button release.
> The first type did not work when invoked outside a window context,
> for example on the root window:
> 
>   mouse 3 a sc move
> 
> just flashed the selection cursor, selected the root window and
> beeped.  The right way to have move-on-press is
> 
>   AddToFunc move_on_press
>   + I Move
>   mouse 1 W 3 function move_on_press
> 
> In the future, I would like to remove the difference between both
> types of commands.
> 
> END THEORY
> 
> So much for the theory.  Unfortunately, many people rely on the
> old, broken behaviour.  It should be relatively easy to write a
> script that changes your config, though.

So basically, the fix is to put your move command into a function, and
then call the function.  For the chronically lazy or those who aren't
terribly familiar with their fvwm configuration, I made a script a while
back to do the conversion; it's available at
http://themuffin.net/fvwm-mousecmd-convert.awk  It should, at least,
make the required changes obvious so that you can do it yourself if you
prefer.

-- 
Ben Winslow <[email-masked]>

---

From: "Jules Alberts" <[email-masked]>
Date: Wed, 23 Jul 2003 10:49:24 +0200

Op 23 Jul 2003 (10:14), schreef Dominik Vogt <[email-masked]>:
<snip>
> This works as you would expect.

And it does, thanks! Another question (also new behaviour since the 
upgrade). When I try to move gkrellm (2.1.12) it stays where it is 
until I release the mousebutton, then it pops at the position of the 
mousecursor. Any ideas? Thanks!
--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 23 Jul 2003 10:59:05 +0200

> mousecursor. Any ideas? Thanks!

Do you mean by clicking on the internal title of the gkrellm
window?  I don't know, it works for me.  It's probably a bug in
gkrellm.

Bye

Dominik ^_^  ^_^

---

From: "Jules Alberts" <[email-masked]>
Date: Wed, 23 Jul 2003 11:55:22 +0200

Op 23 Jul 2003 (10:59), schreef Dominik Vogt <[email-masked]>:
<snip>
> window?

Actually it's the hostname of my box inside gkrellm, and gkrellm is 
"NoTitle'd".

It does something else that's weird. If I click hostname and keep mouse 
button 1 pressed, after about 1.5 seconds the PC speaker beeps and I 
can move gkrellm normally. If I click hostname and move the 
mousepointer (still keeping mouse button one pressed), after the same 
time, gkrellm pops to the new cursorposition.

Other apps don't do this (not even xmms).

> I don't know, it works for me.  It's probably a bug in
> gkrellm.

Could be, but before I upgraded fvwm it worked as expected and I didn't 
change anything gkrellmish.

I tried changing some of gkrellm internal properties (sticky state 
etc.) but that doesn't change anything. Strange...
--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 23 Jul 2003 12:31:39 +0200

> Actually it's the hostname of my box inside gkrellm, and gkrellm is 

That's what I meant.

> can move gkrellm normally.

Gkrellm is probably trying to grap control of the mouse pointer
but some other application has already grabbed it - most likely
fvwm itself.  Do you have any mouse bindings on the 'W' indow
context?  A la

  mouse 1 w n ...

If fvwm has grabbed the pointer, that is because you somehow told
it to do so.

> If I click hostname and move the 

Bye

Dominik ^_^  ^_^

---

From: Ben Winslow <[email-masked]>
Date: 23 Jul 2003 08:07:32 -0400

> > etc.) but that doesn't change anything. Strange...

Since I could reproduce this, I decided to track it down...

fvwm is indeed trying to grab the pointer and failing [XBell() at
functions.c:992 in execute_complex_function], however, it's not because
of anything Jules has done...

In ConfigFvwmDefaults, an EWMHActivateWindowFunc function is
defined--whenever gkrellm is clicked on to be moved (I think GTK2 is 
what's actually causing this to happen), EWMHActivateWindowFunc is
called, causing this problem.

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 23 Jul 2003 14:36:59 +0200

> called, causing this problem.

Which gkrellm version?  It doesn't happen with 1.2.10.  Anyway,
this is a gkrellm bug:

An application can not expect that the window manager processes
any requests (_NEW_WM_ACTIVE_WINDOW client message in this case)
while the server/pointer/keyboard is grabbed.  This should be
fixed in gkrellm.  Could someone report this to the developers?

Bye

Dominik ^_^  ^_^

---

From: Ben Winslow <[email-masked]>
Date: 23 Jul 2003 09:07:39 -0400

> fixed in gkrellm.  Could someone report this to the developers?

It happens to me with gkrellm 2.1.14 (gtk 2.2.2) and a CVS snapshot from
Apr 27 (as well as today.)

---

From: "Jules Alberts" <[email-masked]>
Date: Mon, 28 Jul 2003 08:49:35 +0200

Op 23 Jul 2003 (14:36), schreef Dominik Vogt <[email-masked]>:
<snip>
> Which gkrellm version?  It doesn't happen with 1.2.10.  Anyway,

Over here it's version 2.1.12, I got it from freshrpms.net

> message to [email-masked]. To report problems, send mail to
> [email-masked].

Hello Bill,

Last week I seem to have found a bug in gkrellm. I found your email 
address at the gkrellm site and took the liberty of mailing you this 
snip of a thread on the fvwm mailing list.

I also post this to the mailing list, because if you have technical 
questions, I probably won't be able to answer :-)

Regards,

-- 
Jules Alberts

----------------------------------------------------------------------

----------------------------------------------------------------------

---

From: Olivier Chapuis <[email-masked]>
Date: Mon, 28 Jul 2003 15:52:15 +0200

On Wed, Jul 23, 2003 at 02:36:59PM +0200, Dominik Vogt wrote:
> fixed in gkrellm.  

Maybe. But it is not always needed to grab the pointer when we execute
a complex function. So, I suggest that when fvwm fail to grab the
pointer for executing a complex function we do not abort the function
execution.  This fix Jules problem (that I can reproduce, and it
happens the same thing with the Mozilla resize grip).  What do you
think?

Note that the "problem" does not arise to me with 2.5.7 and I think
that it appears _for me_ during your recent work on ConfigureRequest
Event. However, it seems that Jules use 2.5.7.

Regards, Olivier

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 28 Jul 2003 16:11:15 +0200

> happens the same thing with the Mozilla resize grip).  What do you

I think it's a bad idea.  It is practically impossble to guess
whether a function needs to grab the pointer before executing or
not, and it depends on what other application do too.  For
example, if an application warps the pointer while a function is
executed, all sorts of strange things can happen.

> Event.

I don't think so.  That has nothing to do with the problem.

> However, it seems that Jules use 2.5.7.

Bye

Dominik ^_^  ^_^

---

From: "Jules Alberts" <[email-masked]>
Date: Mon, 28 Jul 2003 16:34:19 +0200

> I don't think so.  That has nothing to do with the problem.

I agree. I have the problem now with 2.5.7, before the upgrade I 
didn't.

---

From: Olivier Chapuis <[email-masked]>
Date: Mon, 28 Jul 2003 19:37:17 +0200

> executed, all sorts of strange things can happen.

In fact I can reproduce the gkrellm problem only on certain condition:
I've a FvwmEvent running which executes a complex function on each
module events. fvwm bell and abort a complex function which is run
with a raise_window (gkrellm) or a configure_window (Mozilla resizing
with grip). Also I've an FvwmEvent which auto shade a FvwmButtons with
a delay via leave_window (with the schedule command and a "shade"
complex function). When, I leave the FvwmButtons and popup a menu of
an application before auto shade the "auto shade" complex function
xbell and abort.

So I really think that by default we should not abort complex
functions when we cannot grab the cursor. Maybe a Grab prefix or a
Grab function (with automatic ungrab) should be introduced, but I
_think_ that the case where we need to grab is exceptional. Do you
have a real life example (say in your fvwm config)?

> I don't think so.  That has nothing to do with the problem.

Yes, Sorry, no FvwmEvent running when I do the test with 2.5.7.

Regards, Olivier

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 29 Jul 2003 10:35:49 +0200

> have a real life example (say in your fvwm config)?

The pointer *must* be grabbed during function execution.  We have
made various attempts to ignore this in the past, and they all
ended in disaster.  For example, if the user can click in windows
(or release a button - quite likely during function execution) she
can cause EnterNotify and LeaveNotify events, screwing up scripts
that make tricky use of Raise/Lower/Focus.

Bye

Dominik ^_^  ^_^

---

From: Olivier Chapuis <[email-masked]>
Date: Wed, 30 Jul 2003 10:08:32 +0200

> that make tricky use of Raise/Lower/Focus.

But it seems to me that we need grabing only if the function has
a non immediate context? It is simple to detect this situation and
to non grab (or grab fast, i.e., try to grab only once and do
not abort if grabbing fail) for "immediate only" function. I've
writting such a patch and cannot reproduce problem.

What do you think?

Regards, Olivier

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 30 Jul 2003 11:52:57 +0200

On Wed, Jul 30, 2003 at 10:08:32AM +0200, Olivier Chapuis wrote:
> a non immediate context?

No, that is wrong.

  AddToFunc foo
  + I do this
  + I do that
  Mouse 1 t n foo

is no better than

  AddToFunc bar
  + C do this
  + C do that
  Mouse 1 t n bar

For example, look at this:

  Style * SLoppyFocus
  AddToFunc next_focus
  + I next focus
  + I next warptowindow 0 0
  mouse 1 t n next_focus

If the pointer is not grabbed, the following may happen:

 1)  User presses mouse button on window title (triggering
     EnterNotify/LeaveNotify events).
 2a) Some application grabs the pointer.  This may cause
     EnterNotify/LeaveNotify events.
 2b) Fvwm focuses next xterm and warps the pointer into the
     window, generating more EnterNotify/LeaveNotify events.
 2c) User releases button (more EN/LN events).

Which window ends up with the focus is more or less random.  It
depends on the order of 2a, 2b and 2c and possibly the windows
involved.

This is not theory - the grabs are there for exactly this reason.
There is no reliable way of filtering out the random events caused
by applications.

> It is simple to detect this situation and

I think it will replace one kind of problems with another one.

Bye

Dominik ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 30 Jul 2003 12:01:34 +0200

> > But it seems to me that we need grabing only if the function has

(and we have the same problem if function execution is triggered
by a client message or schedule or a module or ...).

Bye

Dominik ^_^  ^_^

---

From: Olivier Chapuis <[email-masked]>
Date: Thu, 31 Jul 2003 11:32:05 +0200

> > But it seems to me that we need grabing only if the function has

The situation is differrent. With the "I" function "do this" and "do
that" are a priorie executed immediatly (but see below).  With the "C"
function "do this" and "do that" are executed after button release
only.

> depends on the order of 2a, 2b and 2c and possibly the windows

Unable to reproduce this, but this is not the point (do not found a
method to get 2a). At first I thought that 2a) cannot cause problem as
2b should be executed "immediately". At least I thought fvwm does not
process events between 1 and 2b (and I think that fvwm should
not). But I've noted that the trigger_evtype of
execute_complex_function is lost sometime (using Next is an example)
so DeferExecution forces focus to be executed only when the button is
released. It seems to me that this is a bug.
 
In fact it seems that your example can happen on exceptional situation
because DeferExecution run over focus will try to grab and if it
fails will abort focus. Of course I think that it is a bug that we
DeferExec at this point (but it is one reason for precessing event).
I may miss something (function code is complex), but this is not my
point too. 
 
> This is not theory - the grabs are there for exactly this reason.

and also for a correct (and fast) detection of M, D, H conditions.

> I think it will replace one kind of problems with another one.

Yes maybe, but I really would like to found a solution (Note the
examples with FvwmEvent).

I recall the current way of executing complex function regarding these
problems: Grab and really try to grab (this may take a few seconds)
and if the grab fail abort the func (and essentially this is in this
case that the grab procedure take a _few seconds_).  fvwm grabbing is
slow because basically fvwm wait for success.

An alternative interesting method: Try to grab fast (just try to grab
once or twice) and _if the grab fail_ execute the func anyway.
(an obvious alternative is to try to grab fast and if the grab fail
abort the function, but see below). 

The first remark is that in most cases the grab will not
fail. Moreover, I think that this method should be applied only for
totally immediate func (we should really grab for H,M and D). Maybe
others conditions can be added.  I think it will be difficult to
reproduce a problem with this method.  Note that we try to grab here.

Here a "problem" which can happen with this method (but which has more
or less nothing to do with complex function). Type in an FvwmConsole

AddToFunc WS
+ I  WindowShade

Schedule 5000 All (FvwmConsole) WS

then use an app for grabbing the cursor before the scheduled cmd is
executed (e.g., by opening a menu of this app and do not close it).
When WS is executed, with the current method WS is aborted (after a
few seconds of fvwm freeze). With the fast grab and exec method when
WS is executed X and fvwm take a lot of CPU (fortunately, at low
price) until the app ungrab the pointer (e.g., by poping down the menu)
and then the FvwmConsole is shaded (ok).

This has nothing to do with complex function as this can be reproduced
with the current code with:

Schedule 5000 All (FvwmConsole) WindowShade

I do not know if this is a real issue but I am just afraid that we
should add new prefix commands as ForceGrab (try to grab and do not
execute if grabbing fail) and ForceFastGrab (try to grab fast and do
not execute if grabbing fail).

What do you think of all that? I am ready to work/think on any others
proposal suggestion ... 

Regards, Olivier

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 31 Jul 2003 11:51:59 +0200

> abort the function, but see below). 

Welcome to maintenance hell:

 - apparingly random results in funtion execution
 - random fvwm freezes if XQueryPointer or similar funcitons are
   called while an application holds a grab

> others conditions can be added.

Somethimes I feel like talking to a wall.  See my previous mails.

> I think it will be difficult to

I'm 100% against it.  Not that my opinion counts for much in this
place anymore...

Bye

Dominik ^_^  ^_^

---

From: Olivier Chapuis <[email-masked]>
Date: Thu, 31 Jul 2003 15:47:56 +0200

> Somethimes I feel like talking to a wall.  See my previous mails.

I think that you do not understand me. I see bugs that I can reproduce
easily and I want to found a solution. I really care that fvwm can
work well with certain applications (e.g., Mozilla and gkrellm). And
what about all your work on autohide with the Schedule command and
FvwmEvent (via WindowShade)?

You give an example and I study it carefully and found some strange
behavior in the current code.

You claim that my ideas can give raise to some bug. I cannot reproduce
any one but I trust you.

I say that I am ready to work on any other idea.

Now you say that I am a wall! This is funny. Maybe you should read my
mail (this discussion has nothing todo with the WindowStyle discussion).

Regards, Olivier

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 31 Jul 2003 16:44:48 +0200

> FvwmEvent (via WindowShade)?

I'm talking only about not grabbing the pointer in complex
functions.  Argue as much as you want, it does not work because it
can not work reliably under X, for example because of the way
EnterNotify and LeaveNotify events work.  If you don't like it,
all you can do is to delay function execution until the pointer
can be grabbed (i.e. loop forever in certain places).  But - this
may generate a deadlock with applications that grab the pointer
and then expect that the window manager processes requests.

> mail

I spend much more time reading list mail carefully than you think
(and than I should spend, for that matter).

> (this discussion has nothing todo with the WindowStyle discussion).

Bye

Dominik ^_^  ^_^

---

From: Dan Espen <[email-masked]>
Date: Thu, 31 Jul 2003 10:58:17 -0400

> and then expect that the window manager processes requests.

Please don't take this the wrong way.
Not all of us have your deep understanding of fvwm.

If the goal is to run some functions without grabbing,
why not make it an option?

Like:

FunctionNoGrab FUNCNAME

or Grab and UnGrab comands:

DestroyFunc ScreenDump
AddToFunc ScreenDump
+ I UnGrab
+ I Exec xwd
+ ...

-- 
Dan Espen                           E-mail: [email-masked]

---

From: Olivier Chapuis <[email-masked]>
Date: Thu, 31 Jul 2003 22:45:12 +0200

On Thu, Jul 31, 2003 at 04:44:48PM +0200, Dominik Vogt wrote:
> EnterNotify and LeaveNotify events work.

Please give an example I can reproduce. I think there is some but I would
like to see one which is reproducible. The example you give cannot
happen I think (and there are problems in the code with this example).
Note, again, that aborting complex function can _also_ break things! 

It is clear that you can do too much things with complex function to
have a default regarding grabbing. My hope is/was that this can be
detected in the average and add a special stuff for the unlikely
case.

I think that Dan idea is ok (I do not want to fight too much
more). I've suggested the converse: added a ForceGrab and
ForceFastGrab "dummy command" because again I cannot reproduce
(or even get one problem with my logic). 
 
> If you don't like it,

Do not underestimate my understanding of fvwm and X (however, I am not
(yet?) a big specialist of complex functions).

In a certain sense fvwm already "freeze" when grabbing fail: when
grabbing fail when you execute a complex function fvwm freeze for a few
seconds in GrabEm and in fact this cause the problem with gkrellm: If
you try to grab only once when executing complex function and abort if
this fail gkrellm can be moved smoothly.

> (and than I should spend, for that matter).

My previous and _complex_ previous long mail as the following date (I
spent one day to write it, reading the code an your mails, make some
experience ...etc):

Your answer arrived 20 minutes later ... :o) 

Regards, Olivier

---

From: Olivier Chapuis <[email-masked]>
Date: Thu, 31 Jul 2003 22:39:32 +0200

> or Grab and UnGrab comands:

Yes why not. In fact what is needed if we go this way is a "Grab fast
and abort if fail" and a "Grab fast and continue if fail" pre cmds.

Regards, Olivier