> It looks like earthlink put my reply in your "suspect email" folder.
>
I got your first reply. Thanks. If I don't get to look at my suspect email
soon enought to put a previously unknown sender in my address book the well
meaning sender gets the alert that you got. Sorry about that.
> Here is one more attempt to reach you and my original reply:
>
Thanks for responding and the additional info.
> Both those functions "menu" and "windowlist" are meant to grab the
> xserver and cause the "hang" that you observed.
>
But shouldn't the code waiting (or hanging) on a user's menu choice release
the wait when a menu choice has been chosen? Maybe my use of the term
"hang" along with lack of some more information was misleading.
I took your advice and posted a slightly revised and hopefully more accurate
explanation to fvwm-workers@fvwm.org that (see below) where I say
> > the mouse is moved. For example if you launch an application using
> > this it will not come up until the mouse is moved.
In other words, fvwm does the right thing according to the
RootMenu-or-WindowList function and displays the root menu or windows list
depending on whether the user single clicks or double clicks. But when this
RootMenu-or-WindowList is asserted for "mouse 1" and then the user launches
an application from the root menu, *then* the application does not come up
until the mouse is moved. If however, the RootMenu-or-WindowList function
is asserted for a title bar button this works fine. And therefore this
seems like an inconsistency in the way that fvwm works,
ie. RootMenu-or-WindowList works fine at one place but not at another.
Bill
> There has been some experimental code developed for "tear off menus" which
> would be a prerequiste for solving this problem with menus.
>
> You might try the Module FvwmWindowList instead of using the built in
> windowlist. The FvwmGtk might serve as a substitute for the menu.
>
> I've closed your problem report as "not a problem". Send mail to
> fvwm-workers@fvwm.org if you feel this is still a problem.
>
>
> --
> Dan Espen E-mail: [EMAIL PROTECTED]
>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>
> William Paul Vrotney <[EMAIL PROTECTED]> writes:
> >
> > This function works fine if bound to almost anything (like a button):
> >
> > Single click RootMenu, double click WindowList
> > DestroyFunc RootMenu-or-WindowList
> > AddToFunc RootMenu-or-WindowList
> > + I Menu Root-Menu mouse -1p -1p
> > + D WindowList mouse -1p -1p NoGeometry
> >
> > If bound to mouse 1 on the root plane
> >
> > Mouse 1 R N Menu Root-Menu mouse -1p -1p
> >
> > it also works fine but, after executing it successfully, fvwm hangs until
> > the mouse is moved. For example if you launch an application using this it
> > will not come up until the mouse is moved.
> >
> > Is this a bug? Is there another way of achieving this? It seems like a bug
> > because it seems to imply that one can not have a flawless binding to a
> > single and double click on the root plane.
>
--
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]
