FIX: glutPositionWindow fails inside GLUI_Main::reshape (Nvidia GLUT)

[m-7761]

Working with GLUT is primarily frustrating. It should be noted that the subwindows can't reposition themselves with Nvidia GLUT because the move doesn't take effect until a reshape event is generated. It seems that dragging window border is the only way to do that.

EDITED: I'm removing the old (speculative) description. See fix details below. Note, this code change is not in the code here, so I'm hesitant to "Close" this issue.

[m-7761]

Update:

I wanted to test this one last time, and found that it was possible to position subwindows from inside of an input event... so I think there is something else going on here.

I think the problem may be that glutPositionWindow needs to happen before glutReshapeWindow or something, since reshape needs to schedule a glutReshapeFunc event.

I also noticed that the "refresh" method seems to not reshape subwindows. But I don't think that's related to issue I was earlier experiencing. (Its code is otherwise identical to the "reshape" method incidentally.)

I know I tried the following before, but it didn't work then. But it does now. Except instead of doing the "check_subwindow_position" procedure inside of a timer, I changed it to the (GLUI_Master) user API called "reshape" that does it for all of the subwindows, since I reckon that's more correct, since a subwindow changing its size will cause the position of the subwindows that sit on it to also change position.

static void glui_reshape_timer(int id) 
{
    int gw = glutGetWindow(); glutSetWindow(id);

    GLUI_Master.reshape(); //HACK: Has functionality required/access.

    glutSetWindow(gw);
}

This code is part of GLUI::reshape.

    _pack_controls();

    if(_w!=reshape_w||_h!=reshape_h) 
    {
        glutReshapeWindow(_w,_h);
    }
    else if(_flags&SUBWINDOW)
    {       
        //2019: This just isn't working here.
        //if(_flags&SUBWINDOW) _check_subwindow_position();
        glutTimerFunc(0,glui_reshape_timer,_glut_parent_id);
    }

Since changing how Rollout works to size it according to its hidden contents, and also to expand to the size of its column, this isn't actually a problem that can occur right now. But it should be useful in the future if the UI panels came in a fixed dimension flavor.

I've contemplated adding scrollbars to the main windows (outside of the "main panel") just as an optional feature, meaning that adding a scrollbar to the Node doesn't locate it in the panel, but outside of the panel. But I'm not implementing new feature right now, since I'm really trying to shake this monkey off my back, so I can take a break from it.

I think though this bodes better for GLUT that this is not a limitation for it.

[nigels-com]

One thing to consider for this is the behaviour of FreeGLUT.

[m-7761]

I tested everything with freeglut too. But freeglut's implementation of subwindows is completely broken over X servers on Windows. I don't know who is to blame, but other software works fine. I will be interested to see how wxWidgets does. I don't think there is an alternative to freeglut in the Ubuntu package system.

I think implementing GLUT is super simple, so freeglut probably should go away in favor of just using more mature, better maintained cross-platform libraries. GLUT is a 1 file job with any such library. There's no reason to maintain it as baby's first cross-platform library. I doubt freeglut has better cross-platform code for any given system. And I've dealt with its developers. They don't seem like good people or inspire confidence. They are a tiny group, whereas wxWidgets and Qt hold the interest of countless parties with pretty big deal software stakes. Though wxWidgets is not much better than amateur code, it still gets a lot of foot traffic; a lot more eyeballs.

[nigels-com]

What do you think is actionable for (mainline) GLUI for subwindows?
File a bug against FreeGLUT and wait for other GLUT implementations to sort it out? Recommend GLUI users to avoid subwindows, or at least test carefully?

[m-7761]

Well just to be clear, this has nothing to do with freeglut. It's just not implemented correctly. As I recall the logic itself was all wrong, apart from GLUT variants that exist in the wild.

I think you have probably have better things to do in your private life then nitpick these things. I know I do. I've fixed all of these issues, so I would just integrate those fixes en mass and trust they are correct.

[nigels-com]

Without substantiation, I'm not inclined to merge changes to GLUI. I realise you're not happy with that, but that's the way it is.

[nigels-com]

If there is a need to improve or change the GLUI handling or support for subwindows, I recommend taking that elsewhere. This seems related to your fork of GLUI, not necessarily the mainline one maintained here.

[m-7761]

This seems related to your fork of GLUI, not necessarily the mainline one maintained here.

Why does it seem so? Hint: It's not.