#32 2.2.0: glutMenuStatusFunc() doesnt work

closed-fixed
nobody
moderate (59)
5
2012-08-06
2003-12-22
No

When switching from glut (3.7) to freeglut (2.2.0) I
found out, that glutMenuStatusFunc() seems not to work
on freeglut:

My menues attached to the right button:
glutAttachMenu(GLUT_RIGHT_BUTTON);

thats how I initialize the callback to menuStatus:
glutMenuStatusFunc(menuStatus);

...and this is my menuStatus-function:
void menuStatus(int val, int x, int y)
{
cout << "menuStatus called" << endl;

if (val == GLUT_MENU_IN_USE) {
MENUSTATE = true;
cout << "menu switched on" << endl;
}

if (val == GLUT_MENU_NOT_IN_USE) {
MENUSTATE = false;
cout << "menu switched off" << endl;
}
}

in glut 3.7:
(1) this is called everytime the menu is switched on or
off.
(2) The menu is visible as long the right button is
hold down.
(3) the mouse-pointer is visible when the menu is
visible (even, if the pointer is turned off)

in freeglut 2.2.0:
(1) the menuStatus function is never called!
(2) the menu stays up, when the right button is
pressed shortly and released
(3) the mouse-pointer is not visible (if turned off)
while menu is dsplayed, only some sort of flashing if
moved...

I think, that (2) is not a problem, but a slightly
different behaviour, (3) is only an optical issue, but
(1) is a real problem.

Discussion

  • Richard Rauch

    Richard Rauch - 2003-12-25

    Logged In: YES
    user_id=854844

    Thanks for the bug report.

    (1) The menus staying on your screen after you release the
    menu button is a known issue. I believe that it is
    intentional, in order to mimic the WIN32 behavior of old
    GLUT, but (at least under X) it is implemented imperfectly,
    resulting in menus that are "annoying". (This is all
    happening because old GLUT used host system menus, while
    freeglut manufactures its own menus from slight variations
    on its own windows. The result is hoped to be more uniform
    across systems, but I do not know if we can ever make it
    work correctly. I think that making freeglut always have
    menus after the style of old GLUT on X11 is a better
    prospect.) But there is no consensus to make that change,
    and it would involve redoing a fair bit of the menus.

    (2) The mouse pointer should probably be set to the
    right-pointing arrow while in the menus. (That should be
    easy: Set the pointer for the menu's window.) (NOTE:
    *Right* pointing, not upper-right.) I think that this is at
    least as severe as (1) (though I personally rather dislike
    (1), too). An invisible mouse pointer in the menus is a bad
    thing. (^&

    (3) Menu status: It would be helpful if you actually showed
    the output of a program that uses menu status, along with
    blow-by-blow commentary "Here is where the program is
    initialized." "Here the menu is created." "Here the window
    is open". "Here the menu has appeared." "Here the menu
    item is selected." (Yes, I could do that, too. But you are
    already sensitive to the timing of the menu status function,
    whereas I never use it. I suspect that no one else uses it,
    either, on the freeglut team or something like this would
    have been discussed before.)

    (4) There is another menu buglet: Menus hang around after
    you select a menu until AFTER the menu callback is
    completed. (For an old class project, as a student, I once
    had to get input from {cin} or {stdin} after a menu
    selection. Under GLUT, the menu pops down immediately after
    the selection, before/while waiting for input. In freeglut,
    the menu hangs around until the input (done in the callback)
    is completed.)

     
  • Hannes Krueger

    Hannes Krueger - 2003-12-28

    example source.

     
  • Hannes Krueger

    Hannes Krueger - 2003-12-28

    Logged In: YES
    user_id=844385

    I added a glutMenuStatus callback to the simple menu_test
    program from the GLUT distribution. I tried it with GLUT and
    also with freeglut. With GLUT the menuStatus function is
    called everytime a menu is popped up or is disappearing.
    With freeglut this function is never called...
    the source is attached.
    Even in this program, where the mouse pointer is diaplayed,
    it is invisible if any menu is popped up. The pointer can
    only be seen while its moved. But even then ghost-like.
    (flashing, half-invisible). The popped up menus are
    sometimes incomplete. They seem to be overlayed by some
    rectangles... This is hard to describe detailed. Better try
    yourself with attached source on X11.

    (2) I think that setting the mouse pointer for menus should
    be done by freeglut. GLUT sets the mouse pointer to
    (right-pointing) if a menu is popped up.

     
  • Richard Rauch

    Richard Rauch - 2004-02-01

    Logged In: YES
    user_id=854844

    First, Sorry for taking so long to get back.

    Second, the file that you provide is copyright by Mark Kilgard. Given that the raison d'etre of freeglut is to get away from the vague, hazy terms of mark Kilgard's original GLUT, and that the file doesn't provide any permission for you to make modifications to it, I suggest that you attempt to demonstrate this bug with either an UNMODIFIED program of his, or else by creating your own program from scratch.

    (3): This one is possibly coming from two aspects. freeglut *does* set the cursor for the menu window (or rather, I believe, allows it to be inherited). The problem is that the menu's window doesn't get the input focus initially. To give it the focus, you must first release the mouse button, in a place NOT over the menu, then move back over the menu. Until you do that, you still have the parent-window's mouse poniter.

    However, the flickering/ghost effect that you are seeing is due to something else. The most likely explanation is that your video card doesn't have a hardawre mouse cursor (or, perhaps more likely, that your X server doesn't know how to use it). I had this very annoying problem with a Radeon 9200 SE card, until I lied to XFree86 to tell it that I was using a different chipset. Now I have a rock-solid cursor again (and some other things are much better, too).

    The damaged block in the menu is strange. I haven't seen that before.

    I'm not sure what to make of this one, for now.

     
  • Hannes Krueger

    Hannes Krueger - 2004-02-02

    Logged In: YES
    user_id=844385

    sorry for that copyright-thing, I thought it would be OK for
    demonstrating this bug.. But you can take any code that uses
    menus, add something like

    void menuStatus(int val, int x, int y)
    {
    cout << "menuStatus called" << endl;

    if (val == GLUT_MENU_IN_USE) {
    MENUSTATE = true;
    cout << "menu switched on" << endl;
    }

    if (val == GLUT_MENU_NOT_IN_USE) {
    MENUSTATE = false;
    cout << "menu switched off" << endl;
    }
    }

    and register it somewhere:
    glutMenuStatusFunc(menuStatus);

    You'll see, that the callback is never used...

    I browsed through the freeglut sources and found
    fgActivateMenu and fgDeactivateMenu in the freeglut_menu.c,
    I think that these are the functions from where the
    menuStatusCallback should be called (but I'm not the
    freeglut menu expert)

    I tested with freeglut on a more recent system, and the
    invisible mouse-pointer and flickering effects did not
    appear there, so I think its an issue with my old xserver at
    home... You should forget about that.

     
  • Hannes Krueger

    Hannes Krueger - 2004-02-02

    Logged In: YES
    user_id=844385

    sorry for that copyright-thing, I thought it would be OK for
    demonstrating this bug.. But you can take any code that uses
    menus, add something like

    void menuStatus(int val, int x, int y)
    {
    cout << "menuStatus called" << endl;

    if (val == GLUT_MENU_IN_USE) {
    MENUSTATE = true;
    cout << "menu switched on" << endl;
    }

    if (val == GLUT_MENU_NOT_IN_USE) {
    MENUSTATE = false;
    cout << "menu switched off" << endl;
    }
    }

    and register it somewhere:
    glutMenuStatusFunc(menuStatus);

    You'll see, that the callback is never used...

    I browsed through the freeglut sources and found
    fgActivateMenu and fgDeactivateMenu in the freeglut_menu.c,
    I think that these are the functions from where the
    menuStatusCallback should be called (but I'm not the
    freeglut menu expert)

    I tested with freeglut on a more recent system, and the
    invisible mouse-pointer and flickering effects did not
    appear there, so I think its an issue with my old xserver at
    home... You should forget about that.

     
  • Diederick C. Niehorster

    • status: open --> closed-fixed
     
  • Diederick C. Niehorster

    glutMenuStatusFunc implemented in current trunk last week or so. I can't comment on the other issues as I'm only on the windows side, but hope they've been cleared up after 8 years...

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks