Windows GLUT: scrollbars/rotation mouse up/down events (affecting Idling?)

[m-7761]

I think the scrollbar puts the UI in constant idle after it is manipulated. The spinner reevaluates the idle requirement in the mouse-up event. Scrollbar doesn't.

The Rotation manipulator doesn't manage the idle requirement at all. If it's set to have a spin, then it looks like that makes the UI an idling UI.

It's pretty simple to have the idle function reevaluate the idle requirement so controls don't have to do cleanup. The mouse-up event isn't reliable anyway.

The reverse is not true... because you need an idle function in order to scan the controls for an idle requirement. Maybe it makes sense to have them continue to prompt the idle state in light of that.

[nigels-com]

For example6 I can certainly see high CPU usage while the vertical scroll bar is being manipulated. But I do not observe constant idling once the mouse button is released. This does not seem to be affecting the mainline GLUI branch.

[m-7761]

The problem is the scrollbar code calls glui_setIdleFuncIfNecessary own down or drag, but doesn't call it again on release. To fix this I changed the idle subroutine to call glui_setIdleFuncIfNecessary so that it turns itself off, since events are not reliable anyway.

I'm sure I looked over the code here to confirm it was that way, but by all means look again. I could be wrong. The spinner code uninstalls its idle handler as the scrollbar should.

[nigels-com]

Possibly a windows-specific problem if the pairing of button up and down events is not guaranteed.

Possibly something GLUT ought to be handling for the purpose of platform portability. The documentation (which likely pre-dates the Windows support for GLUT) states:

If a GLUT_DOWN callback for a specific button is triggered, the program can assume a GLUT_UP callback for the same button will be generated (assuming the window still has a mouse callback registered) when the mouse button is released even if the mouse has moved outside the window.

[m-7761]

You misunderstand the problem (as usual) which has nothing to do with sequences. The control's UP event is not implemented correctly. I explained this. Look at the code.

That said, nothing in software is guaranteed to occur. Especially not messages. And GLUT is not a rock steady foundation that I would trust to begin with. That's why I've programmed it much more defensively. There are several places where controls can get stuck, like buttons being suck down when the mouse is not...

Frankly GLUI's code here is a laughing-stock. It's not even sub-amateur quality. So you can defend it until the cows come home, but I won't humor you.

[nigels-com]

Please substantiate the issue with the details, as requested.

[m-7761]

It must really suck to be yourself. Sorry Nigels.

[nigels-com]

So while you were busy insulting strangers on the internet.

I built (mainline) GLUI on Windows 10 and Visual Studio 2019, using the GLUT bundled with the Cg 3.1 runtime.

The scrollbars appear to be working as expected with no "idle CPU spiking".

So unless this issue can be clarified with more detailed instructions, and without insults, I'm inclined to resolve it as "works for me".

[m-7761]

Here (https://github.com/libglui/glui/blob/master/glui_scrollbar.cpp#L226) is the code I referred to, that anyone can see for themselves...

Buy yeah, at some point this line of code got deleted from my code. I tracked it down. It was adjacent to some clipboard idle logic. I guess what happened is Visual Studio ate a line or something when I wasn't watching it.

Believe me, if I thought sharing information here was an opportunity to converse with you Nigel I would not. I'm writing here as it's the responsible thing to do, since I'm working with the code, and can provide some insight... to literally any person in the world who might take an interest in this code. My impulse was to stop writing--because of yourself--but I felt that was petty, and gave too much power to one miserable person.

The fork I've prepared uses the idle function in many different ways, and mouse up events are not reliable. The idle function should not be uninstalled in the Up handlers in the first place. Which is part of what I expressed at the top of this ticket. I also did not express conclusively there was a problem.

I've only become thoroughly well versed in GLUI's code after spending so many hours pouring over every square inch. It now occupies a large part of what I know about expertly. For the time being. Only a devil or a fool would throw that opportunity away. But to be honest, I've only met the worst people in my life squatting on issue trackers. I think the average programmer must be an especially broken person. They seem to have no good qualities. I think the field or atmosphere may be unsuited for decent people. I have to do it alone myself.

[nigels-com]

I'm glad you resolved the problem.

But this illustrates the problem having two forks of GLUI sharing one issue tracker. I would request that you go elsewhere to discuss your own fork of GLUI. I'm (usually) happy to discuss with you this mainline GLUI here, but I don't find it productive to be chasing bugs (regressions) in your own fork that hasn't been accepted or merged here.

The GLUI I choose to maintain is there one here at libglui/glui. I'm interested enough to consider pull requests or feature suggestions. But I don't think it's constructive to clutter this issue tracker with issues arising from other forks of GLUI. By the way, do you have a name for your GLUI yet?

[m-7761]

I'm glad you resolved the problem.

But this illustrates the problem having two forks of GLUI sharing one issue tracker. I would request that you go elsewhere to discuss your own fork of GLUI. I'm (usually) happy to discuss with you this mainline GLUI here, but I don't find it productive to be chasing bugs (regressions) in your own fork that hasn't been accepted or merged here.

The GLUI I choose to maintain is there one here at libglui/glui. I'm interested enough to consider pull requests or feature suggestions. But I don't think it's constructive to clutter this issue tracker with issues arising from other forks of GLUI. By the way, do you have a name for your GLUI yet?

Yeah okay. 1 out of 100 bug reports is a mistake. People make mistakes. I certainly do... on a regular basis. You could have avoided all of the time you spent on this issue by looking at the code yourself, instead of talking, and running tests.

In any case, these issues are with this code. Not mine (my fork). Yours is bug-riddled. I'm just leaving a list of bugs, in case anyone gives a damn... they are a resource.

[nigels-com]

One job of a maintainer is to verify or confirm bug reports. If they seem like a misunderstanding or a matter of expectations, that's something that can often be resolved quickly and easily.