SCI Seg3D Mailing List

Text archives Help


[Seg3D] Re: what's Painter::set_status for?


Chronological Thread 
  • From: Michael Callahan <callahan@sci.utah.edu>
  • To: seg3d@sci.utah.edu
  • Subject: [Seg3D] Re: what's Painter::set_status for?
  • Date: Tue, 13 Oct 2009 10:07:44 -0600
Much of the GUI and code confusion comes from the fact that there are
two different GUIs in operation within Seg3D.  This is somewhat
unavoidable as current GUI toolkits do not integrate well with 3D
scenes.  The best you get is 3D windows in your 2D programs.  Thus if
you want to have GUI components in the 3D window you need to do this
work yourself.

McKay dreamt up Skinner to solve some of these problems at the time.
The general idea was that you needed to do the 3D gui elements anyway
and thus you might as well draw all the 2D elements using the same
system.  That way you would get a consistent GUI across the programs
and across different platforms.  It also had nice portability features
as all you needed to get a GUI working was an OpenGL window.  Other
features would be that the GUI could be specified via XML files, the
gui would be multi-threaded, and the variables would be the dynamic
string tree things that they for backwards compatability with the
SCIRun tcl world.  Interestingly modern GUIs are moving in the 3D
direction with toolkits like XAML for windows and Clutter for Linux.

The second GUI is WxWidgets.  At the time Qt was GPLed and so we went
with the more liberal licensing of WxWidgets.  We also went with
DialogBlox to build the GUIs.  WxWidgets is somewhat of a least common
denominator widget set across different platforms.  However the GUI
needs of Seg3D outside of OpenGL windows aren't all that great.

The primary messiness in using these two GUI models is that they use
different thread concepts.  This makes communications between the two
very clunky with the string passings and the callback function
wrappers used instead of straightforward function calls.  You can see
this for instance in how it bloats up the code used to connect a
simple tool.  You end up having to do the declarations for what the
tool does in duplicate, once for WxWidgets and once for Skinner.

There are two different kind of tools in Seg3D.  The first kind is the
simple non-interactive filters (like crop tool).  Creating these is
somewhat messy at the moment but your prior diagram on all the stuff
needed to make the GUI and connect it up pretty well covers the things
that need to be done.  You make the Menu entry, then the panel, and
then connect all of the panel buttons to the code that actually does
the work.  Theoretically Seg3D should have boiled this down into a
plugin architecture by now so that there aren't 6 or so different
files to touch to do this.  However the work done by such a plugin
architecture would be similar (just automated).

As you have seen, the way this currently works is that the panel is
connected to various skinner parameter variables and then the finish()
function is called when the user presses start to actually compute the
filter.  The simplest tool just reuses the 'optionless' panel and has
no variables.  In this case you just make the menu entry, then make
the skinner callback in PainterSignalTargets and fill in that function
with the actual filter work.

The other tool type is the interactive ones.  These are invoked by
creating the tool class that inherits from Skinner::BaseTool and then
pushing it onto the tool stack for the canvas so it can receive mouse
events and draw things.  For instance SeedTool is used to draw little
crosshairs by various other tools.  PolylineTool shows an example tool
that inherits from the SeedTool.  It uses the SeedTool to manage all
the little control points but overwrites the draw function to also
draw the polyline and has an extra rasterize function to render the
polygon into a mask.

If you are wanting to create a polyspline tool then the fastest way to
do this would be to clone the PolylineTool, clone the polyline GUI,
then rewrite the draw_gl and render functions to work with your
shapes.  Let me know if you want any help with that.

  Michael

On Mon, 2009-10-12 at 13:14 +0100, Ramón Casero Cañas wrote:
> Hi all,
> 
> As I read through the code, it is a bit difficult to figure out what 
> many functions do, sometimes where they are declared/defined, etc. 
> Please don't take this badly, but there aren't many comments to help, or 
> much developer documentation.
> 
> For example, with the Brush Tool, it took a while to figure out that 
> BrushTool::draw_gl is used to draw the circle that tells you where the 
> brush tip is.
> 
> Or with the Crop Tool, that the way the crop is actually done is by 
> sending a FinishEvent with the Start button. The event then gets 
> propagated up to CropTool::finish(). It is in finish() where the "Crop" 
> (start button) functionality is implemented.
> 
> I am trying to document the event process,
> 
> http://paracommunications.org/wiki/index.php/Adding_a_new_filter_to_Seg3D#Diagram_of_the_Seg3D_tool_signal.2Fevent_system
> 
> But I just realised that things work differently depending on whether 
> one needs to get a value from the GUI (e.g. from a spin box) or not, so 
> I will make a new diagram for the latter case.
> 
> 
> One of the functions that has me puzzled is Painter::set_status. What is 
> it for? I'd say it is maybe for some kind of log file for debugging, but 
> I haven't been able to find said file (I generated a status message, and 
> then grepped for it in the whole tree). This function is declared in 
> Painter.h and defined in PainterSignalTargets.cc.
> 
> On a related note, are there any plans to write some kind of 
> documentation, e.g. using doxygen?
> 
> 
> Cheers,
> 
> Ramon.
> 


Archive powered by MHonArc 2.6.16.

Top of page