ichthyo/LUMIERA.clone
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

DOC: reorganise time handling pages (use Linkfarm)

Browse source 
Create a new subcategory "design/architecture/time"
and rearrange several pages related to time handling and time codes.

NOTE: starting with this changeset, a ''Link-Farm'' is required for cross-links;
since we don't have an automatic solution for this task yet, I have created
the necessary forwarding pages manually in the website repository.
This commit is contained in:
Fischlurch 2025-09-05 03:17:43 +02:00
parent 25eb6a61e3
commit 217ec447c0
13 changed files with 586 additions and 35 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

16
doc/design/architecture/playRender.txt → doc/design/architecture/Playback.txt
View file

@ -3,7 +3,7 @@ Design: Playback and Render Control
:Author: Ichthyostega :Author: Ichthyostega
:Date: 5/2011 :Date: 5/2011
//MENU: label Player subsystem //MENU: label Playback
************************************************************************************** **************************************************************************************
This part of the architecture is concerned with how to initiate, coordinate and control This part of the architecture is concerned with how to initiate, coordinate and control
@ -24,10 +24,12 @@ discussions and brainstorming sessions.
* discussions regarding time values and timecode handling shed some light on the requirements * discussions regarding time values and timecode handling shed some light on the requirements
to be fulfilled by a player subsystem to be fulfilled by a player subsystem
- link:http://article.gmane.org/gmane.comp.video.lumiera.general/2116[Timecode Widget and Framerates] - https://lists.lumiera.org/pipermail/lumiera/2010-July/001984.html[Timecode formats and time widget]
- link:http://article.gmane.org/gmane.comp.video.lumiera.general/2109[Time, Time-spans, Quatisation and Timecode] - https://lists.lumiera.org/pipermail/lumiera/2010-December/002197.html[Timecode Widget and Framerates]
- link:{l}/wiki/renderengine.html#TimeQuant[Definition of Time entities] - https://lists.lumiera.org/pipermail/lumiera/2010-December/002190.html[Time, Time-spans, Quatisation and Timecode]
from the implementation notes in the TiddlyWiki
* at the _framework level_ a set of definitions has been created to handle
link:/x/TimeUsage.html[time values and quantisation].
Reasoning Behind the Player Subsystem's Structure Reasoning Behind the Player Subsystem's Structure
@ -152,8 +154,8 @@ reconfigure the vault layer services.
Frame quantisation Frame quantisation
^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^
link:../TimeQuant.html[Quantisation] is a kind of rounding; like any kind of rounding, quantisation is link:/x/TimeQuant.html[Quantisation] is a kind of rounding; like any kind of rounding,
a dangerous operation because it kills information content. quantisation is a dangerous operation because it kills information content.
Thus, there are three fundamental guidelines when it comes to rounding: Thus, there are three fundamental guidelines when it comes to rounding:

9
doc/design/architecture/index.txt
View file

@ -5,7 +5,6 @@ Design Documents: Lumiera Architecture
// Menu : prepend child Subsystems // Menu : prepend child Subsystems
// Menu : prepend child ArchitectureSummary // Menu : prepend child ArchitectureSummary
// Menu : attach child TimeQuant after TimeUsage
This section will feature some rather high-level considerations regarding This section will feature some rather high-level considerations regarding
the architecture of the application. the architecture of the application.
@ -14,6 +13,12 @@ the architecture of the application.
See link:ArchitectureSummary.html[here] for a short summary of the core architecture See link:ArchitectureSummary.html[here] for a short summary of the core architecture
ideas of the envisioned Lumiera Application. ideas of the envisioned Lumiera Application.
.Time and Time-code
link:time/[Handling of time values] and link:time/TimeCode.html[Time Code] is
essential for an editing application and requires some forethought to avoid
some of the common inconsistencies and pitfalls; precision can be a challenge,
given the extremely large range of time scales to cover.
.Rendering and Playback Control .Rendering and Playback Control
This part of the architecture is concened with how to initiate, coordinate and control This part of the architecture is concened with how to initiate, coordinate and control
the calculation processes necessary to generate visible / audible data from our source the calculation processes necessary to generate visible / audible data from our source
@ -21,6 +26,6 @@ media. This design is _not so much_ concerned with the actual calculations; inde
takes on an ``bird eye's view'', treating the actual render engine mostly just as an takes on an ``bird eye's view'', treating the actual render engine mostly just as an
opaque entity providing some service. opaque entity providing some service.
-> link:playRender.html[Design: Playback and Rendering] -> link:Playback.html[Design: Playback and Rendering]

13
doc/design/architecture/time/TimeCode.txt Normal file
View file

@ -0,0 +1,13 @@
Handling of Time Code Formats
=============================
.A Design draft
Since handling of time values and time code formats is of uttermost importance
for editing film, a draft concept was created in the early phase of Lumiera design.
The chosen approach relies heavily on a framework for representation of temporal data
developed for this purpose in the Lumiera support library. However, the implementation
of various actual time code formats was deferred for later -- while the viability of
this design yet needs to be validated by actual usage.
Detailed analysis and planning can be found in the
link:/x/fwd/DevWiki.TimeCode.html[DevWiki: TimeCode].

48
doc/design/architecture/time/TimeMutation.txt Normal file
View file

@ -0,0 +1,48 @@
Modify Quantised Time Values
============================
.Challenges
Temporal data can be complex and given in several flavours; a request to _modify_
some given time data adds a further layer of complexity, since the required modification
can itself be specified in various forms. And on top of that, the temporal data can be
quantised, or can be represented through a quantised view, while also the modification
can be given in any form of quantification, even based on a different time grid.
When it comes to resolving this kind of multi-layered complexity, it is crucial
to stick to the principles of logically sound reasoning; furthermore, especially
the situation where several disjoint time grids are involved may require some
additional decision rule to determine which grid has to take priority.
.Problematic choices of design
While the Lumiera developers immediately recognised the danger of code quality problems,
there was no consensus how to approach these difficulties. Should everything in the
Render Engine be based on frame counts? Can questions of grid alignment be pushed out
to the system's boundaries? Is grid alignment mostly a problem of UI representation?
An attempt was made to base time handling on simple integral data types, with a plain-C
library to provide quantisation and timecode functions -- which however could not prevent
the proliferation of ad-hoc computations at various places, given that temporal data
seems to be ``just simple numbers''. In an attempt to get this situation under control
before problems start to accumulate and spread, _Ichthyo_ pushed for a radical approach
to rely on the _C++ type system_ and use _opaque_ entities with controlled arithmetic.
Unfortunately, those basic time entities were also defined to be _immutable_ -- following
a trend towards functional programming, which became increasingly popular at that time.
This new framework proved itself successful as a device to identify and eliminate ad-hoc
solutions -- yet state, being a part of the real world, can not be eliminated by dictum,
and will claim it's right sooner or later.
- very soon, a `TimeVar` datatype was introduced, since ``pure'' functional concepts
can never compete with the _intuitivity_ of ``just using numbers''
- from a users point of view, the GUI exposes time-related entities which can be
manipulated -- notably the playback position. An attempt was made, to _encapsulate_
these manipulations as a `time::Control`
In this (slightly compromised) form, the new framework was able to support all
time-data related tasks encountered for the first (GTK-2) version of the UI.
Some more technical explanations can be found in the
link:/x/fwd/DevWiki.TimeMutation.html[DevWiki: TimeMutation].
In hindsight, using opaque types was very successful -- while the immutability seems
to be a mistake and induces a lot of unnatural complications. A design change to
rectify the situation was planned and documented as
link:/x/ticket/1261.html[#1261 »reconsider (im)mutability of time entities«]

12
doc/design/architecture/TimeQuant.txt → doc/design/architecture/time/TimeQuant.txt
View file

@ -44,7 +44,7 @@ changing time::
Time values are _immutable,_ like numbers. Time values are _immutable,_ like numbers.
+ +
Only a *time variable* can be changed -- yet some of the special time entities Only a *time variable* can be changed -- yet some of the special time entities
can recieve link:TimeMutation[mutation messages], allowing e.g. for can receive link:/x/TimeMutation.html[mutation messages], allowing e.g. for
adjustments to a time interval selection from the GUI adjustments to a time interval selection from the GUI
'''' ''''
@ -99,7 +99,7 @@ frame count::
timecode:: timecode::
Quantisation also is the foundation of all kinds of formalised time specifications Quantisation also is the foundation of all kinds of formalised time specifications
actually even a frame count is some kind of (informal) timecode -- other timecodes actually even a frame count is some kind of (informal) timecode -- other timecodes
employ a standardised format. //Every// presentation of time values and every employ a standardised format. _Every_ presentation of time values and every
persistent storage and exchange of such values is based on time codes. persistent storage and exchange of such values is based on time codes.
Yet quantisation and time code aren't identical: a given quantised time value Yet quantisation and time code aren't identical: a given quantised time value
typically can be cast into multiple timecode formats. typically can be cast into multiple timecode formats.
@ -202,11 +202,9 @@ There is a common baseclass `TCode` though, which can be used as marker
or for _type erasure._ or for _type erasure._
-> more on link:TimeUsage.html[usage situations] -> more on link:TimeUsage.html[usage situations]
////
// TODO integrate those cross links
+ +
-> Timecode link:TimecodeFormat[format and quantisation] -> Timecode link:/x/TimeCode.html[format and quantisation]
+ +
-> Quantiser link:QuantiserImpl[implementation details] -> Quantiser link:/x/imp/TimeQuantiser.html[implementation details]
////

18
doc/design/architecture/TimeUsage.txt → doc/design/architecture/time/TimeUsage.txt
View file

@ -8,7 +8,7 @@ Time Usage Situations
the following collection of usage situations helps to shape the details of the the following collection of usage situations helps to shape the details of the
time values and time quantisation design. + time values and time quantisation design. +
-> see also link:TimeQuant.html[more about time quantisation] -> see also link:/x/TimeQuant.html[more about time quantisation]
time position of an object:: time position of an object::
indeed the term ``time position'' encompasses two quite different questions indeed the term ``time position'' encompasses two quite different questions
@ -45,7 +45,7 @@ updating the playback position::
possible loop positions are way finer than the processing block size) possible loop positions are way finer than the processing block size)
dispatching individual frames for calculation:: dispatching individual frames for calculation::
when a link:PlayProcess[render or playback process] is created, at some point when a link:/x/PlayProcess.html[render or playback process] is created, at some point
we need to translate this logical unit (``calculation stream'') into individual we need to translate this logical unit (``calculation stream'') into individual
frame job entries. This requires to break continuous time into individual frame job entries. This requires to break continuous time into individual
frames, and then ennumerating these frames. frames, and then ennumerating these frames.
@ -113,7 +113,7 @@ desirable somehow to move these distinctions out of the scope of this design and
offload them onto the client (code using these time classes). offload them onto the client (code using these time classes).
Another closely related problem is *when to allow mutations*, if at all (-> see Another closely related problem is *when to allow mutations*, if at all (-> see
link:TimeMutation[more here...]). We can't completely do away with mutations, link:/x/TimeMutation.html[more here...]). We can't completely do away with mutations,
simply because we don't have a pure functional language at our disposal. The simply because we don't have a pure functional language at our disposal. The
whole concept of _reference semantics_ doesn't play so well with immutable whole concept of _reference semantics_ doesn't play so well with immutable
objects. The Lumiera high-level (session) model certainly relies on objects objects. The Lumiera high-level (session) model certainly relies on objects
@ -140,8 +140,8 @@ in this case quantised values and quantisation are approached in the reverse
direction, compared with the other uses. Here, after establishing a start point direction, compared with the other uses. Here, after establishing a start point
on the time scale, we proceed with ennumerating distinct frames and later on on the time scale, we proceed with ennumerating distinct frames and later on
need to access the corresponding raw time, especially to find out about the need to access the corresponding raw time, especially to find out about the
link:Segmentation[timeline segment] to address, or for retrieving parameter link:/x/Segmentation.html[timeline segment] to address, or for retrieving parameter
automation. -> link:FrameDispatcher[see frame dispatching]. automation. -> link:/x/FrameDispatcher.html[see frame dispatching].
Note that the *display window might be treated as just an independent instance Note that the *display window might be treated as just an independent instance
of quantisation*. This is similar to the approach taken above for modifying of quantisation*. This is similar to the approach taken above for modifying
@ -176,11 +176,11 @@ closing the circle.
substantial problems to be solved substantial problems to be solved
--------------------------------- ---------------------------------
* how to link:TimeGridAlignment[align multiple grids] * how to align multiple grids -- what grid to use for playback?
* how to integrate link:TimeMutation[modifications of quantised values]. ([green]#✔ solved#) * how to integrate link:/x/TimeMutation.html[modifications of quantised values]. ([green]#✔ solved#)
* how to isolate the Time/Quantisation part from the grid MetaAsset in the * how to isolate the Time/Quantisation part from the grid MetaAsset in the
session -> we use the link:Advice[Advice] system ([green]#✔ solved#) session -> we use the link:/x/Advice.html[Advice] system ([green]#✔ solved#)
* how to design the relation of Timecode, Timecode formatting and Quantisation * how to design the relation of Timecode, Timecode formatting and Quantisation
-> link:TimecodeFormat[more here] [yellow-background]#WIP# -> link:/x/TimeCode.html[more here] [yellow-background]#WIP#

21
doc/design/architecture/time/index.txt Normal file
View file

@ -0,0 +1,21 @@
Time Handling
=============
// Menu : sort children
// Menu : attach child TimeQuant after TimeUsage
// Menu : append child TimeMutation
While Lumiera will be able to handle various kinds of different content and data,
the task of _editing_ implies to arrange elements into a temporal dimension.
Thus representation of time and expression of relations in time plays a pivotal role.
At first sight, time seems to we well-known, commonplace and trivial to understand --
which however is a deception, since anything related to time, timings, duration and
time scales is notoriously difficult to spell out with precision and tricky to
handle in the practice of programming. A high-level discussion should thus
- start with an analysis of link:TimeUsage.html[usage situations]
- alignment to a pre-determined grid scale, the so called
link:TimeQuant.html[Time Quantisation] requires careful attention
- formal representation of link:TimeCode.html[Time Code] is central to film editing.

11
doc/design/engine/PlayProcess.txt Normal file
View file

@ -0,0 +1,11 @@
Playback and Render Processing
==============================
.Prototyping and Exploration
On a conceptual level, this topic reaches far beyond the mere data processing
and is undeniably one of the most complex and interwoven aspects of Lumiera.
As of 2025, most structures in this realm are in a state of prototyping --
many topics are in flux and what works well needs to be figured out yet.
Many detailed notes can be found in the
link:/x/fwd/DevWiki.PlayProcess.html[DevWiki: PlayProcess].

2
doc/design/engine/index.txt
View file

@ -2,5 +2,5 @@ Design Documents: Renderengine
============================== ==============================
This section contains design documents regarding the overall workings of the Render Engine, This section contains design documents regarding the overall workings of the Render Engine,
and the handling of output generation and output connections. data processing and the handling of output generation and output connections.

21
doc/design/model/Segmentation.txt Normal file
View file

@ -0,0 +1,21 @@
Segmentation of Timeline
========================
.A junction between the models
The term ``Segmentation of the Timeline'' describes both a data structure and a step in the
build process, which translates the structures of the *high-level-Model* into a corresponding
graph of Render Nodes. The latter is also known as the *low-level-Model* and can be seen
as a set of preconfigured render pipelines. When such a pipeline is ``pulled''. the render
computations are invoked. The _access points_ to all these pipelines are hooked into a
_backbone_ data structure, designated as the *Fixture* -- which breaks down each top-level
Timeline into a sequence of temporal segments: what differentiates these segments is the
topology of the Render Nodes in the pipeline; whenever a change in this topology is
necessary, a new segment is started. Such a change might e.g. be caused by a transition
between two clips, which has to cover a range of some frames.
As of 2025, this part of the model is only roughly drafted, mostly using placeholder code
to achieve some level of functional integration.
Detailed design planning and explanations can be found in the
link:/x/fwd/DevWiki.Segmentation.html[DevWiki: Segmentation].

2
doc/design/model/index.txt
View file

@ -2,5 +2,5 @@ Design Documents: Model
======================= =======================
* two models: high-level and low-level * two models: high-level and low-level
* RfC: link:{rfc}/../rfc/ProcHighLevelModel.html[high-level model basics] * RfC: link:{rfc}/ProcHighLevelModel.html[high-level model basics]

2
doc/devel/meeting_summary/2011-05-11.txt
View file

@ -20,7 +20,7 @@ Render Engine Interface
_Ichthyo_ had prepared a new _Ichthyo_ had prepared a new
link:/documentation/devel/rfc_pending/EngineInterfaceSpec.html[RfC] link:/documentation/devel/rfc_pending/EngineInterfaceSpec.html[RfC]
about the actual interface between the about the actual interface between the
link:/documentation/design/architecture/playRender.html[Player subsystem] link:/documentation/design/architecture/Playback.html[Player subsystem]
and the Renderengine/Scheduler. and the Renderengine/Scheduler.
The following discussion turned into considering several detaled and technical The following discussion turned into considering several detaled and technical
topics regarding the Jobs to be scheduled, how to create and attach new jobs, topics regarding the Jobs to be scheduled, how to create and attach new jobs,

446
wiki/thinkPad.ichthyo.mm
View file

@ -161542,6 +161542,33 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo
</node> </node>
</node> </node>
<node CREATED="1751833021246" HGAP="10" ID="ID_1501497638" MODIFIED="1751833031779" TEXT="Struktur" VSHIFT="-2"> <node CREATED="1751833021246" HGAP="10" ID="ID_1501497638" MODIFIED="1751833031779" TEXT="Struktur" VSHIFT="-2">
<node CREATED="1756996752814" HGAP="-2" ID="ID_1879816570" MODIFIED="1756996783991" TEXT="Richtlinien" VSHIFT="8">
<icon BUILTIN="yes"/>
<node BACKGROUND_COLOR="#ddceb7" CREATED="1756941531758" HGAP="24" ID="ID_1684054849" LINK="http://localhost:8888/documentation/devel/rfc/DeveloperDocumentationStructure.html" MODIFIED="1756941603712" TEXT="RfC: DeveloperDocumentationStructure" VSHIFT="-10">
<font NAME="SansSerif" SIZE="11"/>
<icon BUILTIN="idea"/>
</node>
<node CREATED="1756996803277" ID="ID_3828783" MODIFIED="1756996966004" TEXT="Hierarchie schlank und daf&#xfc;r tief">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
Wir sollten darauf achten, auf den oberen Ebenen die Anzahl der Kategorien knapp zu halten &#8212; um eine gewisse systematische Auffindbarkeit zu gew&#228;hrleisten; im Gegenzug dazu sind weitere Unterkategorien auf tiefer geschachtelten Ebenen eine praktisch kostenlos verf&#252;gbare Ressource, da die Kapazit&#228;t eines Baumes exponentiell mit der Tiefe w&#228;chst
</p>
</body>
</html></richcontent>
<node CREATED="1756997359532" ID="ID_1783830780" MODIFIED="1756997509579" TEXT="wichtig: Design abstrakt halten">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
Wenn die Design- und Archtektur-Bereiche zu sehr in die Details abgleiten, f&#228;chern sie sich in technische Belange auf, welche nicht mehr so recht systematisch in eine Kategorie passen wollen. F&#252;r die technische Dokumentation ist das kein Problem, denn diese ist ohnehin quantitativ ausgelegt.
</p>
</body>
</html></richcontent>
</node>
</node>
</node>
<node CREATED="1751833032755" ID="ID_1065210302" MODIFIED="1751833034848" TEXT="Gliederung"> <node CREATED="1751833032755" ID="ID_1065210302" MODIFIED="1751833034848" TEXT="Gliederung">
<node CREATED="1751833463677" ID="ID_525672736" MODIFIED="1751833474810" TEXT="Dukumentation im Haupt-Repo"> <node CREATED="1751833463677" ID="ID_525672736" MODIFIED="1751833474810" TEXT="Dukumentation im Haupt-Repo">
<node CREATED="1751833072752" ID="ID_1145154527" MODIFIED="1751833078387" TEXT="Design und Architektur"/> <node CREATED="1751833072752" ID="ID_1145154527" MODIFIED="1751833078387" TEXT="Design und Architektur"/>
@ -161617,6 +161644,190 @@ unsigned int ThreadIdAsInt = *static_cast&lt;unsigned int*&gt;(static_cast&lt;vo
</node> </node>
</node> </node>
</node> </node>
<node CREATED="1756938847705" ID="ID_103170329" MODIFIED="1756938853153" TEXT="Tagging-System">
<node BACKGROUND_COLOR="#ccb59b" COLOR="#6e2a38" CREATED="1756938864201" ID="ID_1398390540" MODIFIED="1756941730894" TEXT="Querverbindungen sind wichtiger als die Systematik">
<linktarget COLOR="#af3956" DESTINATION="ID_1398390540" ENDARROW="Default" ENDINCLINATION="-550;30;" ID="Arrow_ID_1693780597" SOURCE="ID_739075540" STARTARROW="None" STARTINCLINATION="-1134;-80;"/>
<font ITALIC="true" NAME="SansSerif" SIZE="14"/>
<icon BUILTIN="yes"/>
</node>
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1756938903084" ID="ID_1011681098" MODIFIED="1756996665571" TEXT="Grundidee (&#xd83e;&#xdc32; Christian!)">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
wie so oft hatte Christian eine ganz pfiffige L&#246;sung, die <i>zu kurz greift</i>&#160;aber in die <i>richtige Richtung</i>&#160;zeigt (und auf die man erst mal kommen mu&#223;!)
</p>
</body>
</html></richcontent>
<node CREATED="1756939756446" ID="ID_848677930" MODIFIED="1756939768247" TEXT="die Debatte 2012 war kontrovers"/>
<node CREATED="1756939807269" ID="ID_1623672671" LINK="https://Lumiera.org/documentation/devel/rfc/WebsiteSupportMarkup.html" MODIFIED="1756939852312">
<richcontent TYPE="NODE"><html>
<head/>
<body>
<p>
es gibt einen RfC: &#187;<b>WebsiteSupportMarkup</b>&#171;
</p>
</body>
</html></richcontent>
</node>
</node>
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1756941749934" ID="ID_423358953" MODIFIED="1756941796038" TEXT="Implementierung: unklar &#x27f9; inkrementell">
<node CREATED="1756941807662" ID="ID_1476751063" MODIFIED="1756942071658" TEXT="&#xfc;berschneidet sich mit Menuegen.py (auch problematisch)">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
Die Implementierung braucht sehr wahrscheinlich einen kompletten Scan &#252;ber alle Dokumente; das zu vermeiden f&#252;hrt direkt in ein DB-basiertes CMS. Daher, gem&#228;&#223; KISS sollte man erst mal versuchen das zu implementieren und beobachten, wie gro&#223; der Schmerz ist. Auch Menuegen selber war mal in zwei Tagen implementiert, ist schwer zu warten, aber erf&#252;llt seinen Zweck inzwischen seit mehr als 10 Jahren
</p>
</body>
</html></richcontent>
<icon BUILTIN="messagebox_warning"/>
</node>
<node CREATED="1756942074622" ID="ID_1205948049" MODIFIED="1756942200762" TEXT="es ist nicht klar was wir letztlich alles brauchen....">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
Das gr&#246;&#223;te Problem ist wohl, da&#223; wir nicht genau wissen, was wir brauchen (abgesehen von der Vorstellung, <i>irgenwie magisch</i>&#160;funktionierende Cross-Links zu bekommen)...
</p>
<ul>
<li>
wir wollen ein Tag-System, welches um weitere Quellen erweitert werden kann
</li>
<li>
wir wollen m&#246;glichst mit dem Taggen anfangen k&#246;nnen, bevor unser Konzept wirklich klar ist
</li>
<li>
es schwirren viele Ideen herum bez&#252;glich generierter &#220;bersichtsseiten; was uns aber tats&#228;chlich weht tut, ist die Schwierigkeit, Cross-Links in der Dokumentation zu verwenden.
</li>
</ul>
</body>
</html></richcontent>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1756942230234" ID="ID_1854153711" MODIFIED="1756944327464" TEXT="Prototyp: manuell angelegte LInkfarm">
<linktarget COLOR="#fff2d9" DESTINATION="ID_1854153711" ENDARROW="Default" ENDINCLINATION="82;184;" ID="Arrow_ID_789572840" SOURCE="ID_150932933" STARTARROW="None" STARTINCLINATION="-258;-18;"/>
<icon BUILTIN="idea"/>
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1756942253197" ID="ID_1730148338" MODIFIED="1756942500279" STYLE="bubble">
<richcontent TYPE="NODE"><html>
<head/>
<body>
<p style="text-align: right">
nun sind wohl 10 Jahre vergangen
</p>
<p style="text-align: right">
und das Problem besteht unver&#228;ndert
</p>
</body>
</html></richcontent>
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
...was aber vor allem daran liegt, da&#223; ich allein bin und <i>f&#252;r mich sowiso alles per Mindmap organisiere;</i>&#160;daher konnte ich das Problem bisher &#187;aussitzen&#171; &#8212; was aber leider dazu gef&#252;hrt hat, da&#223; das TiddlyWiki (und meine Mindmap) ins Unermessliche gewachsen sind. Dennoch ist das Problem <b>eigentlich brennend ernst</b>: au&#223;er mir blickt keiner durch, und ohne mich findet niemand die Ergebnisse der umfangreichen Konzeptionsarbeit.
</p>
</body>
</html></richcontent>
<edge COLOR="#b82c56"/>
<icon BUILTIN="smiley-angry"/>
</node>
<node CREATED="1756942521652" ID="ID_1783168341" MODIFIED="1756942540564" TEXT="man k&#xf6;nnte prototypisch beginnen">
<node CREATED="1756942581078" ID="ID_1022353279" MODIFIED="1756942594732" TEXT="es gibt einige wenige Seiten, die dringend Querlinks brauchen"/>
<node CREATED="1756942595480" ID="ID_1806644552" MODIFIED="1756942609160" TEXT="an vielen Stellen w&#xe4;re zudem ein Link ins TiddlyWiki notwendig"/>
<node CREATED="1756942662255" ID="ID_197073125" MODIFIED="1756942785932" TEXT="&#xbb;Linkfarm&#xab; war bisher die einzige L&#xf6;sung, die nicht doch wieder ein CMS wird">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
Dieser Vorschlag stammt von Christian, und (selbst wenn der Vorschlag zun&#228;chst in zweifelhaftem Kontext stand) &#8212; es ist die einzige bisher vorgeschlagene L&#246;sung, die mit einfachen Mitteln umsetzbar ist, <b>letztlich sogar ohne jedwede Automatisierung</b>
</p>
</body>
</html></richcontent>
</node>
</node>
<node CREATED="1756942563329" ID="ID_75757480" MODIFIED="1756942913708" TEXT="wenn das Konzept aufgeht, mu&#xdf; man sp&#xe4;ter nur die Linkfarm anpassen">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
...all die weiteren seinerzeit hitzig diskutieren &#187;Killer-Features&#171; sind meines Erachtens Extras, die man oben drauf setzen kann; auch &#220;bersichts- und Kategorieseiten erreicht man letztlich wieder &#252;ber einen ID-Link. Der einzige Knackpunkt ist, das Eingangs-Format der Links so hinzubekommen, da&#223; es tragf&#228;hig ist.
</p>
</body>
</html></richcontent>
</node>
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1757001689681" ID="ID_1598113157" MODIFIED="1757001693588" TEXT="Probleme">
<icon BUILTIN="messagebox_warning"/>
<node CREATED="1757001726624" ID="ID_1645285100" MODIFIED="1757001767376" TEXT="m&#xfc;ssen HTML-Seiten sein">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
Micro-HTTPD expandiert nicht automatisch *.html
</p>
</body>
</html></richcontent>
</node>
<node BACKGROUND_COLOR="#ecb18c" COLOR="#851038" CREATED="1757001696346" ID="ID_1305308451" MODIFIED="1757002190164" TEXT="URL-Struktur relevant">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
Aus mehrerlei Gr&#252;nden
</p>
<ul>
<li>
weil wir generell in der Adresszeile die kanonische URL sehen wollen
</li>
<li>
weil das Navigationsmen&#252; nur mit der kanonischen URL funktioniert
</li>
</ul>
</body>
</html></richcontent>
<icon BUILTIN="stop-sign"/>
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#d9010d" CREATED="1757002194873" HGAP="25" ID="ID_292178403" MODIFIED="1757002221112" TEXT="eine reine Linkfarm gen&#xfc;gt nicht" VSHIFT="4">
<font NAME="SansSerif" SIZE="11"/>
<icon BUILTIN="messagebox_warning"/>
</node>
</node>
<node CREATED="1757001822110" ID="ID_1072758756" MODIFIED="1757001879840" TEXT="&#x27f9; Trampolin verwenden">
<arrowlink COLOR="#6a4954" DESTINATION="ID_489453149" ENDARROW="Default" ENDINCLINATION="-21;-91;" ID="Arrow_ID_1222164953" STARTARROW="None" STARTINCLINATION="-146;17;"/>
</node>
</node>
<node BACKGROUND_COLOR="#ccb59b" COLOR="#6e2a38" CREATED="1756942924060" ID="ID_1637291888" MODIFIED="1756942936542" TEXT="Entwurf">
<font ITALIC="true" NAME="SansSerif" SIZE="14"/>
<icon BUILTIN="yes"/>
<node CREATED="1756942938346" ID="ID_559627723" MODIFIED="1756942952354" TEXT="Root-absolute LInks unterhalb /x"/>
<node CREATED="1756942961742" ID="ID_1442589072" MODIFIED="1756943029121" TEXT="reine ID-Links kommen unmittelbar dort hinein">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
&#187;solange Vorrat reicht&#171; &#8212; die ganze Frage der Duplikat-Resolution kann sp&#228;ter auf technischer Ebene gel&#246;st werden, solange es nur f&#252;r jede verwendete ID einen Link gibt
</p>
</body>
</html></richcontent>
</node>
<node CREATED="1756943030167" ID="ID_1762668578" MODIFIED="1756943037296" TEXT="Kategorie-Unterverzeichnisse">
<node CREATED="1756943038265" ID="ID_273491167" MODIFIED="1756943057343" TEXT="/x/def"/>
<node CREATED="1756943064425" ID="ID_1085430825" MODIFIED="1756943072037" TEXT="/x/spec"/>
<node CREATED="1756943097246" ID="ID_476380016" MODIFIED="1756943102889" TEXT="/x/imp"/>
</node>
<node CREATED="1756943520804" HGAP="31" ID="ID_489453149" MODIFIED="1757002241293" TEXT="Trampolin" VSHIFT="14">
<linktarget COLOR="#6a4954" DESTINATION="ID_489453149" ENDARROW="Default" ENDINCLINATION="-21;-91;" ID="Arrow_ID_1222164953" SOURCE="ID_1072758756" STARTARROW="None" STARTINCLINATION="-146;17;"/>
<node CREATED="1756943525685" ID="ID_1453475345" MODIFIED="1756943626593" TEXT="/x/fwd/&lt;KAT&gt;.&lt;ID&gt;.html"/>
<node CREATED="1756943628727" ID="ID_76298422" MODIFIED="1756943644273" TEXT="&lt;KAT&gt; ist ein Namensraum">
<node CREATED="1757002249262" ID="ID_1425806759" MODIFIED="1757002252346" TEXT="Page"/>
<node CREATED="1756943645452" ID="ID_1064575039" MODIFIED="1756998819278" TEXT="DevWiki"/>
<node CREATED="1756943652176" ID="ID_734902530" MODIFIED="1756943676548" TEXT="SubHeading"/>
<node CREATED="1756943686751" ID="ID_1929602439" MODIFIED="1756943693442" TEXT="CodeBrowser"/>
</node>
<node CREATED="1756943701469" ID="ID_1882952779" MODIFIED="1757001078102" TEXT="die Seiten dort enthalten ein HTML-Redirect-Tag"/>
<node CREATED="1756943719634" ID="ID_664718821" MODIFIED="1757001097058" TEXT="im sichtbaren Text: normales Seitenlayout + &quot;Redirect&quot;"/>
</node>
</node>
</node>
</node>
</node>
<node CREATED="1756651585768" ID="ID_1780831155" MODIFIED="1756651592266" TEXT="Website / Infrastruktur"> <node CREATED="1756651585768" ID="ID_1780831155" MODIFIED="1756651592266" TEXT="Website / Infrastruktur">
<node CREATED="1756651593543" ID="ID_336711694" MODIFIED="1756651598874" TEXT="Anordnung der Repos"> <node CREATED="1756651593543" ID="ID_336711694" MODIFIED="1756651598874" TEXT="Anordnung der Repos">
<node CREATED="1756651599892" ID="ID_1760498141" MODIFIED="1756652477206" TEXT="Diskussion 2025 &#x27f9; l&#xe4;ngerfristig Git-Submodule"> <node CREATED="1756651599892" ID="ID_1760498141" MODIFIED="1756652477206" TEXT="Diskussion 2025 &#x27f9; l&#xe4;ngerfristig Git-Submodule">
@ -162538,10 +162749,12 @@ unsigned int ThreadIdAsInt = *static_cast&lt;unsigned int*&gt;(static_cast&lt;vo
</node> </node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1752070238449" ID="ID_1380279991" MODIFIED="1752070248400" TEXT="Clean-up allgemein"> <node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1752070238449" ID="ID_1380279991" MODIFIED="1752070248400" TEXT="Clean-up allgemein">
<icon BUILTIN="flag-yellow"/> <icon BUILTIN="flag-yellow"/>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1752070250288" ID="ID_787544102" MODIFIED="1752070280201" TEXT="Fixes von Christian aufsammeln (2018)"> <node COLOR="#338800" CREATED="1752070250288" FOLDED="true" ID="ID_787544102" MODIFIED="1756773268522" TEXT="Fixes von Christian aufsammeln (2018)">
<icon BUILTIN="flag-yellow"/> <icon BUILTIN="button_ok"/>
<node CREATED="1756657556750" ID="ID_1232269885" MODIFIED="1756657567057" TEXT="das ist ein ganzer Branch (damals auf website-staging)"/> <node COLOR="#435e98" CREATED="1756657556750" ID="ID_1232269885" MODIFIED="1756773266528" TEXT="das ist ein ganzer Branch (damals auf website-staging)">
<node CREATED="1756657567790" ID="ID_1102007831" MODIFIED="1756657859352" TEXT="Vorsicht: vieles ist gut, manches erscheint mir etwas &#xbb;forsch&#xab;"> <icon BUILTIN="info"/>
</node>
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1756657567790" ID="ID_1102007831" MODIFIED="1756773253937" TEXT="Vorsicht: vieles ist gut, manches erscheint mir etwas &#xbb;forsch&#xab;">
<icon BUILTIN="messagebox_warning"/> <icon BUILTIN="messagebox_warning"/>
<node CREATED="1756657860861" ID="ID_1937963620" MODIFIED="1756657863575" TEXT="gut"> <node CREATED="1756657860861" ID="ID_1937963620" MODIFIED="1756657863575" TEXT="gut">
<node CREATED="1756657864828" ID="ID_384847163" MODIFIED="1756657869975" TEXT="verbessertes Logging"/> <node CREATED="1756657864828" ID="ID_384847163" MODIFIED="1756657869975" TEXT="verbessertes Logging"/>
@ -162589,13 +162802,14 @@ unsigned int ThreadIdAsInt = *static_cast&lt;unsigned int*&gt;(static_cast&lt;vo
</node> </node>
</node> </node>
</node> </node>
<node CREATED="1756682077595" ID="ID_361943000" MODIFIED="1756682084516" TEXT="Review &amp; Integration"> <node COLOR="#338800" CREATED="1756682077595" ID="ID_361943000" MODIFIED="1756773245324" TEXT="Review &amp; Integration">
<icon BUILTIN="button_ok"/>
<node BACKGROUND_COLOR="#c8c0b6" COLOR="#435e98" CREATED="1756682085439" ID="ID_1381638319" MODIFIED="1756769031480" TEXT="Methode: sortieren"> <node BACKGROUND_COLOR="#c8c0b6" COLOR="#435e98" CREATED="1756682085439" ID="ID_1381638319" MODIFIED="1756769031480" TEXT="Methode: sortieren">
<icon BUILTIN="yes"/> <icon BUILTIN="yes"/>
<node COLOR="#338800" CREATED="1756682092737" ID="ID_1201468428" MODIFIED="1756748660340" TEXT="erst mal einen Cehteh-Branch konstruieren"> <node COLOR="#338800" CREATED="1756682092737" ID="ID_1201468428" MODIFIED="1756748660340" TEXT="erst mal einen Cehteh-Branch konstruieren">
<icon BUILTIN="button_ok"/> <icon BUILTIN="button_ok"/>
</node> </node>
<node COLOR="#338800" CREATED="1756682118743" ID="ID_1709090489" MODIFIED="1756748685527" TEXT="diesen dann sofort konsolidieren"> <node COLOR="#338800" CREATED="1756682118743" FOLDED="true" ID="ID_1709090489" MODIFIED="1756748685527" TEXT="diesen dann sofort konsolidieren">
<icon BUILTIN="button_ok"/> <icon BUILTIN="button_ok"/>
<node CREATED="1756686078655" ID="ID_1103164760" MODIFIED="1756686081386" TEXT="drei Teile"> <node CREATED="1756686078655" ID="ID_1103164760" MODIFIED="1756686081386" TEXT="drei Teile">
<node CREATED="1756686082398" ID="ID_73523769" MODIFIED="1756686093750" TEXT="generische Verbesserungen (build_website)"> <node CREATED="1756686082398" ID="ID_73523769" MODIFIED="1756686093750" TEXT="generische Verbesserungen (build_website)">
@ -162833,8 +163047,211 @@ unsigned int ThreadIdAsInt = *static_cast&lt;unsigned int*&gt;(static_cast&lt;vo
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1752070293350" ID="ID_391826628" MODIFIED="1752070305584" TEXT="top-Level-Seiten durchk&#xe4;mmen"> <node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1752070293350" ID="ID_391826628" MODIFIED="1752070305584" TEXT="top-Level-Seiten durchk&#xe4;mmen">
<icon BUILTIN="flag-yellow"/> <icon BUILTIN="flag-yellow"/>
</node> </node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1752070265482" ID="ID_927720852" MODIFIED="1752070278585" TEXT="releavnte Links aktualisieren"> <node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1752070265482" ID="ID_927720852" MODIFIED="1756773347225" TEXT="relevante Links aktualisieren">
<icon BUILTIN="flag-yellow"/> <icon BUILTIN="flag-yellow"/>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1756817746790" ID="ID_1287550895" MODIFIED="1756817778617" TEXT="Au13.pre &#x27fc; August13">
<icon BUILTIN="flag-yellow"/>
</node>
<node BACKGROUND_COLOR="#fafe99" COLOR="#fa002a" CREATED="1756936990537" ID="ID_1030893321" MODIFIED="1756937011089" TEXT="Problem: fehlende Seiten">
<icon BUILTIN="clanbomber"/>
<node CREATED="1756937024722" ID="ID_264003249" MODIFIED="1756937032826" TEXT="unendlich viele Einzelthemen"/>
<node CREATED="1756937033658" ID="ID_1509603645" MODIFIED="1756937047500" TEXT="im TiddlyWiki gibts daf&#xfc;r jeweils einen &#xbb;Tiddler&#xab;"/>
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1756937081422" ID="ID_1473479858" MODIFIED="1756937089530" TEXT="Thematische Anordnung ist ungekl&#xe4;rt">
<icon BUILTIN="messagebox_warning"/>
<node CREATED="1756937093722" ID="ID_1318650958" MODIFIED="1756937101284" TEXT="das d&#xfc;rfte der Kern des Problems sein"/>
<node CREATED="1756937101776" ID="ID_1321628608" MODIFIED="1756937129495" TEXT="die Dokumentation soll trennen nach Design / Technik"/>
<node CREATED="1756937162192" ID="ID_1004012837" MODIFIED="1756937188806" TEXT="im TiddlyWiki (und w&#xe4;hrend der Entwicklung) vermischt sich das"/>
</node>
<node CREATED="1756937211239" ID="ID_1737418933" MODIFIED="1756937233312" TEXT="Art der Verlinkung ist unpraktikabel">
<node CREATED="1756937234117" ID="ID_35449583" MODIFIED="1756937249911" TEXT="explizite Links sind umst&#xe4;ndlich"/>
<node CREATED="1756937250554" ID="ID_310222935" MODIFIED="1756937265816" TEXT="Links k&#xf6;nnen instabil werden (Entwicklung)"/>
<node CREATED="1756937267796" ID="ID_256582368" MODIFIED="1756937290218">
<richcontent TYPE="NODE"><html>
<head/>
<body>
<p>
Stichworte allein sind ein <i>flat namespace</i>
</p>
</body>
</html></richcontent>
</node>
<node CREATED="1756937330192" ID="ID_1148465619" MODIFIED="1756937352566" TEXT="Stichwort-System existiert noch nicht">
<node CREATED="1756937357765" ID="ID_1921358813" MODIFIED="1756937582547" TEXT="es gibt einen pfiffigen Plan (Christian)">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
Das w&#228;re eigentlich eine sch&#246;ne L&#246;sung, die uns weiterhin ein Content-Management-System erspart: wir erzeugen beim Seiten-Rendern eine Linkfarm, und die Links werden anhand von Tags aufgel&#246;st, die in den Seiten als Kommentar stehen (&#228;hnlich wie derzeit die Steuerung des Men&#252;s)
</p>
</body>
</html></richcontent>
</node>
<node CREATED="1756937375346" ID="ID_1875286957" MODIFIED="1756937843822" TEXT="die Implementierung w&#xfc;rde sich mit Menuegen &#xfc;berschneiden">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
Seinerzeit wollte Christian das <i>mal eben schnell in Lua</i>&#160; implementieren, war aber am n&#228;chsten Tag zur&#252;ckgerudert (als ihm klar wurde, da&#223; die eigentliche Aufgabe schon etwas komplexer ist). Dann wollte sich Benny darum k&#252;mmern, ist aber bei einem Glossary-Generator steckengeblieben. Und ich &#8212; ich w&#252;rde das wohl in 1-2 Wochen hinbekommen, w&#252;rde daf&#252;r aber auch Menuegen neu schreiben, weil beide Aufgaben gleicherma&#223;en eine Traversierung aller Sources erfordern. Meine Sorge dabei ist, da&#223; das ein Performance-Bottleneck wird; denn dann brauchen wir inkrementelle Verarbeitung und damit eine Datenbank &#8212; und w&#252;rden dann selber ein Content-Management-System schreiben.
</p>
</body>
</html></richcontent>
</node>
<node CREATED="1756937423192" ID="ID_224270089" MODIFIED="1756937964163" TEXT="das konkrete Tagging-Schema ist eine nicht-triviale Aufgabe">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
Und das Problem hierbei ist so <i>typisch Christian:</i>&#160;&#8222;man kann dann ja mit Tags arbeiten!&#8220; &#8212; Junge, ein System von Tags aufbauen, das f&#252;r unsere Zwecke funktionert, das ist <b>die eigentliche Aufgabe</b>.
</p>
</body>
</html></richcontent>
</node>
</node>
</node>
<node BACKGROUND_COLOR="#ccb59b" COLOR="#6e2a38" CREATED="1756938744163" ID="ID_739075540" MODIFIED="1756941730894" TEXT="irgendwann mu&#xdf; man anfangen">
<arrowlink COLOR="#af3956" DESTINATION="ID_1398390540" ENDARROW="Default" ENDINCLINATION="-550;30;" ID="Arrow_ID_1693780597" STARTARROW="None" STARTINCLINATION="-1134;-80;"/>
<font ITALIC="true" NAME="SansSerif" SIZE="14"/>
<icon BUILTIN="yes"/>
<node CREATED="1756938759279" ID="ID_202949599" MODIFIED="1756938772081" TEXT="es bringt nichts immer nur auf die L&#xf6;sung zu warten"/>
<node CREATED="1756938772847" ID="ID_472407213" MODIFIED="1756938818241" TEXT="mu&#xdf; die M&#xf6;glichkeit zum Reifen dieses Systems schaffen"/>
</node>
</node>
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1756944222448" ID="ID_150932933" MODIFIED="1756944327464" TEXT="vorl&#xe4;ufig: manuelle Linkfarm-Eintr&#xe4;ge">
<arrowlink COLOR="#fff2d9" DESTINATION="ID_1854153711" ENDARROW="Default" ENDINCLINATION="82;184;" ID="Arrow_ID_789572840" STARTARROW="None" STARTINCLINATION="-258;-18;"/>
<icon BUILTIN="bell"/>
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1756997510608" ID="ID_1340206899" LINK="#ID_1783830780" MODIFIED="1756997541478" TEXT="Design-Themen schlank halten">
<icon BUILTIN="yes"/>
</node>
<node COLOR="#338800" CREATED="1756944334324" ID="ID_1174990115" MODIFIED="1757002780761" TEXT="/x/PlayProcess">
<icon BUILTIN="button_ok"/>
<node CREATED="1756997550337" ID="ID_1850622066" MODIFIED="1756997557826" TEXT="geh&#xf6;rt dann wohl in die Engine-Sektion"/>
<node CREATED="1756997558413" ID="ID_1884692521" MODIFIED="1756997567592" TEXT="behandelt das Thema &#xbb;Processing&#xab;"/>
<node CREATED="1757002308810" ID="ID_1925498691" MODIFIED="1757002317217" TEXT="vorerst nur verweis auf das DevWiki"/>
</node>
<node COLOR="#338800" CREATED="1756944657867" ID="ID_1239322037" MODIFIED="1757035087349" TEXT="Time sollte eine Sub-Kategorie werden">
<icon BUILTIN="button_ok"/>
<node CREATED="1757029120123" ID="ID_1975176919" MODIFIED="1757029130074" TEXT="die bestehenden Seiten dorthin schieben"/>
<node CREATED="1757029130686" ID="ID_1001056146" MODIFIED="1757029134225" TEXT="Links anpassen"/>
<node COLOR="#338800" CREATED="1757029181082" ID="ID_1804753547" MODIFIED="1757029221815" TEXT="jeweils passende Forwards in das TiddlyWiki">
<linktarget COLOR="#05df2e" DESTINATION="ID_1804753547" ENDARROW="Default" ENDINCLINATION="252;15;" ID="Arrow_ID_98280388" SOURCE="ID_1513961200" STARTARROW="None" STARTINCLINATION="201;0;"/>
<icon BUILTIN="button_ok"/>
</node>
</node>
<node COLOR="#338800" CREATED="1756944634199" ID="ID_1235503392" MODIFIED="1757035089379" TEXT="/x/TimeMutation">
<icon BUILTIN="button_ok"/>
<node COLOR="#435e98" CREATED="1756944644615" ID="ID_1067332685" MODIFIED="1757029116927" TEXT="das ist eine echte Architektur-Diskussion">
<icon BUILTIN="idea"/>
</node>
<node COLOR="#338800" CREATED="1757029085884" ID="ID_52868230" MODIFIED="1757029111967" TEXT="neue Seite unter architecture/time">
<icon BUILTIN="button_ok"/>
</node>
<node COLOR="#338800" CREATED="1757029103921" ID="ID_1420860131" MODIFIED="1757029110919" TEXT="dort die Problematik beschreiben">
<icon BUILTIN="button_ok"/>
</node>
</node>
<node COLOR="#338800" CREATED="1756946990017" ID="ID_150632911" MODIFIED="1757035090412" TEXT="/x/TimecodeFormat">
<icon BUILTIN="button_ok"/>
<node CREATED="1756946999712" ID="ID_798298912" MODIFIED="1756947008693" TEXT="geh&#xf6;rt auch diese Sub-Kategorie"/>
<node COLOR="#338800" CREATED="1756947009348" ID="ID_1592399527" MODIFIED="1757035091650" TEXT="erst mal als Platzhalter-Seite">
<icon BUILTIN="button_ok"/>
</node>
<node COLOR="#338800" CREATED="1757029147292" ID="ID_1513961200" MODIFIED="1757029221814" TEXT="auch x/TimeCode">
<arrowlink COLOR="#05df2e" DESTINATION="ID_1804753547" ENDARROW="Default" ENDINCLINATION="252;15;" ID="Arrow_ID_98280388" STARTARROW="None" STARTINCLINATION="201;0;"/>
<icon BUILTIN="button_ok"/>
</node>
</node>
<node COLOR="#338800" CREATED="1756945527094" ID="ID_379568883" MODIFIED="1757035092457" TEXT="/x/Segmentation">
<icon BUILTIN="button_ok"/>
<node CREATED="1756945532139" ID="ID_1633726565" MODIFIED="1756945543262" TEXT="Erl&#xe4;uterungs-Seite"/>
<node CREATED="1756945543849" ID="ID_452364054" MODIFIED="1756945556972" TEXT="geh&#xf6;rt in Design/Model"/>
<node COLOR="#338800" CREATED="1757032157433" ID="ID_987981180" MODIFIED="1757032178353" TEXT="Ein Absatz einf&#xfc;hrende Erl&#xe4;uterung">
<icon BUILTIN="button_ok"/>
</node>
<node COLOR="#338800" CREATED="1757032170957" ID="ID_1069780982" MODIFIED="1757032177356" TEXT="dann weiter in das DevWiki verlinkt">
<icon BUILTIN="button_ok"/>
</node>
</node>
<node COLOR="#338800" CREATED="1756945570430" ID="ID_1989630376" MODIFIED="1757035093644" TEXT="/x/FrameDispatcher">
<icon BUILTIN="button_ok"/>
<node CREATED="1756945573673" ID="ID_209472146" MODIFIED="1756945577449" TEXT="technisch!"/>
<node COLOR="#338800" CREATED="1756945578130" ID="ID_671431606" MODIFIED="1757032186781" TEXT="vorl&#xe4;ufig auf das TiddlyWiki">
<icon BUILTIN="button_ok"/>
</node>
</node>
<node COLOR="#338800" CREATED="1756947054848" ID="ID_1133248397" MODIFIED="1757035094836" TEXT="/x/Advice">
<icon BUILTIN="button_ok"/>
<node BACKGROUND_COLOR="#d2beaf" COLOR="#5c4d6e" CREATED="1756947060232" ID="ID_345678908" MODIFIED="1757032034202" TEXT="sollte auf eine Design-Seite verweisen">
<icon BUILTIN="hourglass"/>
</node>
<node BACKGROUND_COLOR="#d2beaf" COLOR="#5c4d6e" CREATED="1756947081429" ID="ID_1352644631" MODIFIED="1757031875263" TEXT="geeignete Kategorie finden">
<icon BUILTIN="yes"/>
<icon BUILTIN="hourglass"/>
<node CREATED="1757031877034" ID="ID_1565516888" MODIFIED="1757031890753" TEXT="f&#xe4;llt in die Kategorie &quot;Application&quot;"/>
<node CREATED="1757031891420" ID="ID_106217965" MODIFIED="1757031988414" TEXT="(denn ich m&#xf6;chte keine separate Kategorie &quot;Framework&quot;)">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
Lumiera ist keine Plattform und kein Framework &#8212; wir haben lediglich Framework-artige Infrastruktur wie in jeder gr&#246;&#223;eren Applikation
</p>
</body>
</html></richcontent>
<font NAME="SansSerif" SIZE="10"/>
</node>
</node>
<node COLOR="#435e98" CREATED="1757032004822" ID="ID_715158297" MODIFIED="1757032029818" TEXT="vorerst: lediglich in das DevWiki weiterleiten">
<icon BUILTIN="idea"/>
</node>
</node>
<node COLOR="#338800" CREATED="1757027697483" ID="ID_884614038" MODIFIED="1757035097111" TEXT="x/ticket">
<icon BUILTIN="button_ok"/>
<node CREATED="1757028583148" ID="ID_265578975" MODIFIED="1757028598353" TEXT="delegiert an Trampolin-Seiten"/>
<node CREATED="1757028599749" ID="ID_103722705" MODIFIED="1757029055815" TEXT="x/fwd/Ticket.#.html">
<icon BUILTIN="info"/>
</node>
<node COLOR="#338800" CREATED="1757029037410" ID="ID_1399412065" MODIFIED="1757029047641" TEXT="1261">
<icon BUILTIN="button_ok"/>
</node>
</node>
</node>
</node>
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1756773353095" ID="ID_397054568" MODIFIED="1756773366565" TEXT="weitere Fixes">
<icon BUILTIN="bell"/>
<node BACKGROUND_COLOR="#fafe99" COLOR="#fa002a" CREATED="1756773369043" ID="ID_252956083" MODIFIED="1756773406409" TEXT="Verlinkung Git-Flow (Codebase)">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
hier stimmt was nicht mit dem Link auf das allgemeine Essay
</p>
</body>
</html></richcontent>
<icon BUILTIN="broken-line"/>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1756834117054" ID="ID_718437760" MODIFIED="1756834125609" TEXT="Lizenz-Seiten erneuern">
<icon BUILTIN="flag-yellow"/>
</node>
<node BACKGROUND_COLOR="#ccb59b" COLOR="#6e2a38" CREATED="1756830253426" ID="ID_989483889" MODIFIED="1756830598512" TEXT="Dontations-Page ist obsolet">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
Okt.2009 hatten wir eine Kooperation mit der ffis.de vereinbart; in den n&#228;chsten Jahren gab es ein paar Klein-Spenden, die wir aber nicht von der ffis abgerufen haben, da wir damals keinen Bedarf hatten (Idee war z.B. immer gewesen, einem Entwickler die Reise zum Treffen zu zahlen &#8212; aber die Beteiligten konnten die Reise zur FrOSCon immer problemlos selber zahlen). <i>Das ist zwar sch&#246;n f&#252;r uns ....</i>&#160;aber eine <b>derart veraltete Spenden-Seite wirft ein schlechtes Licht auf uns!</b>
</p>
</body>
</html></richcontent>
<arrowlink COLOR="#882246" DESTINATION="ID_679146016" ENDARROW="Default" ENDINCLINATION="311;0;" ID="Arrow_ID_909744060" STARTARROW="None" STARTINCLINATION="756;65;"/>
<font ITALIC="true" NAME="SansSerif" SIZE="14"/>
<icon BUILTIN="yes"/>
</node>
<node CREATED="1756773417519" ID="ID_1432896045" MODIFIED="1756773420272" TEXT="Men&#xfc;">
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1756773421004" ID="ID_1536518392" MODIFIED="1756773452193" TEXT="Reihenfolge Technical">
<icon BUILTIN="flag-yellow"/>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1756773443885" ID="ID_103458183" MODIFIED="1756773452194" TEXT="Reihenfolge Infrastructure">
<icon BUILTIN="flag-yellow"/>
</node>
</node>
</node> </node>
</node> </node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1751808931491" ID="ID_1572764059" MODIFIED="1752070235664" TEXT="Build/Dependencies"> <node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1751808931491" ID="ID_1572764059" MODIFIED="1752070235664" TEXT="Build/Dependencies">
@ -174582,6 +174999,21 @@ Since then others have made contributions, see the log for the history.</font></
</node> </node>
</node> </node>
</node> </node>
<node CREATED="1756830145491" ID="ID_1909194712" MODIFIED="1756830156650" TEXT="Website">
<icon BUILTIN="pencil"/>
<node BACKGROUND_COLOR="#fafe99" COLOR="#fa002a" CREATED="1756830158871" ID="ID_207712886" MODIFIED="1756830168645" TEXT="TODO">
<icon BUILTIN="bell"/>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1756830177726" ID="ID_534650716" MODIFIED="1756830193831" TEXT="kl&#xe4;ren: Donations-Page">
<icon BUILTIN="bell"/>
<node CREATED="1756830202685" ID="ID_1184692288" MODIFIED="1756830217995" TEXT="bei der ffis sind wir schon lange nicht mehr als &quot;aktiv&quot; gef&#xfc;hrt"/>
<node CREATED="1756830218755" ID="ID_218868534" MODIFIED="1756830228917" TEXT="derzeit brauchen wir keine Donations"/>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1756830229931" ID="ID_679146016" MODIFIED="1756830559859" TEXT="2025-8 : Seite entfert">
<linktarget COLOR="#882246" DESTINATION="ID_679146016" ENDARROW="Default" ENDINCLINATION="311;0;" ID="Arrow_ID_909744060" SOURCE="ID_989483889" STARTARROW="None" STARTINCLINATION="756;65;"/>
<icon BUILTIN="flag-yellow"/>
</node>
</node>
</node>
</node>
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#990000" CREATED="1446356368070" HGAP="-38" ID="ID_768449868" MODIFIED="1582333957320" TEXT="Au Au" VSHIFT="196"> <node BACKGROUND_COLOR="#fdfdcf" COLOR="#990000" CREATED="1446356368070" HGAP="-38" ID="ID_768449868" MODIFIED="1582333957320" TEXT="Au Au" VSHIFT="196">
<edge COLOR="#c14b4b" STYLE="sharp_bezier"/> <edge COLOR="#c14b4b" STYLE="sharp_bezier"/>
<icon BUILTIN="broken-line"/> <icon BUILTIN="broken-line"/>