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.
The GLUI code is all written in C++ and all the widgets
are classes etc, which makes a lot of sense.
BUT! The way to create and add widgets is through a
billion different methods of the GLUI class. And a
different one for add_to_panel vs add to main window??
This is a really odd way to do OO UI code. The GLUI
class should have just one add API that takes a
GLUI_control, and all the code in glui_add_controls.cpp
should instead go into the constructors of the
individual widgets.
In fact the way these things are typically done with
other toolkits is that you just pass in the parent in
the constructor. So instead of
You would do
GLUI_Checkbox *cb = new GLUI_Checkbox(mypanel, "Check
me out!", &value, MY_CB_ID, updateCB);
It doesn't make for any more typing (actually, a little
less typing in this case) and it means that GLUI
doesn't explicitly have to know about every
GLUI_Control subclass in existence. That means GLUI
becomes more extensible because people can write their
own reusable widget subclasses without having to modify
glui.h to add
GLUI::add_my_ultracool_widget(...) and
GLUI::add_my_ultracool_widget_to_panel(...)
methods.
Plus this will make a lot more sense to people who are
used to other C++ GUI APIs (wxWindows, Qt, FOX, to name
a few).
https://sourceforge.net/p/glui/feature-requests/6/
The GLUI code is all written in C++ and all the widgets are classes etc, which makes a lot of sense.
BUT! The way to create and add widgets is through a billion different methods of the GLUI class. And a different one for add_to_panel vs add to main window?? This is a really odd way to do OO UI code. The GLUI class should have just one add API that takes a GLUI_control, and all the code in glui_add_controls.cpp should instead go into the constructors of the individual widgets.
In fact the way these things are typically done with other toolkits is that you just pass in the parent in the constructor. So instead of
GLUI_Checkbox *cb = myglui->add_checkbox_to_panel( mypanel, "Check me out!", &value, MY_CB_ID, updateCB);
You would do GLUI_Checkbox *cb = new GLUI_Checkbox(mypanel, "Check me out!", &value, MY_CB_ID, updateCB);
It doesn't make for any more typing (actually, a little less typing in this case) and it means that GLUI doesn't explicitly have to know about every GLUI_Control subclass in existence. That means GLUI becomes more extensible because people can write their own reusable widget subclasses without having to modify glui.h to add GLUI::add_my_ultracool_widget(...) and GLUI::add_my_ultracool_widget_to_panel(...) methods.
Plus this will make a lot more sense to people who are used to other C++ GUI APIs (wxWindows, Qt, FOX, to name a few).