lumiera_documentation/src
Ichthyostega 0d2d8c3413 Scheduler: providing the execution-context
The Activity-Language can be defined by abstracting away
some crucial implementation functionality as part of an generic
»ExecutionCtx«, which in the end will be provided by the Scheduler.

But how actually?
We want to avoid unnecessary indirections, and ideally we also want
a concise formulation in-code. Here I'm exploring the idea to let the
scheduler itself provide the ExecutionCtx-operations as member functions,
employing some kind of "compile-time duck-typing"

This seems to work, but breaks the poor-man's preliminary "Concept" check...
2023-10-21 03:01:27 +02:00
..
common Library/Application: consolidate Monitor API and usage 2023-10-15 20:42:55 +02:00
include Clip-Drag: consider translation of command ctxID into a InteractionState implementation 2021-03-28 18:03:40 +02:00
lib Library/Application: complete technology switch (closes #1279) 2023-10-16 01:44:04 +02:00
lumiera Global-Layer-Renaming: adjust namespace qualification 2018-11-15 23:59:23 +01:00
plugin
stage LibraryApplication: tie DispatcherLoop to thread lifecycle 2023-10-12 20:23:59 +02:00
steam Library/Application: consolidate Monitor API and usage 2023-10-15 20:42:55 +02:00
tool Doxygen: fill in missing file level headlines for some supplemental code 2016-11-09 20:09:19 +01:00
vault Scheduler: providing the execution-context 2023-10-21 03:01:27 +02:00
.gitignore
DIR_INFO update some DIR_INFO entries 2011-04-05 00:44:30 +02:00
doxygen.dox Scheduler: devise the arrangement of basic components 2023-06-24 03:14:17 +02:00
SConscript Global-Layer-Renaming: fix handling of GuiResources in the build 2018-11-16 18:18:33 +01:00