Subject: Tear off menus stop module messages

From: tim phipps <[email-masked]>
Date: Fri, 19 Apr 2002 16:01:48 +0100

Configuration Information [Automatically generated, do not change]:
uname: SunOS silver 5.5.1 Generic_103640-39 sun4u sparc SUNW,Ultra-5_10
compiler flags: gcc -g -O2 -Wall -Wno-implicit-int

FVWM Version:	2.5.1
FVWM_MODULEDIR:	/u/phippst/sunos/libexec/fvwm/2.5.1
FVWM_DATADIR:	/u/phippst/sunos/share/fvwm
FVWM_USERDIR:	/u/phippst/.fvwm

Description:
	When the pointer is on a tear off menu item fvwm stops processing
	module messages.
	
	The same thing happens when a normal menu is popped up but it's less
	noticeable since the menu is short lived.

Repeat-By:
	Arrange for a shell script to update an FvwmButtons title every second
	via FvwmCommand.
	Tear off a menu.
	Put the mouse over then torn off menu item.
	Look at the button which should be updating.
	Move the pointer off.
	Watch the button catch up with the updates.

--
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: Fri, 19 Apr 2002 17:35:44 +0200

> 	When the pointer is on a tear off menu item fvwm stops processing

Yes, that's by design of the tear off menu code.  I have no idea
what to do about it (other that creating a separate instance of
fvwm for each tear off menu).

Bye

Dominik ^_^  ^_^

-- 
Dominik Vogt, email: [email-masked]
LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen
fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20
--
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: Dan Espen <[email-masked]>
Date: Fri, 19 Apr 2002 12:59:10 -0400

> fvwm for each tear off menu).

Why can't the menu code be in a module?

To retain compatibility, there could be commands like this:

OnCommand Popup       SendToModule FvwmMenu P $*
OnCommand Menu        SendToModule FvwmMenu M $*
OnCommand AddToMenu   SendToModule FvwmMenu A $*
OnCommand DestroyMenu SendToModule FvwmMenu D $*

# Make "SendToModule Module" load FvwmMenu,
LoadOnDemand FvwmMenu

The first time fvwm encountered a "SendToModule" for a LoadOnDemand
module, it would load it.  As long as the module stays loaded,
the menus should be fast enough.

-- 
Dan Espen                           E-mail: [email-masked]
444 Hoes Lane  Room RRC 1C-214      Phone: (732) 699-5570
Piscataway, NJ 08854
--
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: Mon, 22 Apr 2002 11:41:47 +0200

> Why can't the menu code be in a module?

Of course menus *can* be a module.  It's just that the menu code
was not written to run independently of fvwm and is thus
interwoven tightly with fvwm's data structures.  Well, and as long
as menus grab the pointer and the keyboard, processing module
messages is pointless since the funtion execution code needs (?)
to grab the pointer too.

Bye

Dominik ^_^  ^_^

---

From: Dan Espen <[email-masked]>
Date: Mon, 22 Apr 2002 15:05:26 -0400

Dominik Vogt <[email-masked]> writes:
> > > > 	When the pointer is on a tear off menu item fvwm stops processi
> > > > 	module messages.
> > > 
> messages is pointless since the function execution code needs (?)
> to grab the pointer too.

I don't think I understand the point about the grab.
Its OK for menus to freeze FVWM so the grab should be OK.

I think putting the menu code in a module might simplify tear
off menus.  I'm not sure of all the details but it just seems
like it might.  Perhaps another copy of the menu module could be
started to handle the torn off menu (without grabs once its torn
off).

I think it might have a beneficial effect on memory use too.
More of the menu logic might swap out while the menus are not
in use.

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 23 Apr 2002 11:41:34 +0200

> Its OK for menus to freeze FVWM so the grab should be OK.

When any client grabs the pointer, fvwm basically stops processing
most module messages too, at least if modules call complex
functions.

> started to handle the torn off menu (without grabs once its torn

Fvwm menus need to grab the keyboard to work properly.  Pure mouse
oparable menus would be useless to me.

Bye

Dominik ^_^  ^_^

---

From: Dan Espen <[email-masked]>
Date: Tue, 23 Apr 2002 18:05:06 -0400

> most module messages too, at least if modules call complex

I know that, but don't see that as a problem.  We want FVWM
to freeze when a menu is popped up.

> operable menus would be useless to me.

I'm sorry if I'm wasting your time.  Maybe I don't understand what
a tear off menu is.  I thought it was like one of those Openwin
menus that you use a pushpin to make it stay visible.

If I'm on the right track, then I think the menu would have to release
the grab once the menu is torn off.  What I thought would happen
is the menu code would send a description of the menu to another
module and the module would create a normal window that looked
like the menu except that FVWM could reparent it, and if desired
frame, title and do other good things to it.

At that point the menu could be operated with the keyboard
or the mouse just like any other window.
(Using  enter, leave, keypress events and the like.)
It could still popup a submenu with a grab, but you wouldn't need
a grab for the torn off menu itself.

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 24 Apr 2002 13:21:58 +0200

On Tue, Apr 23, 2002 at 06:05:06PM -0400, Dan Espen wrote:
> I'm sorry if I'm wasting your time.

Nonsense.

> Maybe I don't understand what

Exactly.  They are sometimes called pin up menus.  I expect that
torn off menus behave as any other application window does.  This
is very difficult to do if the torn off menus are handled directly
in the fvwm code.

> the grab once the menu is torn off.

Well, it does release the grabs.  But as it is now, whenever the
pointer enters a tear off menu, fvwm makes the grabs again.  As
long as fvwm is in the menu loop it doesn't really matter if the
grabs are made or not - it can't handle module input anyway in
that code.

> What I thought would happen

Yes, I agree.  In theory this sounds all very good.  It's only
that the menu code is woven into the fvwm framework so tightly
that it's very hard to separate it and put it into a module.  I
don't like the idea of duplicationg the complete menu code
either.  I'm open to any ideas how to do this.

Bye

Dominik ^_^  ^_^

---

From: Tim Phipps <[email-masked]>
Date: Thu, 25 Apr 2002 12:24:25 +0100

[email-masked] wrote:

>>the grab once the menu is torn off
>>
I think there might be a bug in the grabbing and it may be the reason 
I'm seeing it as a problem. I don't mind fvwm stopping module messages 
when the pointer is on the torn-off menu but it seems to keep the grab 
when the pointer moves off and it only releases it when the pointer 
enters another window.
Normally the grab is released when the pointer leaves the torn off menu 
but if you use the keyboard to go from the torn off menu to a sub-menu 
and the use the keyboard to go back to the torn off menu and then move 
the pointer off the torn off menu the grab remains. You can see the grab 
is active because the cursor stays the same as on the menu.

Cheers,
Tim.

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 25 Apr 2002 14:58:22 +0200

> is active because the cursor stays the same as on the menu.

Fixed.

The although the grab was released, the pointer was immediately
regrabbed because the menu code did not remove EnterNotify events
from the queue.  These were processed later by the main loop
although the window had long been left again.

Bye

Dominik ^_^  ^_^

---

From: Tim Phipps <[email-masked]>
Date: Fri, 26 Apr 2002 13:47:56 +0100

>Fixed.
Thanks, that's much better.

Cheers,
Tim.