A base class for Robolocust drawable objects. More...
#include <Robots/LoBot/ui/LoDrawable.H>
Classes | |
| struct | Geometry |
Public Member Functions | |
| virtual void | gl_init () |
| std::string | name () const |
| Return this drawable's name. | |
| Geometry | geometry () const |
| Return this drawable's geometry. | |
| bool | border () const |
| const GLColor & | border_color () const |
| void | add_hook (const RenderHook &) |
| This function allows one drawable to add an overlay to another. | |
| void | render () |
| This method renders the drawable itself plus any overlays. | |
| virtual void | gl_cleanup () |
| virtual | ~Drawable () |
| Clean-up. | |
| bool | invisible () const |
| bool | visible () const |
| virtual void | zoom_by (float dz) |
| Drawables can support zoom/pan and keypress events. | |
| virtual void | pan (int curr_x, int curr_y, int prev_x, int prev_y) |
| virtual void | reset_zoom_pan () |
| virtual void | keypress (unsigned char key) |
Protected Types | |
| typedef void(* | RenderCB )(unsigned long client_data) |
|
typedef std::pair< RenderCB, unsigned long > | RenderHook |
Protected Member Functions | |
| Drawable (const std::string &, const Geometry &) | |
| void | viz_lock () |
| void | viz_unlock () |
| void | unit_view_volume () const |
| Some helper methods. | |
| void | text_view_volume () const |
| void | setup_view_volume (float L, float R, float B, float T) const |
| void | restore_view_volume () const |
Protected Attributes | |
| bool | m_border |
| GLColor | m_border_color |
| Geometry | m_geometry |
A base class for Robolocust drawable objects.
This class provides a common interface that allows the Robolocust main window to render each of the different Robolocust objects.
All drawables will be assigned a drawing area within the main window and must render themselves inside that area. In some cases, a drawable's drawing area is computed by lobot::MainWindow. However, in most cases a drawable's drawing area is simply looked up from the lobot config file.
DEVNOTE: By default, this class's methods are all virtual and empty. They are not pure virtual to ensure that leaf classes that don't care for visualization are not forced to define unnecessary empty methods. For example, lobot::SpeedArbiter does not present any visualization; however, its base class lobot::Arbiter does use lobot::Drawable as a base so as to allow lobot::TurnArbiter to present its visualization.
Of course, we could simply have leaf classes that need to visualize, such as lobot::TurnArbiter, derive directly from lobot::Drawable and then declare all of lobot::Drawable's methods pure virtual. However, we choose not to do it this way because the main thread's lobot::App object would then have to work in terms of the leaf classes/objects.
For the arbiters, that's not a big deal because the Robolocust system only uses two DAMN arbiters and they're both singletons. Unfortunately, the situation is not quite as clean when it comes to behaviours. If we were to require all the leaf classes to derive from lobot::Drawable, then lobot::App would have to downcast to each behaviour's instance and add that to lobot::MainWindow's list of drawables, which pretty much defeats the whole purpose of having a polymorphic factory for creating behaviours.
Instead, by deriving lobot::Behavior from lobot::Drawable, we ensure that all behaviours are drawables and that the main thread need not concern itself with the exact type of each object it creates. Furthermore, a behaviour or other object that does not care to perform any visualization can rely on the empty virtual functions in lobot::Drawable instead of being forced to define empty functions.
Definition at line 117 of file LoDrawable.H.
typedef void(* lobot::Drawable::RenderCB)(unsigned long client_data) [protected] |
In addition to rendering itself, each drawable also supports rendering arbitrary overlays on top of itself. This is useful, for instance, with the open path behaviour, which likes to paint the candidate open paths on top of the LRF data visualization.
Overlays are rendered via callback functions. Client modules register such a callback along with any client data they require to be passed back when the callback is triggered. The client data is always an unsigned long and can be used to pass object pointers that can then be dereferenced inside the callback to invoke a member function.
These types are used to define the rendering callbacks.
Definition at line 170 of file LoDrawable.H.
| lobot::Drawable::Drawable | ( | const std::string & | name, | |
| const Geometry & | g | |||
| ) | [protected] |
A protected constructor because only derived classes can invoke it. And when they do, they must specify the drawable's name and its geometry.
Definition at line 101 of file LoDrawable.C.
| lobot::Drawable::~Drawable | ( | ) | [virtual] |
Clean-up.
Definition at line 214 of file LoDrawable.C.
| void lobot::Drawable::add_hook | ( | const RenderHook & | h | ) |
This function allows one drawable to add an overlay to another.
Definition at line 124 of file LoDrawable.C.
| bool lobot::Drawable::border | ( | ) | const [inline] |
This method returns true if this drawable is configured to have a border drawn around its drawing area within the Robolocust UI.
Definition at line 253 of file LoDrawable.H.
References m_border.
| const GLColor& lobot::Drawable::border_color | ( | ) | const [inline] |
This method returns the color in which the drawable's border should be rendered.
Definition at line 257 of file LoDrawable.H.
References m_border_color.
Referenced by lobot::Map::Map().
| Geometry lobot::Drawable::geometry | ( | ) | const [inline] |
Return this drawable's geometry.
Definition at line 238 of file LoDrawable.H.
| void lobot::Drawable::gl_cleanup | ( | ) | [virtual] |
Just as drawables should refrain from performing GL initialization in their constructors (because the GL rendering context might not yet be available), they should also not perform any GL clean-up in their destructors just in case the rendering context is already gone.
Instead, subclasses should override this method to perform OpenGL related clean-up. lobot::MainWindow will take care of triggering this function for each drawable just before rendering context is released. The default implementation of this method does nothing.
Definition at line 213 of file LoDrawable.C.
| void lobot::Drawable::gl_init | ( | ) | [virtual] |
Drawables should refrain from making any OpenGL calls until they can be absolutely sure that the GL rendering context is open for business. Unfortunately, a drawable cannot by itself determine when this happy situation might prevail. Thus, any OpenGL related initialization that a drawable might want to perform will have to be deferred to this function, which will be called by the lobot::MainWindow object when the time is right, viz., after the GL window is created but before the GL message loop commences and, for drawables created after the commencement of the GL message loop, just before they get added to the main window's drawables list.
The default implementation of this method does nothing. Derived classes may override it if they need to.
Definition at line 122 of file LoDrawable.C.
Referenced by lobot::MainWindow::push_back().
| bool lobot::Drawable::invisible | ( | ) | const [inline] |
These functions check the visibility of this drawable. A drawable that is not visible will not take up any screen space within the Robolocust UI but can still be configured to actively receive and respond to keyboard input.
Definition at line 245 of file LoDrawable.H.
| std::string lobot::Drawable::name | ( | ) | const [inline] |
Return this drawable's name.
Definition at line 235 of file LoDrawable.H.
| void lobot::Drawable::render | ( | ) |
This method renders the drawable itself plus any overlays.
Definition at line 132 of file LoDrawable.C.
| void lobot::Drawable::unit_view_volume | ( | ) | const [protected] |
Some helper methods.
Definition at line 158 of file LoDrawable.C.
| void lobot::Drawable::viz_lock | ( | ) | [inline, protected] |
API for locking and unlocking the visualization mutex.
As mentioned earlier, this class cannot actually enforce proper use of the visualization mutex. (Actually, it could by locking/unlocking before/after the action and render methods; however, that would be too brutal and wasteful as we may only need the locks in small parts of these methods.) Thus, it is up to each derived class to call these functions as and when required.
Definition at line 292 of file LoDrawable.H.
References lobot::Mutex::acquire().
Referenced by lobot::TTIEstimator::compute_distance(), lobot::TTIEstimator::copy_lgmd(), and lobot::TTIEstimator::update().
| void lobot::Drawable::zoom_by | ( | float | dz | ) | [virtual] |
Drawables can support zoom/pan and keypress events.
Definition at line 149 of file LoDrawable.C.
bool lobot::Drawable::m_border [protected] |
By default, we always draw a border around each drawable to help clearly demarcate each of them. However, that may not be appropriate or desirable for some drawables. This flag can be used by derived classes to turn the border off on a case-by-case basis.
Definition at line 205 of file LoDrawable.H.
Referenced by border(), and lobot::Map::Map().
GLColor lobot::Drawable::m_border_color [protected] |
In addition to allowing derived classes to turn the drawable border on or off, we also allow them specify a suitable border color. The default border color is yellow.
Definition at line 210 of file LoDrawable.H.
Referenced by border_color(), and lobot::Map::Map().
1.6.3