FVWM: Solution to Start menu problem

From: Raph Levien <raph_at_acm.org>
Date: Mon, 21 Apr 1997 15:43:22 -0700

Hi Hector,

   I've come up with the answer to making the Start menu pop up when the
start button is pressed, not waiting for it to be released.

   First, change modules/FvwmTaskBar.c:LoopOnEvents as follows (near
line 861):

      case ButtonPress:
        RadioButton(&buttons, -1, BUTTON_UP); /* no windows focused
anymore */
        if (MouseInStartButton(Event.xbutton.x, Event.xbutton.y)) {
          StartButtonUpdate(NULL, BUTTON_DOWN);
          x = win_x;
          if (win_y < Midline) {
            /* bar in top half of the screen */
            y = win_y + RowHeight;
          } else {
            /* bar in bottom of the screen */
            y = win_y - ScreenHeight;
          }
          sprintf(tmp,"Menu \"%s %d %d\"", StartPopup, x, y);
          SendFvwmPipe(tmp, ItemID(&windows, 0));
          XUngrabPointer(Event.xbutton.display, Event.xbutton.time);

   The two relevant changes are changing from Popup to Menu, so the
Start menu is properly sticky, and adding the XUngrabPointer call, so
the menu comes up instantly on button press.

   Second, change fvwm/builtins.c:staysup_func as follows:

  ...
  ActiveItem = NULL;
  ActiveMenu = NULL;
  menuFromFrameOrWindowOrTitlebar = FALSE;

  do_menu(menu,1);

  if(menu_name != NULL)
  ...

   In other words, get rid of the case analysis which makes the popup
sticky only if the event was a button press. Incidentally, you can do
the same thing at the end of window.c too.

   Third, change fvwm/menus.c:UpdateMenu as follows:

        case ButtonPress:
          sticks = 0;
        case KeyPress:
        case VisibilityNotify:
          done=1;
          break;

   In other words, catching a button press makes the window non-sticky.
This handles both the case that the menu was popped up by a key and the
case where it is popped up by a button in a different process (such as a
module).

   It should be clear that this is the right way to fix the problem (if
for no other reason than the too-sticky problem is solved once, in
UpdateMenu, rather than in two different places). What makes the problem
tricky is that the button release event from clicking the start button
may go to either FvwmTaskBar or fvwm, depending on the timing.

   Since much of the affected code is in fvwm proper, not just fvwm95,
I've cc'ed the fvwm mailing list. I'm not sure if this is the right
process, but it should at the very least get the patches to the people
that need them.

Raph
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
Received on Mon Apr 21 1997 - 17:42:53 BST

This archive was generated by hypermail 2.3.0 : Mon Aug 29 2016 - 19:38:00 BST