Indeed — this change set is kind of sad.
Because I still admire the design of the GAVL library,
and would love to use it for processing of raw video.
However, up to now, we never got to the point of actually
doing so. For the future, I am not sure if there remains
room to rely on lib-GAVL, since FFmpeg roughly covers
a similar ground (and a lot beyond that). And providing
a plug-in for FFmpeg is unavoidable, practically speaking.
So I still retain the nominal dependency on lib-GAVL
in the Build system (since it is still packaged in Debian).
But it is pointless to rely on this library just for an
external type-def `gavl_time_t`. We owe much to this
inspiration, but it can be expected that we'll wrap
these raw time-values into a dedicated marker type
soon, and we certainly won't be exposing any C-style
interface for time calculations in future, since
we do not want anyone to side-step the Lumiera
time handling framework in favour of working
„just with plain numbers“
NOTE: lib-GAVL hompage has moved to Github:
https://github.com/bplaum/gavl
With the ability to invoke a Render Node graph,
the development on branch `play` reached some kind of milestone
regarding the »Playback Vertical Slice«.
This is a good opportunity to update the reference platform
and upgrade the preview releases and packaging setup accordingly.
This will include adjustments to compile on recent compilers and
upgrade the build system to support Python-3.
At various places, concepts and drafts from the early stage of the
Lumiera Project are still reflected in the online documentation pages.
During the last months, development focussed on the Render Engine,
causing a shift in some parts of the design, and obsoleting other
parts altogether (notably we consider to use IO_URING for async IO)
After sleeping some nights over it, rework the wording to make
my reasoning more clear and remove any possibly insulting undertone.
I have seen what I describe here, happening over and over again --
and several times I myself was the one cooking up "simplifications",
which caused lots of pain further down the road.
During the last years, I became more and more doubtful and regretted
that decision. In hindsight, the fundamental conflict was present
already in the original discussion.
My own experience showed me again and again: skipping the hard work
of specification for sake of some kind of fluid prototyping rarely
leads to anything solid. If "time to market" counts, this can be
a viable strategy though...
- most notably the NOBUG logging flags have been renamed now
- but for the configuration, I'll stick to "GUI" for now,
since "Stage" would be bewildering for an occasional user
- in a similar vein, most documentation continues to refer to the GUI
Considering this since some time, since it more and more occurred to me
the existing conventional names are a misfit. And they are dull and clumsy.
This fall, I mentioned it to Benny, and he seemed to be rather favourable towards that idea,
which encourages me just to go ahead. Unfortunately, I am alone on the coding frontier
right now, which has several downsides, but at least it gives me the ability
to pull off radical moves.
Introduce the new term "Fork" at various relevant places
within the documentation. We do not entirely purge the
term "track" though; rather we
- make clear that "Fork" is the entity to build tracks
- use "fork" also synonymous to the "tree of tracks"
This switches the Lumiera UI from GTK-2 to GTK-3
Unfortunately, this move breaks two crucial features, which have been
disabled for now: the display of video and our custom timeline widget.
Since both of these require some reworking, which in fact has already
started, we prefer to do the library and framework switch right away.
There is a long-standing RfC which basically describes the
same idea on a much wider, conceptual scope. Indeed I consider
this approach used here for solving the problem with GUI uptades
also as a proof of concept, to be expanded to a much wider scope
in case it works out well.
The new insight here is, that, by transferring a diff in pull mode,
we can circumvent the architectural problems with typing, which
showed up quite clearly in earlier design studies towards this
concept. The change from push to pull is by far not so fundamental
as it looks, since the sender still may initiate the exchange
by sending a message offering the diff iterator for the receiver
to pull. This way, we get a handshake and still sustain the
crucial part, which is to decouple the data representation
and give the receiver full control over the interpretation
of the exchanged data.
Uniform sequence at start of source files
- copyright claim
- license
- file comment
- header guard
- lumiera includes
- library / system includes
Lumiera uses Brittish spelling. Add an according note to the styleguide.
initial draft of an RfC to discuss and define the
requirements for other parts of the application to relie on
note: this commit fixes a merge error; the RfC was lost
while combining documentation and code branches
* rfcs are now all stored in the rfc folder (formerly hold the final rfcs)
* a new rfc_final folder is created
* the state folders (rfc_final|pending|parked|dropped) now contain
symlinks back to the rfc pool
