diff --git a/src/stage/timeline/view-hook.hpp b/src/stage/timeline/view-hook.hpp new file mode 100644 index 000000000..f896042be --- /dev/null +++ b/src/stage/timeline/view-hook.hpp @@ -0,0 +1,98 @@ +/* + VIEW-HOOK.hpp - abstracted attachment to a canvas or display facility + + Copyright (C) Lumiera.org + 2019, Hermann Vosseler + + 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 view-hook.hpp + ** Allow widgets to connect to a common shared presentation context. + ** This is an abstraction to overcome the problem of cross-cutting a complex + ** hierarchical widget structure in order to maintain a connection to some central + ** presentation entity or canvas. We do not want a central "God class" to manage and + ** remote-control the widgets, nor do we want the widgets to be aware of the hierarchical + ** control structure they are part of. Yet still, widgets typically require to have some + ** access to those shared central structures, especially if they need to "draw themselves". + ** A widget must be able to attach itself to a presentation canvas, and it must be able + ** to control its position thereon. As usual, we solve this problem by abstracting away + ** the actual implementation of the central facility. So widgets get a stage::timeline::ViewHook + ** as access point, which also manages the _lifecycle of this attachment:_ whenever the + ** `ViewHook` is destroyed, the attachment is automatically untied and the widget + ** is deregistered from the central canvas. Widgets thus may want to store the + ** `ViewHook` as member. + ** + ** @todo WIP-WIP-WIP as of 9/2019 + ** + */ + + +#ifndef STAGE_TIMELINE_VIEW_HOOK_H +#define STAGE_TIMELINE_VIEW_HOOK_H + +//#include "stage/gtk-base.hpp" +//#include "lib/symbol.hpp" +//#include "lib/util.hpp" + +//#include +//#include +//#include + + + +namespace stage { +namespace timeline { + +// using lib::Literal; +// using util::isnil; +// using std::forward; + + + /** + * Abstracted attachment onto a display canvas or similar central presentation context. + * A `ViewHook` represents the connection of a Widget into the presentation facility, like + * e.g. placing the widget onto a _canvas_ (`Gtk::Layout`). This way, the widget may control + * details of its placements, while remaining agnostic regarding the implementation details + * of the presentation context. + * + * The prominent example for using a `ViewHook` is the stage::timeline::DisplayFrame maintained + * by the TrackPresenter within the timeline UI. This connection entity allows to place ClipWidget + * elements into the appropriate display region for this track, without exposing the actual + * stage::timeline::BodyCanvasWidget to each and every Clip or Label widget. + * + * @todo WIP-WIP as of 4/2019 + * @todo the number of pinned elements should be a member field, instead of sneaking it into the prelude element... + */ + class ViewHook + { + public: + }; + + + + /** + */ +//inline void +//TrackProfile::performWith () +//{ +//} + + + +}}// namespace stage::timeline +#endif /*STAGE_TIMELINE_VIEW_HOOK_H*/ diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index ec3513235..3d97a547b 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -5658,8 +5658,7 @@ TestControl Dialogbox

- - + @@ -6720,7 +6719,7 @@ - + @@ -18266,6 +18265,33 @@ + + + + + + + + + + +

+ wichtigstes Beispiel: wir verwenden einen gemeinsamen Canvas  (Gtk::Layout) zur Darstellung. +

+

+ Das bedeutet: viele Kind-Widgets werden auf diesem Canvas platziert und müssen daher mit ihm interagieren +

+ + + + + + + + + + + @@ -19343,6 +19369,9 @@ + + + @@ -19932,6 +19961,20 @@ + + + + + + +

+ ermöglicht (abstrahierten) Zugang zum Canvas über einen ViewHook +

+ + + + + @@ -21818,7 +21861,17 @@ - + + + + + + +

+ naheliegend: das BodyCanvasWidget selber +

+ + @@ -21830,6 +21883,7 @@ + @@ -21866,6 +21920,57 @@ + + + + + + + + + + + + +

+ everyone and my grandma does it this way... +

+

+ Kein Wunder daß die meisten UIs aus Sicht des Programmierers ein Albtraum sind +

+ + + + + + + + + + + + + + + +

+ Abstraktion: ViewHook (->Canvas) +

+ + + + + + + + + + + + + + + @@ -22001,14 +22106,14 @@ - + - + - - + + @@ -22017,8 +22122,25 @@ - + + + + + + + + + + + +

+ weil dann innerhalb des Canvas alles konsistent ist +

+ + + + @@ -24227,7 +24349,8 @@ - + + @@ -24255,8 +24378,9 @@ - + + @@ -24270,10 +24394,30 @@ - + + + - + + + + + + + + + + +

+ weil die Canvas-Controls tief eingewickelt in der Struktur liegen +

+ + + + + + @@ -24318,6 +24462,12 @@ + + + + + + @@ -24361,10 +24511,83 @@ + + + + + + + + - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + @@ -33757,7 +33980,7 @@ - +