On Tue, Apr 23, 2002 at 06:05:06PM -0400, Dan Espen wrote: > Dominik Vogt <fvwm-workers@fvwm.org> writes: > > On Mon, Apr 22, 2002 at 03:05:26PM -0400, Dan Espen wrote: > > > Dominik Vogt <fvwm-workers@fvwm.org> writes: > > > > On Fri, Apr 19, 2002 at 12:59:10PM -0400, Dan Espen wrote: > > > > > 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 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. > > > > When any client grabs the pointer, fvwm basically stops processing > > most module messages too, at least if modules call complex > > functions. > > I know that, but don't see that as a problem. We want FVWM > to freeze when a menu is popped up. > > > > 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). > > > > Fvwm menus need to grab the keyboard to work properly. Pure mouse > > operable menus would be useless to me. > > I'm sorry if I'm wasting your time.
Nonsense. > 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. 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. > If I'm on the right track, then I think the menu would have to release > 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 > 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. 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 ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] 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 PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
