continue drafting the Player control elements -- life timevalue changes

src/include/play-facade.h

@@ -92,9 +92,22 @@ namespace lumiera {
           {
           public:
             void play(bool);          ///< play/pause toggle
+            void scrub(bool);         ///< scrubbing playback
             void adjustSpeed(double); ///< playback speed control
-            void go(lib::time::Time); 
-            /////////////////////////////TODO how to modify the Loop range, the playback mode, scrubbing?
+            void go(lib::time::Time); ///< skip to the given point in time
+            
+            void controlPlayhead (lib::time::TimeControl & ctrl);
+            void controlDuration (lib::time::TimeControl & ctrl);
+            void controlLooping  (lib::time::TimeControl & ctrl);
+            
+            void useProxyMedia (bool);
+            void setQuality (uint);
+            
+            bool is_playing()   const;
+            bool is_scrubbing() const;
+            double getSpeed()   const;
+            uint getQuality()   const;
+            bool usesProxy()    const;
           };
         
         

src/lib/time/control.hpp

@@ -0,0 +1,102 @@
+/*
+  CONTROL.hpp  -  a life time control for feedback and mutation  
+
+  Copyright (C)         Lumiera.org
+    2011,               Hermann Vosseler <Ichthyostega@web.de>
+
+  This program is free software; you can redistribute it and/or
+  modify it under the terms of the GNU General Public License as
+  published by the Free Software Foundation; either version 2 of
+  the License, or (at your option) any later version.
+
+  This program is distributed in the hope that it will be useful,
+  but WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+  GNU General Public License for more details.
+
+  You should have received a copy of the GNU General Public License
+  along with this program; if not, write to the Free Software
+  Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+
+*/
+
+
+/** @file control.hpp
+ ** Manipulating and monitoring time entities with life changes.
+ ** This is an control- and callback element to handle any kind of "running"
+ ** time entities. This element is to be provided by the client and then attached
+ ** to the target time entity as a time::Mutation. Internally, a life connection to
+ ** the target is built, allowing both to 
+ ** - to manipulate the target by invoking the function operator
+ ** - to receive change notifications by installing a callback functor.
+ ** 
+ ** The actual type of the changes and modifications is specified as template parameter;
+ ** when later attached to some time entity as a Mutation, the actual changes to be performed
+ ** depend both on this change type and the type of the target time entity (double dispatch).
+ ** The behaviour is similar to applying a static time::Mutation
+ ** 
+ ** \par relevance
+ ** This control element is intended to be used for all kinds of editing and monitoring
+ ** of time-like entities -- be it the running time display in a GUI widget, a ruler marker
+ ** which can be dragged, a modifiable selection or the animated playhead cursor.
+ ** 
+ ** @todo WIP-WIP-WIP
+ **
+ */
+
+#ifndef LIB_TIME_CONTROL_H
+#define LIB_TIME_CONTROL_H
+
+#include "lib/error.hpp"
+#include "lib/time/mutation.hpp"
+//#include "lib/symbol.hpp"
+
+//#include <boost/noncopyable.hpp>
+//#include <iostream>
+//#include <boost/operators.hpp>
+#include <tr1/functional>
+//#include <string>
+
+
+namespace lib {
+namespace time {
+  
+//using lib::Symbol;
+//using std::string;
+//using lib::Literal;
+  using std::tr1::function;
+  
+//LUMIERA_ERROR_DECLARE (INVALID_MUTATION); ///< Changing a time value in this way was not designated
+  
+  typedef function<void(TI)> timeSignal;
+  
+  /**
+   * Interface: controller-element for retrieving and
+   * changing running time values
+   * 
+   * @see time::Mutation
+   * @see time::TimeSpan#accept(Mutation const&)
+   * @todo WIP-WIP-WIP
+   */
+  template<class TI>
+  class Control
+    : Mutation
+    , timeSignal
+    {
+    public:
+      /** install a callback functor to be invoked
+       *  to notify for any changes to the observed
+       *  time entity */
+      void connectChangeNotification (timeSignal);
+      
+      /** disconnect from observed entity and
+       *  cease any change notification */
+      void disconnnect();
+      
+    };
+  
+  
+  
+  
+}} // lib::time
+#endif

wiki/renderengine.html

@@ -6782,7 +6782,7 @@ Thus no server and no network connection is needed. Simply open the file in your
  * see [[Homepage|http://tiddlywiki.com]], [[Wiki-Markup|http://tiddlywiki.org/wiki/TiddlyWiki_Markup]]
 </pre>
 </div>
-<div title="TimeMutation" modifier="Ichthyostega" modified="201104252343" created="201101231344" tags="spec discuss draft" changecount="38">
+<div title="TimeMutation" modifier="Ichthyostega" modified="201105250040" created="201101231344" tags="spec discuss draft" changecount="41">
 <pre>Simple time points are just like values and thus easy to change. The difficulties arise when time values are to be //quantised to an existing time grid.// The first relevant point to note is that for quantised time values, the effect of a change can be disproportional to the cause. Small changes below the threshold might be accumulated, and a tiny change might trigger a jump to the next grid point. While this might be annoying, the yet more complex questions arise when we acknowledge that the amount of the change itself might be related to a time grid.
 
 The problem with modification of quantised values highlights an inner contradiction or conflicting goals within the design
@@ -6843,27 +6843,30 @@ As rationale, consider the following
 * by materialising a quantised change prior to applying it, we get the &quot;chaining effect&quot;
 
 ----------
-!!! solutions ideas{{red{WIP 12/10}}}
+this leads to the following solutions approach
 * time values are immutable (as far as possible)
-* only allow to assign a completely new setting
-* only accept raw time values for redefining a quantised interval
-* only accept an abstract //modification object.// &amp;rarr;{{red{No! any kind of abstraction requires an indirection}}}
+* for simple time calculations the ~TimeVar is sufficient
+* but we allow to fed an abstract //modification object.//
+* ''nudge by unit(s)'' is subsumed here as a special case
 
-{{red{Question 3/11}}} -- can we avoid accepting mutations for Time (and thus only mutate ~TimeSpan)?
+As the actual change logic to apply depends both on the target value and the kind of the change, we end up with //double dispatch.//
+
+ -- can we avoid accepting mutations for Time (and thus only mutate ~TimeSpan)?
 Rationale: allowing mutations for Time bears the danger of making ~TimeVar obsolete
 * //4/11 yes, implementing it now this way....//
 * we have ~TimeVar, so the only thing that //needs// to be mutable is a whole object &amp;rArr; ~TimeSpan
 * err, because MObject will include a Duration separate from the start time in the Placement, Duration needs to be mutable too
 
 !!!usage considerations
-Question is: how fine grained and configurable needs this to be?
-* for example, when moving a clip taken from 50fps media, the new position might be quantised to the 50fps grid established by the media, while the target timeline runs with 25fps, allowing for finer adjustments based on the intermediate frames present in the source material.
-* likely we need a &quot;nudge by unit(s)&quot;
+{{red{Question 5/11}}} when moving a clip taken from 50fps media, the new position might be quantised to the 50fps grid established by the media, while the target timeline runs with 25fps, allowing for finer adjustments based on the intermediate frames present in the source material.
 
-!!! design draft
+!!!design draft
 The special focus of this problem seems to lead itself to a __visitor pattern__ based implementation. Because the basic hierarchy of applicable types is fixed, but the behaviour is open ended (and not yet fully determined). A conventional implementation would scatter this behaviour over all the time entities, thus making it hard to understand and reason about. The classical ~GoF cyclic visitor solution to the contrary allows us to arrange closely related behaviour into thematically grouped visitor classes. As a plus, the concrete action can be bound dynamically, allowing for more flexibility when it comes to dealing with the intricate situations when a quantised time span (= a clip) recieves a quantised mutation (= is re-alligend to a possibly different frame grid)
 
 Thus the possibly mutalble time entities get an {{{accept(time::Mutation&amp;)}}} function, which is defined to reflect back into the (virtual) visitation functions of the Mutation Interface. Additionally, we provide some static convenience shortcuts right in the Mutation interface, performing the trivial mutations.
+
+!!!life value changes and monitoring
+Based on this time::Mutation design, we provide a specialised element for dealing with //running time values:// When attached to a target time entity, a &quot;life&quot; connection is established. From then on, continuous changes and mutations can be fed to the target by invoking a functor interface. Besides, a change notification signal (callback) can be installed, which will be invoked on each change. This element is the foundation for implementing all kinds of running time display widgets, spin buttons, timeline selections, playheads, loop playback and similar.
 </pre>
 </div>
 <div title="TimeQuant" modifier="Ichthyostega" modified="201101232031" created="201012181753" tags="Concepts Player spec img discuss draft" changecount="50">