\documentclass[portrait]{seminar}
\def\myslideheader{{\bf MIDAD, ROOT and Lessons Learned.} ROOT2001}
\def\myslidefooter{Brett Viren, B.N.L.}
\input{preamble.tex}

\definecolor{MyCode}{named}{Red}
\definecolor{RootCode}{named}{Blue}
\definecolor{Crit}{named}{Red}
\definecolor{Sugg}{named}{OliveGreen}

\newcommand{\mcode}[1]{\textcolor{MyCode}{#1}}
\newcommand{\rcode}[1]{\textcolor{RootCode}{#1}}
\newcommand{\crit}[1]{\textcolor{Crit}{#1}}
\newcommand{\sugg}[1]{\textcolor{Sugg}{#1}}

\begin{document}
\slideframe{none}
\pagestyle{fancy}
\centerslidesfalse

\begin{slide*}
  \slideheading{MIDAD: Minos Interactive Data Analysis and Display}

  \vfill
  \resizebox{.49\textwidth}{1cm}{\includegraphics{fardet-muon-001.eps}}
  \resizebox{.49\textwidth}{1cm}{\includegraphics{fardet-nc-001.eps}}

  \resizebox{.49\textwidth}{1cm}{\includegraphics{fardet-muon-002.eps}}
  \resizebox{.49\textwidth}{1cm}{\includegraphics{fardet-nc-002.eps}}

  \resizebox{.49\textwidth}{1cm}{\includegraphics{caldet-001.eps}}
  \resizebox{.49\textwidth}{1cm}{\includegraphics{neardet-numu-001.eps}}

  \resizebox{.49\textwidth}{1cm}{\includegraphics{caldet-002.eps}}
  \resizebox{.49\textwidth}{1cm}{\includegraphics{neardet-numu-002.eps}}

  \begin{itemize}
  \item Minos - mini site report.
  \item Guiding design.
  \item Main Classes of the Framework.
  \item Screenshot of current display.
  \item ROOT: Problems and Suggestions.
    \begin{itemize}
    \item CINT, Rt and TG GUI classes.
    \end{itemize}
  \end{itemize}

  \vfill

  {\footnotesize http://minos.phy.bnl.gov/$\sim$bviren/talks/}

\end{slide*}

\begin{slide*}
  \enlargethispage{100pt}
  {\footnotesize
  \slideheading{MINOS - mini site report}
  \begin{description}
  \item[Hardware] Three somewhat similar detectors:
    \begin{itemize}
    \item Near detector (ND) - at Fermilab.
    \item Far detector (FD) - in northern Minnesota.
    \item Calibration detector (CalDet) - portable - presently in CERN
      test beam
    \end{itemize}
  \item[Software Time Scale]:
    \begin{itemize}
    \item Now$\rightarrow$Sept, 2001, usable prototype ready for
      CalDet and FD (cosmic muons).
    \item 2001$\rightarrow$2003, reassess, redesign, rewrite as
      necessary.
    \end{itemize}
  \item[Current Software Strategy]: Heavy use of ROOT.  Little attempt
    to isolate most of MINOS framework from ROOT.
  \end{description}

  Comments from Sept, 2000 MINOS software review:
  (paraphrased from several external reviewers)
    
  \sugg{``[In your software infrastructure you should be using C++ constructs
  like templates, exceptions, RTTI, STL containers/iterators, standard
  library, etc., instead of letting ROOT usage dictate which subset of
  the C++ standard language you work in.]''}
    
  
  Minos software future:
  \begin{itemize}
  \item How ROOT evolves is likely to determine whether or how we need
    to moderate our use of ROOT to meet these criticisms.
  \end{itemize}
  }
\end{slide*}

\begin{slide*}
  \slideheading{Major MIDAD Design Criteria}
  \begin{itemize}
  \item Present multiple graphical and non graphical representations
    of data and MC objects.
  \item Display multiple objects, eg. raw data, reconstructed
    tracks/showers, MC truth.
  \item Ability to easily add custom displays.
  \item Ability to ``mark-up'' a display with text/arrows.
  \item Allow display of standard and custom user histograms.
  \item Allow user drawing code.
  \item Ability to drive reconstruction with interactively altered
    data.
  \end{itemize}
\end{slide*}

\begin{slide*}
  \slideheading{Model-View-Controller pattern}
  \sizedfig{\textwidth}{mvc.eps}

  \begin{description}
  \item[Model] Encapsulates data, signals when data is
    modified, exports interface to modify data.
  \item[View] Passive display of data, told by model if data is
    changed.
  \item[Controller] Modifies data via Model's interface.
  \end{description}

  {\tiny \underline{Pattern-Oriented Software Arch, A Sys. of Patterns}, Buschmann, {\it et.al.}}
\end{slide*}

\begin{slide*}
  \slideheading{Main MIDAD Framework classes}
  \vfill
  \begin{description}
  \item[{Model}] A \rcode{TQObject} derived base class for
    encapsulating a data/MC object (hits, track, showers, etc).
    Maintains meta-data (eg. selected hits).  Emits an \rcode{Rt}
    signal when meta data changes.
  \item[{Viewable}] A \rcode{TNamed and TQObject} derived base class
    for graphical representations of particular \mcode{Model}.  Emits
    \rcode{Rt} signals on mouse enter/exit/click.
  \item[{View}] A \rcode{TPad} derived class to which
    \mcode{Viewable}s are added.  Accepts only \mcode{Viewable}s which
    implement a particular view type (projection).  Emits \rcode{Rt}
    signals in response to selections.
  \item[{DisplayBase}] A \rcode{TGMainFrame} derived base class for
    collecting one or more \mcode{View}s and other GUI elements.
    Installs \mcode{Viewable}s in to its \mcode{View}s.
  \end{description}
  \vfill
\end{slide*}


\begin{slide*}
  \slideheading{Supportive Management Classes}
  \vfill
  \begin{description}
  \item[{ViewableProxy}] templated class instantiated as a static object
    at link time, one for each concrete \mcode{Viewable} type.  Used to
    register the concrete \mcode{Viewable} type and provide creator functions.
  \item[{ViewableReg}] Singleton holding registered \mcode{ViewableProxy}s,
    responsible for creating \mcode{Viewable}s.
  \item[{ModelProxy}] Same as \mcode{ViewableProxy}, but for
    concrete \mcode{Model}s.
  \item[{ModelHistory}] Holds collection of one type of \mcode{Model}.
    Emits an \rcode{Rt} signal when \mcode{Model}s are added/removed.
    Allows for undo/redo.  Creates \mcode{Model}s by name.
  \item[{ModelPool}] Like \mcode{ViewableReg} but creates/leases
    \mcode{ModelHistory}s.
  \end{description}
  \vfill
\end{slide*}

\begin{slide*}
  \slideheading{Registry} 

  \begin{itemize}
  \item Used to configure Viewables (and other MINOS objects).
  \item Heterogenous, type safe mapping from strings typed keys to
    arbitrary typed values. 
  \item Traverses ROOT I/O.
  \end{itemize}
  \begin{center}
    \sizedfig{0.7\textwidth}{registry.eps}
  \end{center}
\end{slide*}

% \begin{slide*}
%  \sizedfig{0.9\textwidth}{models.eps}
%\end{slide*}
%\begin{slide*}
%  \sizedfig{0.95\textwidth}{views.eps}
%\end{slide*}

\begin{slide*}
  \slideheading{Example Screenshot}
  % no sizing - bitmap source
  \begin{center}
      \includegraphics{midad-screenshot.eps}

  First and very simple MIDAD display.
  \end{center}
\end{slide*}

\begin{slide*}
  \slideheading{Coding with ROOT, Problems and Suggestions}

  \begin{itemize}
  \item ROOT has much to be praised for.
    \begin{itemize}
    \item Comprehensive, becoming well documented.
    \item Strong and knowledgeable community testing, debugging and
      improving it.
    \item Rene, Fons and Masaharu are quick to help, address problems
      and integrate new features.
    \end{itemize}
  \item However, it's more useful to criticize it than to praise.
  \item The following is based on difficulties developing MIDAD,
    particularly in the area of trying to use templates with ROOT.
  \end{itemize}
    
\end{slide*}
\begin{slide*}
  \slideheading{CINT}
  {\small
    
    CINT is very cool.  For rapid development under ROOT, it is very
    useful.  Given the complexity of interpreting C++, it is
    understandable that CINT is not 100\% perfect.

%    \crit{A ``cmd arg1 arg2'' type command line language.  KUIP will
%      likely get implemented over and over.}\\
%    \sugg{Add hooks for a simpler command line for simple tasks
%      ``hist/plot h1''.  Ease PAW transitions.}
    
    \vfill

    \crit{CINT inside compiled code leads to hidden/confusing
      dependencies (TApplication $\leftrightarrow$ TRootGuiFactory).} \\
    \sugg{Uncertain.  Why is it necessary?.}
    
    \crit{Modern C++ (STL, templates, exceptions, namespaces). Partial
      CINT support (and improving), ROOT containers, TString redundant
      with STL.}\\
    \sugg{ROOT predates STL, but will it adapt/adopt?  Wish: full
      template support in CINT, ROOT subclasses STL containers and
      strings.}
    
    \crit{Linkdef.h ordering is critical w/ templates.}\\
    \sugg{Document rules / likely problems helps. Solution?}
    
    \crit{CPP macros (ClassDef\{,T,TT,...,T2,TT2,...,Nested\} \&
      ClassImp\{,T,TT,...,Q,Nested\}) not scalable nor clear.} \\
    \sugg{Can templates + inheritance help? $\rightarrow$ Proxy.}
    
    }

    \vfill

\end{slide*}


\begin{slide*}
  \slideheading{Templated Proxy}
  \sizedfig{\textwidth}{proxy.eps}

{\footnotesize
\begin{source}
// MyRootClass.cxx (IsA TObject)
#include "MyRootClass.h"
// ...
static Proxy<MyRootClass> 
        gsMyRootClassProxy("MyRootClass");
// ...
\end{source}
}
\end{slide*}

\begin{slide*}
  \slideheading{CINT as both interpreter and MOP.}
  
  \crit{CINT is used for both ROOT's extension \& scripting language
    as well as providing ROOT with a Meta-Object Protocol (MOP) to
    extend the C++ language (Dictionary, Serialization).}
 
 \sugg{Interesting alternative: \textbf{OpenC++}.
    \begin{itemize}
    \item Compile time MOP.
    \item Extended C++ language (less so than CINT).  No CPP macros
      nor cmds in comments.
    \item Emits standard C++ code.
    \item MOP allows for object persistence (I/O).
    \item Allows optimizations like: \\
      \texttt{Matrix m = m1+m2+m3;}
    \item {\footnotesize http://www.csg.is.titech.ac.jp/$\sim$chiba/openc++.html}
    \item {\footnotesize See ``A Metaobject Protocol For C++'', S.
        Chiba (available from above).}
    \end{itemize}
    }
\end{slide*}


\begin{slide*}
  \enlargethispage{100pt}
  {\small
  \slideheading{Rt Signal/Slot mechanism} 
  
  Some praise:
  \begin{itemize}
  \item Signal/slot mechanism is very useful, almost indispensable,
    part of a class library.
  \item Rt is a good implementation and works well with what it has
    as a base (CINT).
  \item Sig/slots bridge the compiled/interpreted gap.
  \end{itemize}
  
  \crit{
    Some criticism:
    \begin{itemize}
    \item Run-time and string based nature leads to programming errors
      \& reliance on CINT in compiled code.
    \item Multiple or user types must be passed by casting pointers to
      Long\_t.
    \item Binding args at connection time done via
      \code{sprintf()}'ing address into char buffer.
    \item Quiet failures (Valeriy: ``existing checks unused - no
      interpreted class Dictionaries'').
    \item No templated signals or slots (CINT limitation).
    \end{itemize}
    }
  
  \sugg{Suggestion:
    \begin{itemize}
    \item Consider libsigc++ (libsigc.sourceforge.net).
    \end{itemize}
    }
  }    
\end{slide*}

\begin{slide*}
  \enlargethispage{100pt}
  {\small
    \slideheading{TG GUI Classes and TGuiFactory}
    
    Praise: Cross platform. Integrated (a good thing?). Some support for
    implementation in other GUIs (Denis Bertini's QtRoot, my embryonic
    GtkRoot)

    \crit{
      Some Criticism:
      \begin{itemize}
      \item Documentation slim.
      \item Difficult/confusing design.  Not as high quality as
        ``professional'' GUI TKs (eg. Qt, Gtk).
      \item Need more widgets implemented.
      \item Tie between TG imp and rest of Root is too tight.
      \item GUI's best handled by GUI experts.
      \end{itemize}
      }

    \sugg{
      Suggestions (fairly obvious):
      \begin{itemize}
      \item Docs for use, extension and implementation of GUI.
      \item Keep accepting contributed TG widgets {\footnotesize
          (blatant plug: TGTableLayout.  Think HTML/\LaTeX{} tables
          holding widgets in heterogenous columns/rows)}.
      \item Continue to be open to the adoption/support of QtRoot,
        GtkRoot and future XxxRoot $\rightarrow$ helps keep ROOT
        modular and broadens ROOT's appeal and thus outside contribution.
      \end{itemize}
      }

  }
\end{slide*}

\begin{slide*}
  \slideheading{Summary}
  \begin{itemize}
  \item An event display framework for MINOS has been (and continues
    to be) developed.
  \item Much of this development was made possible by the quality and
    quantity of ROOT's feature set, documentation, community and
    developer support.
  \item Various perceived problems were given and possible suggestions
    were offered in the hopes of making ROOT even better.
  \item Underlining these suggestions is a wish for ROOT to work
    towards continuing to better its support for ``modern'' C++
    features, particularly templates.
  \end{itemize}
\end{slide*}
\end{document}