search

libglui / glui

GLUI is a GLUT-based C++ user interface library which provides controls such as buttons, checkboxes, radio buttons, and spinners to OpenGL applications. It is window-system independent, using GLUT or FreeGLUT.
Other
194 stars 82 forks source link

GLUI "3.00" code dump information (github.com/mick-p1982/glui) #109

Closed m-7761 closed 3 years ago

m-7761 commented 5 years ago

Here (finally) is the result of my first round of work on GLUI:

https://github.com/mick-p1982/glui/commit/624ca24d1d6a060ea27a8f070c5e8a6ea4126f1c

I apologize for rearranging the file tree, but I think the changes are an improvement. I want to leave my "fork" as a time capsule, not in disorder.

As for the content, I've not added any major features. I've just cleaned up and audited the code and made everything very presentable. It's designed to be a drop in replacement for Win32 common-controls. The existing features are pretty well polished to the highest degree possible, without making significant design decisions or staking out brand new features.

I intend to do a brief write-up for the Readme.txt there on the home-page. I hope I did not leave anything out. Just this morning I was furiously making last minute changes, but I could not think of anything this afternoon to change or add, so I just shot the files up.

GitHub wouldn't accept my changes in the form of an SVN checkout, so I may have missed something in the last moment as I hand copied everything to a fresh Git checkout.

I want to keep developing GLUI somehow, but I don't want to do anymore on this particular fork because it's hard to work with. I would be happy to takeover maintenance of GLUI, but not under GitHub. I would be amenable to reconstituting the SourceForge account.

My opinion of Git and GitHub is very low compared to Subversion's. If I can't be added to the admin list for the GLUI SourceForge account, then I think I will keep it as a subfolder or something under my "Widgets 95" account there, in case anyone is interested in improving upon GLUI.

EDITED: There may be a working example.exe file in the bin/Win32 (https://github.com/mick-p1982/glui/tree/master/bin/Win32) folder. If not, the CMakeLists.txt script has been updated to build the example program. I don't know how it fairs on Linux or GCC since it was only convenient for me to test it on Ubuntu for Windows 10. I didn't do a Cygwin build, but freeglut doesn't work very well with remote/indirect X servers. I've never seen it in a local/direct setting. The Windows version of freeglut works pretty well.

Some of the more noticeable enhancements, aside from appearance and correctness, are:

1) Mouse wheel system. 2) Timer based blinking caret. 3) Timer based Xlib clipboard. 4) On Windows the 3D widgets hide the cursor. This doesn't work so well with Xlib because, freeglut at least, uses XWarpPointer for this, which generates mouse events. XGrabPointer might be possible to use as a solution, but I don't know if it's worth investigating. I could sort of cancel out the fake events, but using glutWarpPointer would quickly put freeglut in a locked state, as if its event queue was stalled/full. 5) Many more controls display their names, but not all. (I have a plan for this called "placement" that analogous to "alignment". I would like to generalize this.) 6) Rollout has a different design. Visually everything is very pleasing. I quite like the rugged esthetic. 7) Spinners and scrollbars are embedded in controls. 8) I removed the GLU dependency, and I can envision a way to support a mode that doesn't use GLUT in favor of user provided functionality. 9) The "example" stuff is maybe a bit in disarray, but a lot better off. It now switches between demos, and demonstrates some nontrivial use cases. 10) There is a new HPP header that the H header acts like a wrapper around it, to use the old syntax. The examples continue to use the old syntax, and I didn't modify them, other than to add newer functionality.

Closing thoughts:

1) I think GLUT has a much too checkered past. If anyone cares about GLUI's future, it should be making plans to gain independence of GLUT. 2) A public offering requires an Undo/Redo feature for the text editor. There were a few things like this that I just couldn't set time aside to do for wanting to meet my deadline and take a long break from GLUI. The current editor is pretty inspired. It took me a while to finalize it. Programming a full-featured text-editor is a big job anyway you look at it. I actually like the minimal take of the original editor code. I'm not sure I would've programmed an editor that way.

m-7761 commented 5 years ago

P.S. I painstakingly moved the files with Tortoise Git, but it looks like their History didn't move with them, or GitHub cannot display it. (Or maybe I didn't use Git correctly, or Tortoise Git doesn't implement Move correctly.)

I don't think there's been a great deal of changes to GLUI since it moved from SourceForge. If my rewrite is inspiring that it could have a future, then I really think moving to GitHub ought to be reconsidered. But I don't know how far back GLUI's history really goes. It may be very shallow in terms of revisions if it was principally developed by Paul Rademacher prior to being open sourced.

m-7761 commented 5 years ago

Today I noticed the Spinner didn't work for clicking because it would go up wildly when clicked. I didn't think I was going to try to fix it but I did anyway.

https://github.com/mick-p1982/glui/commit/0a744af

To do it, it was necessary to impose a speed limit on the idle function, because it's called at such a high frequency.

I don't think the display events happen at that frequency, but there's no way to slow down idle except to "sleep". Even if you waited for a display to happen knowing a control will update it will still spin. The sleep is contingent on the idle function being reentered in under x milliseconds.

EDITED: I actually think glutTimerFunc is generally better than idling for problems that require updates... but I think it's nice too to manage rapid idling for users. Though they might want to disable it.

m-7761 commented 5 years ago

https://github.com/mick-p1982/glui/commits/master has some updates that grew of my beginning to repackage the code for my next phase of development.

The new code won't go into the fork code. I've opted to make a sharp departure from GLUI. I ended up going with the standard-library convention for this project. (All lowercase.) It's kind of weird and clumsy (and hard to read) but it felt like the best fit. It's not as convenient to maintain. It solves some problems with where to capitalize control names by removing capitals altogether.

Copying pasting code to/from GLUI won't be a future option. I received a letter from Nigel the maintainer. They said they were interested in backporting some things I worked on (for hundreds of hours) but I think that's really too much work for anyone to take on (so it is very unlikely to occur) and I would recommend instead copying everything over pretty much intact, and then figuring out what to change (maybe move files back, since Git seems to not be able to move/copy) before committing. I'm sure parts I would prefer to omit myself, but I don't know if it's worth so much consideration considering the abysmal state of the present code (and user experience) by comparison.

I'm not directly working on the, code but when I notice semi-serious issues I will patch them in this fork.