#include <smartptr.h>
#include <mathGutz.h>
#include <arrayGutz.h>
#include <eventGutz.h>
#include <signalGutz.h>
#include <vector>
#include <list>
#include "Constraint.h"
#include "WidgetState.h"
#include "../renderable/Renderable.h"
#include <iostream>
Go to the source code of this file.
Compounds | |
| class | WidgetItem |
| The widget item base class, virtual, needs a concrete sub-class to do anything. More... | |
Typedefs | |
| typedef gutz::SmartPtr< WidgetItem > | WidgetItemSP |
| typedef std::vector< WidgetItemSP > | WidgetItemSPVec |
| typedef WidgetItemSPVec::iterator | WidgetItemSPVecIter |
| typedef std::list< WidgetItemSP > | WidgetItemSPList |
| typedef WidgetItemSPList::iterator | WidgetItemSPListIter |
| typedef WidgetItemSPList::const_iterator | WidgetItemSPListCIter |
Variables | |
| WidgetItem | operator |
| The widget item base class, virtual, needs a concrete sub-class to do anything. | |
| gutz::EventKeyMap | _eventMap |
| ConstraintMap | _constraintMap |
| ColorWStateSP | _color |
| carefull, you need to check if this is a NULL pointer | |
|
|
Definition at line 454 of file WidgetBase.h. |
|
|
Definition at line 458 of file WidgetBase.h. Referenced by SurfaceContentWidget::getContent(), and SurfaceContentWidget::nukeContent(). |
|
|
Definition at line 460 of file WidgetBase.h. Referenced by SurfaceContentWidget::cloneContent(), and SurfaceContentWidget::copyContent(). |
|
|
Definition at line 459 of file WidgetBase.h. Referenced by SurfaceContentWidget::delContent(), SurfaceContentWidget::drawDef(), SurfaceContentWidget::nukeContent(), and SurfaceContentWidget::setChanged(). |
|
|
Definition at line 455 of file WidgetBase.h. |
|
|
Definition at line 456 of file WidgetBase.h. |
|
|
carefull, you need to check if this is a NULL pointer
Definition at line 451 of file WidgetBase.h. Referenced by GLUEdgeWidget::drawDef(), GLUNodeWidget::drawDef(), WidgetItem::getColor(), GLUEdgeWidget::GLUEdgeWidget(), GLUNodeWidget::GLUNodeWidget(), WidgetItem::setColor(), and WidgetItem::WidgetItem(). |
|
|
Definition at line 449 of file WidgetBase.h. Referenced by WidgetItem::addEvent(), WidgetItem::delEvent(), WidgetItem::getConstraints(), WidgetItem::nukeEvents(), WidgetItem::setConstraints(), and WidgetItem::~WidgetItem(). |
|
|
Definition at line 448 of file WidgetBase.h. Referenced by WidgetItem::addEvent(), WidgetItem::delEvent(), WidgetItem::getEvent(), WidgetItem::getEvents(), WidgetItem::nukeEvents(), WidgetItem::setEvents(), and WidgetItem::~WidgetItem(). |
|
|
The widget item base class, virtual, needs a concrete sub-class to do anything. We are using the Renderable interface for mouse events, so the name & cast for gl style picking is: RENDERABLE_NAME and "(unsigned int)(Renderable*)this", respectively. See: Renderable.h. The widget framework is divided into 2 layers.
The Behavior layer defines how widgets interact and are constrained to one another. This level describes how the widgets move, but now how they look. The Appearance layer defines how they look. For instance, we are most likely using minimal OpenGL widget geometry, like GLU quadric objects. These are balls, tubes, cones, etc... We might also like to use widgets in 2D without opengl, or maybe develop a custom "skin" to make our widgets look different than everyone else's. Whatever the reason, we can easly customize the appearance of the widgets by creating new concrete basic widgets that simply draw the geometry we want, with any shader, colors etc. This only requires the implementation of a few functions, for instance: float draw( const gutz::RenderEvent &re ); WidgetItem *clone(); // and possibly these if applicable: void _invalidate(); void _update(); The actions described by widgets are very general, for the most part they contain information about spatial position or some parameter that they represent. There is realy no need to create a new widget everytime you need some new action, nearly all widgets contain signals, see gutz::Signal. These signals are called whenever the parameter of interest changes, which can be captured by your class that implements the action associated with that parameter. For instance, you may want some kind of clipping plane for opengl. Your instinct might say, subclass FrameWiget and have it handle the clipping action. That would lead to a mas-proliferation of "special" widgets that differ from their base class only in how they implement the symantics of the widget. It is far better to create a "ClipObject" that gets "connected", see gutz::connect(), to the FrameWidget::planeChanged signal. Whenever the user modifies the position/orientation of the FrameWidget, the ClipObject will recieve the planeChanged signal and update the clipping plane. This kind of sepparation is important since it could become difficult to maintain and improve the widget framework if there are many classes that "know" about how the widget is implemented.
Of course you will want to build custom widgets with a slider here, another bar there, whatever. You should. But remember to keep the behavior implentation higher in the hierarchy, the appearance lower (most derived), and little or no built in symantics, just signals to communicate parameter changes. The divison between NodeWidget and GLUNodeWidget illustrates the sepparation between behavior and appearance: NodeWidget handles the behavior, and GLUNodeWidget handles the specific appearance for GLU spheres. Behavior implementation should always reside above any and all apperance implementation in the class hierarchy. All parameters, such as position and orientation should be delivered in "WORLD" space; see gutz::BaseManip for a definition of this. By delivered, I mean when you call getPoint, getPos, getOrient, etc... or recieve a signal such as pointChanged etc.. these positions and orientations should always be in "WORLD" space, not the local frame that the widget may live in. It is very likely that widgets store these parameters in a Manip, so as you might expect, this means that we are using gutz::BaseManip::getWorldPos() when you ask for a widget's position. This also means that any setPos functions should use positions/orientations that are defined in "WORLD" space. The widget is responsible for transforming these parameters into their local frame. See also WidgetFactory, gutz::Signal, gutz::connect, gutz::disconnect. |
