clean-up: link maintenance
- use HTTPS - avoid redirects - supply Archive.org snapshots for old resources
This commit is contained in:
parent
643779c4a2
commit
25eb6a61e3
59 changed files with 170 additions and 163 deletions
|
|
@ -10,6 +10,6 @@ The Lumiera application uses two quite different sources for configuration
|
|||
to be resolve employing a rules based system '(planned)'. Configuration rules will be provided by the
|
||||
application (defaults), a session template and rules stored in the actual session.
|
||||
|
||||
-> see also the link:{ldoc}/technical/vault/ConfigLoader.html[Config Loader brainstorming from 2008] (implementation details)
|
||||
-> see also the link:rfc/ConfigLoaderDraft2008.html[Config Loader brainstorming from 2008] (implementation details)
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -55,8 +55,7 @@ Requirement analysis of playback modes
|
|||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
For the task of editing a piece of media, the following modes of playback presentation can be determined +
|
||||
See also the more
|
||||
link:wiki/renderengine.html#NonLinearPlayback%20PlayService%20PlayProcess%20CalcStream%20FrameDispatcher%20OutputManagement[
|
||||
technical discussion of playback in the TiddlyWiki]
|
||||
link:imp/NonLinearPlayback.html[technical discussion of non-linear playback]
|
||||
|
||||
|
||||
regular playback::
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ GUI Proposal by Clay Barnes
|
|||
:Author: R. Clayton Barnes (»rcbarnes«)
|
||||
:Date: 2008-05-21
|
||||
|
||||
-> https://www.hci-matters.com/blog/2008/05/21/archives/41/[original blog entry]
|
||||
-> https://web.archive.org/web/20120128160238/https://www.hci-matters.com/blog/2008/05/21/archives/41/[original blog entry]
|
||||
|
||||
.About the Author
|
||||
***********************************************************************************************************
|
||||
|
|
|
|||
|
|
@ -112,7 +112,8 @@ Can open Windows on different heads of the same server, and is aware of the exis
|
|||
--
|
||||
* Multi-Head != Xinerama ... This is very important and quite common, We want to support monitors driven at the native Video Format (resolution, framerate, interlacing, overscan, ....). For a professional setup this is really required!
|
||||
-- link:ct[] [[DateTime(2008-07-22T07:11:11Z)]] +
|
||||
Xinerama and twinView test comparison http://www.phoronix.com/scan.php?page=article&item=387&num=1[]
|
||||
|
||||
* Xinerama and twinView test comparison -> https://www.phoronix.com/review/387[see @Phoronix...]
|
||||
--
|
||||
|
||||
* Automatic Clip Creation based on video content. +
|
||||
|
|
@ -182,7 +183,7 @@ Widgets
|
|||
|
||||
* Generalized Fader
|
||||
+
|
||||
image:images/fader.png[fader.png]
|
||||
image:/images/fader.png[fader.png]
|
||||
+
|
||||
All faders are the same kind of custom widget, that is:
|
||||
|
||||
|
|
@ -222,7 +223,7 @@ Partially, this is covered by the Adaptive Mouse Wheel too; but, especially when
|
|||
- Comment: This is definitely a problem we need a solution to. Is modifier keys the most discoverable way of doing it - I'm not sure. We need ideas for this (see below).
|
||||
-- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]]
|
||||
|
||||
- This concept of "magnifying faders", is well explained in http://thorwil.wordpress.com/2007/05/01/fan-sliders/[Thorsten Wilms Fan-sliders Article], the Article also links to an implementation.
|
||||
- This concept of "magnifying faders", is well explained in https://thorwil.wordpress.com/2007/05/01/fan-sliders/[Thorsten Wilms Fan-sliders Article], the Article also links to an implementation.
|
||||
-- link:oracle2025[] [[DateTime(2008-02-08T00:40:05Z)]]
|
||||
|
||||
- Comment: In one sense this is bad because it's so incredibly non-standard. Bun in other ways it seems to me like a rather ingenious solution to the problem. Aparently Ardour has these. I must investigate.
|
||||
|
|
|
|||
|
|
@ -10,7 +10,8 @@ Sometimes help files and tutorials are improvable. Keeping track of which help i
|
|||
-- link:JoelHoldsworth[] [[DateTime(2008-07-23T20:47:35Z)]]
|
||||
|
||||
* Suggest an improvement Feature - for users to help improvement +
|
||||
Just like the "Help" feature suggested elsewhere, in which the user can edit the help file as they go, so could the user be able to make suggestions to improve the program. Able to get a panel or window grab, and draw arrows lines to show "where" they are talking about. Online linking - There could also be the facility to click on an email link to send a request for help (want to engage in dialog, rather than just notify - without need for response). Or a relevant search is automatically generated for the forum, chat room, faqs, helpdesk, documentation. Or get sent to a link:BrainStorming[] page like this one (specifically for the panel they were in).
|
||||
Just like the "Help" feature suggested elsewhere, in which the user can edit the help file as they go, so could the user be able to make suggestions to improve the program. Able to get a panel or window grab, and draw arrows lines to show "where" they are talking about. Online linking - There could also be the facility to click on an email link to send a request for help (want to engage in dialog, rather than just notify - without need for response). Or a relevant search is automatically generated for the forum, chat room, faqs, helpdesk, documentation.
|
||||
Or get sent to a ``BrainStorming'' page like this one (but marked specifically for the panel they were in).
|
||||
-- link:Tree[][[DateTime(2008-05-26T12:01:00NZ)]]
|
||||
|
||||
- This isn't really a GUI issue - much of this is more for the website, which the GUI will probably link to from an item in the help menu.
|
||||
|
|
|
|||
|
|
@ -6,10 +6,12 @@ Timeline: Discussion
|
|||
This is Joel Holdsworth's attempt to amalgamate all the ideas from all the brainstorming to one consistent idea that makes sense, can be implemented, and seems like it would be nice to use. Comments are welcome.
|
||||
|
||||
* Avid vs FCP 2006 - http://www.fini.tv/articles/avidfcp2006.html[]
|
||||
Archived 2008 from https://web.archive.org/web/20071211184722/http://www.fini.tv/articles/avidfcp2006.html[fini.tv]
|
||||
|
||||
* Final Cut Pro 5 - A First Look - http://www.kenstone.net/fcp_homepage/fcp_5_new_martin.html[]
|
||||
|
||||
* SpeedEdit Tutorials - http://www.newtek.com/speededit/tutorials/index.php[]
|
||||
* SpeedEdit Tutorials +
|
||||
'http://www.newtek.com/speededit/tutorials/index.php' ~[red]#dead link#~
|
||||
|
||||
|
||||
Brainstorming
|
||||
|
|
|
|||
|
|
@ -83,7 +83,7 @@ reach a menu entry. (same for looking around to check information on the status
|
|||
of the window which has focus anyways). And last but not least, the current GDL docks implement thir own drag handles,
|
||||
moving windows around has a big performance problem with some window managers, moving windows shall be the job of the
|
||||
window manager and not the job of the application, the only thing the application may do is hinting positions to the
|
||||
WM. These second class dock windows are neither ICCCM conforming (http://tronche.com/gui/x/icccm/[]) nor do they add any
|
||||
WM. These second class dock windows are neither https://tronche.com/gui/x/icccm/[ICCCM] conforming nor do they add any
|
||||
extra user experience, instead the user has to learn a new kind of window class. +
|
||||
-- link:ct[] [[DateTime(2009-01-29T03:15:03Z)]]
|
||||
|
||||
|
|
|
|||
|
|
@ -71,4 +71,4 @@ Comment
|
|||
~~~~~~~
|
||||
re "ichthyo asks for help setting up a test/build server" for "Debian"
|
||||
|
||||
see "Build Server" at http://www.pipapo.org/pipawiki/Lumiera/GuiBrainstorming?action=edit&editor=gui[]
|
||||
see "Build Server" at [purple]#<broken-URL>#
|
||||
|
|
|
|||
|
|
@ -23,12 +23,12 @@ __Participants__
|
|||
The Lumiera Logo
|
||||
----------------
|
||||
|
||||
The logo contest is a great success: http://www.pipapo.org/pipawiki/Lumiera/Logos[105 entries]. Everyone agrees that a preselection has to be made. Every attendee will have a look at the entries and selects 5 for the preselection list. Finally, 21 logos are selected. Together with a nice collage they are http://www.pipapo.org/pipawiki/Lumiera/Logos/Selection[presented] so that anyone online can vote for his/her favorite one. Voting will be possible from 20 december until 31 december at midnight.
|
||||
The logo contest is a great success: *105 entries*. Everyone agrees that a preselection has to be made. Every attendee will have a look at the entries and selects 5 for the preselection list. Finally, 21 logos are selected. Together with a nice collage they are presented ([purple]#`http://www.pipapo.org/pipawiki/Lumiera/Logos/Selection`#) so that anyone online can vote for his/her favorite one. Voting will be possible from 20 december until 31 december at midnight.
|
||||
|
||||
|
||||
Recurring Topics
|
||||
----------------
|
||||
Discussion of open http://www.pipapo.org/pipawiki/Lumiera/DesignProcess[design process] drafts.
|
||||
Discussion of open link:/x/DesignProcess.html[design process] drafts.
|
||||
|
||||
|
||||
EDL vs Sequence
|
||||
|
|
|
|||
|
|
@ -100,7 +100,7 @@ are fine though.
|
|||
VoIP discussions over Mumble?
|
||||
-----------------------------
|
||||
|
||||
There seems to be link:http://kitenet.net/~joey/blog/entry/12_hours_of_talking/[ongoing discussions]. on using VoIP more in Debian GNU/Linux.
|
||||
There seems to be https://joeyh.name/blog/entry/12_hours_of_talking/[ongoing discussions]. on using VoIP more in Debian GNU/Linux.
|
||||
|
||||
It was decided that while the idea is nice, it will not be used for developer
|
||||
meetings. We might use it for developer discussions outside meetings if we feel
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ _Francesco Siddi_ has augmented his Layout proposal and already built up two pag
|
|||
cover most of the layout needs of the Lumiera website and documentation resources. However,
|
||||
some points with the code generated by Asciidoc turned out to be problematic.
|
||||
|
||||
In a link:http://permalink.gmane.org/gmane.comp.video.lumiera.general/2330[message preceeding the meeting],
|
||||
In a https://lists.lumiera.org/pipermail/lumiera/2011-April/002418.html[message preceeding the meeting],
|
||||
today _ichthyo_ highlighted some general concerns which might need further discussion and maybe
|
||||
a decision.
|
||||
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ RFCs
|
|||
----
|
||||
|
||||
It was not clear what state
|
||||
link:{ldoc}/devel/rfc.html[RFCs] have in our
|
||||
link:/x/DesignProcess.html[RFCs] have in our
|
||||
documentation structure. The question was if they should, after
|
||||
becoming finalized integrated into some other document or stay first
|
||||
class and be referenced from other documents.
|
||||
|
|
@ -101,7 +101,8 @@ A complete rewrite of Builddrone (a continuous integration system) is
|
|||
now (almost) finished and will be deployed on our build server within
|
||||
the next days. It has numerous improvements over the old one. More
|
||||
information and documentation will appear at
|
||||
https://builddrone.pipapo.org/ soon. Stay tuned.
|
||||
https://web.archive.org/web/20221205192908/https://builddrone.pipapo.org/[builddrone.pipapo.org]
|
||||
soon. Stay tuned.
|
||||
|
||||
Thanks to Lenny for helping with the documentation and Simon for the
|
||||
Logo.
|
||||
|
|
|
|||
|
|
@ -60,7 +60,7 @@ Scheduler: Interface and requirements
|
|||
-------------------------------------
|
||||
_Benny_ showed interest to work on that topic. The first step would be to build or use
|
||||
a priority queue textbook implementation as starting point. Some time ago, _cehteh_ included
|
||||
a suitable implementation in his link:http://git.pipapo.org/?p=cehsrc;a=summary[cehlib],a
|
||||
a suitable implementation in his https://git.pipapo.org/cehteh/cehsrc[cehlib],a
|
||||
collection of basic C library routines, mostly extracted from Lumiera's library. _ichthyo_
|
||||
integrates this priority queue into the Lumiera tree.
|
||||
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@ https://web.archive.org/web/20090129083001/https://www.linux.com/feature/126441[
|
|||
and remove a ^[citation needed]^ tag.
|
||||
|
||||
-> see the reworked
|
||||
{l}/project/index.html[``About''] and {l}/project/faq.html[``FAQ''] pages +
|
||||
link:/project/index.html[``About''] and link:/project/faq.html[``FAQ''] pages +
|
||||
-> section in the
|
||||
https://en.wikipedia.org/wiki/Cinelerra#Lumiera[Wikipedia page for Cinelerra].
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@
|
|||
:Date: 2024-01-20
|
||||
|
||||
Jan 10, 2024
|
||||
on {l}/project/contact.html#_irc[`#lumiera`]
|
||||
on link:/project/contact.html#_irc[`#lumiera`]
|
||||
20:00 - 23:00 UTC +
|
||||
|
||||
__Participants__
|
||||
|
|
|
|||
|
|
@ -327,7 +327,7 @@ Topics
|
|||
* organisational (protocol, agenda, leftovers?)
|
||||
* Logo Contest progress, discussion about how to do the pre selection
|
||||
* rename "EDL" into "Sequence"
|
||||
* link:DesignProcess/TimelineSequenceOutput[Project, Timeline(s), Sequence(s) and Output]
|
||||
* link:/documentation/devel/rfc/TimelineSequenceOutput.html[Project, Timeline(s), Sequence(s) and Output]
|
||||
* GUI/Proc Interface and collaboration
|
||||
* Threading questions regarding gtk-main and main()
|
||||
|
||||
|
|
@ -522,7 +522,7 @@ Summary
|
|||
Topics
|
||||
~~~~~~
|
||||
* Who will write the protocol below
|
||||
* Discuss the open points in link:Lumiera/DesignProcess[] do we need this formalism?
|
||||
* Discuss the open points in a link:/x/DesignProcess[»Design Process«] -- do we need this formalism?
|
||||
* Who works on what, what are the short term goals, what tasks are open
|
||||
* State of the new-name search for the was-intended-as-cinelerra-3 project (no name discussion, just how we will progress!)
|
||||
* Introduce the development model
|
||||
|
|
|
|||
|
|
@ -6,29 +6,23 @@ Statistics and Reports
|
|||
|
||||
++++++++++++++++++++++++++++++++++++++
|
||||
<div style="float:left">
|
||||
<script type='text/javascript' src='https://www.openhub.net/p/lumiera/widgets/project_basic_stats?format=js'></script>
|
||||
<script type='text/javascript' src='https://openhub.net/p/lumiera/widgets/project_basic_stats?format=js'></script>
|
||||
</div>
|
||||
++++++++++++++++++++++++++++++++++++++
|
||||
|
||||
++++++++++++++++++++++++++++++++++++++
|
||||
<div style="float:right; margin-left: 2em;">
|
||||
<script type='text/javascript' src='https://www.openhub.net/p/lumiera/widgets/project_cocomo?format=js'></script>
|
||||
<script type='text/javascript' src='https://openhub.net/p/lumiera/widgets/project_cocomo?format=js'></script>
|
||||
</div>
|
||||
<p style="clear:both" />
|
||||
++++++++++++++++++++++++++++++++++++++
|
||||
|
||||
''''
|
||||
^Statistics generated automatically by *OpenHub* based on Git master footnote:[»link:https://blog.openhub.net/about/[OpenHub]«,
|
||||
^Statistics generated automatically by *OpenHub* based on Git master footnote:[»link:https://openhub.net[OpenHub]«,
|
||||
formerly known as »Ohloh« is a public directory and networking site for free and open source software (FOSS),
|
||||
offering analytics and search services for evaluating and comparing open source projects.]^
|
||||
|
||||
|
||||
Mailing List
|
||||
------------
|
||||
|
||||
image:http://gmane.org/plot-rate.php?group=gmane.comp.video.lumiera.general[Lumiera Mailinglist activity] +
|
||||
^activity stats by link:http://dir.gmane.org/gmane.comp.video.lumiera.general[Gmane.org]^
|
||||
|
||||
|
||||
Tickets
|
||||
-------
|
||||
|
|
|
|||
|
|
@ -39,7 +39,7 @@ Implementation Proposal
|
|||
* first member is a _size_ which will be initialized by the actual
|
||||
implementation
|
||||
* followed by function pointers defining the interface, see:
|
||||
link:Lumiera/DesignProcess/CCodingStyleGuide[]
|
||||
link:{ldoc}/devel/rfc/CCodingStyleGuide.html[C-coding style guide]
|
||||
|
||||
* everything added is considered immutable for this interface version
|
||||
* new functions are added to the end (thus changing size)
|
||||
|
|
|
|||
|
|
@ -40,11 +40,8 @@ Description
|
|||
Comments
|
||||
--------
|
||||
|
||||
* Alcarinque made link:/documentation/design/gui/GuiDiscussion/Proposal.Alcarinque.html[some
|
||||
design drafts] for the UI. Here is the
|
||||
link:/documentation/design/gui/GuiDiscussion/Proposal.Alcarinque.svg[SVG source] (converted
|
||||
from OODraw by Ichthyo 2011). This is not a technical draft at all, it is just
|
||||
an idea.
|
||||
* Alcarinque made link:/x/Proposal.Alcarinque.html[some design drafts] for the UI. +
|
||||
This is not a technical draft at all, it is just an idea.
|
||||
|
||||
* Wouldn't the Config Rules (embedded Prolog) also interact with the High
|
||||
Level Model? Or would that be expanding its scope too much? I imagine
|
||||
|
|
|
|||
|
|
@ -23,7 +23,8 @@ Description
|
|||
In the following I'll explain a C coding style I used frequently for other
|
||||
projects. Take this as suggestion for parts written in C (it definitely makes
|
||||
no sense for C++). We probably don't need to enforce this style for normal C
|
||||
code, but for the related link:Lumiera/DesignProcess/AllPluginInterfacesAreC[]
|
||||
code, but for the related
|
||||
link:/rfc/AllPluginInterfacesAreC.html[Rfc: »All Plugin Interfaces Are C«]
|
||||
it really makes sense to have some well defined style.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ Description
|
|||
We need to agree on some coding style, IMHO consistency is the most important
|
||||
part with this, no matter which style we use.
|
||||
|
||||
See http://en.wikipedia.org/wiki/Indent_style[]
|
||||
See https://en.wikipedia.org/wiki/Indentation_style[Wikipedia: Indentation Style]
|
||||
|
||||
.Notes:
|
||||
* no tabs, use spaces!
|
||||
|
|
|
|||
|
|
@ -314,7 +314,7 @@ semantics notes:
|
|||
anchor:anchor_links[]links
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html[]
|
||||
https://specifications.freedesktop.org/basedir-spec/0.6/[]
|
||||
|
||||
|
||||
anchor:anchor_internals[]internals/implementation sketch
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ http://lists.lumiera.org/pipermail/lumiera/2008-September/000053.html[] -- the
|
|||
main discussion thread
|
||||
|
||||
Additionally, a lot of great concepts for how to streamline the interface are
|
||||
derived in part from link:KPhotoAlbum[].
|
||||
derived in part from https://www.kphotoalbum.org/[KPhotoAlbum].
|
||||
|
||||
I use tags, keywords, and metadata almost interchangeably, with the exception
|
||||
that metadata includes computer generated metadata as well. These are not tags
|
||||
|
|
@ -376,7 +376,8 @@ Possible Collaboration with the people from Ardour?
|
|||
I guess if the thing can do all the things we talked about here, it would be
|
||||
perfectly suitable for sound classification too, and maybe could fill another
|
||||
gap in FOSS: Audio Archival Software, like this:
|
||||
http://www.soundminer.com/SM_Site/Home.html[] (which is very expensive)...
|
||||
https://web.archive.org/web/20100618104752/http://www.soundminer.com/SM_Site/Why_Buy.html[soundminer.com]
|
||||
(which is very expensive)...
|
||||
maybe the Ardour people would be interested in a collaboration on this?
|
||||
|
||||
I like the suggestion of sound classification with a similar (or, even better,
|
||||
|
|
|
|||
|
|
@ -52,7 +52,7 @@ So...
|
|||
|
||||
A closely related issue is the handling of *Automation*. The current draft
|
||||
calls for an abstract interface "ParamProvider", which just allows the
|
||||
link:Plugin/RenderComponent[] to pull a current value, without knowing if the
|
||||
Plugin or RenderComponent to pull a current value, without knowing if the
|
||||
ParamProvider is a GUI widget or an automation data set with interpolation. The
|
||||
component using the param value should not need to do any interpolation. We
|
||||
should re-asses and refine this draft as needed. Note: Render Nodes are
|
||||
|
|
|
|||
|
|
@ -100,11 +100,11 @@ Rationale
|
|||
~~~~~~~~~
|
||||
The purpose of this Design Entry is to give a summary; the questions and the
|
||||
details of carrying out the operations are much more involved.
|
||||
+
|
||||
|
||||
Please see the
|
||||
http://www.lumiera.org/wiki/renderengine.html#Rendering[Development internal doc (TiddlyWiki)]
|
||||
link/wiki/renderengine.html#Rendering[Development internal doc (TiddlyWiki)]
|
||||
and the
|
||||
http://www.lumiera.org/gitweb?p=lumiera/ichthyo;a=blob;f=src/proc/engine/procnod.hpp;h=9cf3a2ea8c33091d0ee992ec0fc8f37bb5874d34;hb=refs/heads/proc[Source Code]
|
||||
https://git.lumiera.org/?p=LUMIERA;a=blob;f=src/proc/engine/procnode.hpp;h=9cf3a2ea8c33091d0ee992ec0fc8f37bb5874d34;hb=f9452f654cf39a4abbbeecfd81bef51aa347b321[Draft: ProcNode (src)]
|
||||
for details
|
||||
(and/or contact Ichthyo for in-depth discussion of those technical details)
|
||||
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@ planning:
|
|||
|
||||
Tasks
|
||||
~~~~~
|
||||
* We need to refine link:Lumiera/DesignProcessTemplate[].
|
||||
* We need to refine the `Lumiera/DesignProcessTemplate`.
|
||||
|
||||
Pros
|
||||
~~~~
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ Background
|
|||
~~~~~~~~~~
|
||||
|
||||
Cinelerra is quite an old project, there is an original version from
|
||||
heroinewarrior.com and a community fork link:https://cinelerra-cv.wikidot.com/[Cinelerra-CV].
|
||||
Heroinewarrior.com and a community fork http://cinelerra-cv.wikidot.com/[Cinelerra-CV].
|
||||
The original author claims that there was no-one producing useable input despite their
|
||||
requests while cinelerra was in development, and indeed the Cinelerra-CV community only
|
||||
feeds back the source released by the original author into their SVN repository
|
||||
|
|
@ -49,8 +49,8 @@ But there are some bad things too. Notably there is not much progress on the
|
|||
community development. Users don't benefit from new improvements which other
|
||||
people have made. There is a endlessly growing list of bugs and feature
|
||||
requests, when someone sends a patch to the ML he has to invest quite some time
|
||||
to maintain it until it might be merged. Finally we don't know what heroine
|
||||
virtual is working on, until we see his next tarball.
|
||||
to maintain it until it might be merged. Finally we don't know what ``Heroine
|
||||
Virtual'' is working on, until we see his next tarball.
|
||||
|
||||
|
||||
Solution for Lumiera
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ This proposal stems from an discussion on the Mailinglist starting with the
|
|||
quote from Walter Murch "Marble and Clay".
|
||||
+
|
||||
It is thought to be in support and to complement nasa's
|
||||
link:DelectusShotEvaluator.html[Delectus Shot Evaluator]
|
||||
link:/rfc/DelectusShotEvaluator.html[RfC: Delectus Shot Evaluator]
|
||||
|
||||
The central Idea is to remove the difference between "viewing", i.e. the media
|
||||
viewer and the timeline/Sequence on the other hand. Lumiera is designed to
|
||||
|
|
|
|||
|
|
@ -262,7 +262,7 @@ Nuff said.
|
|||
Comments
|
||||
^^^^^^^^
|
||||
|
||||
Quote from Ohloh.net: (http://www.ohloh.net/projects/lumiera)[]
|
||||
Quote from https://openhub.net/p/lumiera/[Openhub.net]:
|
||||
|
||||
------------------------------------------------------------
|
||||
Extremely well-commented source code
|
||||
|
|
|
|||
|
|
@ -12,14 +12,13 @@ NoBug logging flag hierachy
|
|||
link:NoBug[] logging flag hierachy
|
||||
----------------------------------
|
||||
|
||||
link:NoBug[] allows hierachical organization of logging flags. Propose a
|
||||
documentation/planning about the setup.
|
||||
https://nobug.pipapo.org/[NoBug] allows hierachical organization of logging flags.
|
||||
Propose a documentation/planning about the setup.
|
||||
|
||||
Description
|
||||
~~~~~~~~~~~
|
||||
Take a look at my draft at:
|
||||
link:http://www.lumiera.org/gitweb?p=lumiera/ct;a=blob;f=doc/devel/nobug_flags.t
|
||||
t;h=74471e255e6ebfedb642e450bdfd3f79e346c600;hb=backend[NoBug_flags]
|
||||
https://git.lumiera.org/?p=LUMIERA;a=blob;f=doc/devel/nobug_flags.txt;h=325141acb52a7be7f75425359b6057c74ed30253;hb=a03e3c5e73a4c0be2264ac4e4e0f02eb8749837b[nobug_flags.txt]
|
||||
|
||||
I've added the things I planning for the backend, others might add their own
|
||||
plans there too. So far this is an early draft, comments welcome.
|
||||
|
|
@ -29,7 +28,7 @@ NOTE: outdated information. Have a look at `include/logging.h`
|
|||
Tasks
|
||||
~~~~~
|
||||
* Needs a file.c defining the common root see
|
||||
link:Lumiera/DesignProcess/GlobalInitialization[]
|
||||
link:{ldoc}/devel/rfc/GlobalInitialization.html[RfC: Global Initialization]
|
||||
* Everyone needs to setup this hierachy by NOBUG_DEFINE_FLAG_PARENT (flag,
|
||||
parent_flag);
|
||||
|
||||
|
|
|
|||
|
|
@ -85,14 +85,14 @@ Alternatives
|
|||
* We only consider auto-vectorization -- GCC is attempting to convert trivial
|
||||
loops into common SSE patterns. Newer or Higher level instructions may not be
|
||||
supported by GCC. This is turned on
|
||||
http://gcc.gnu.org/projects/tree-ssa/vectorization.html[in GCC4.3 with
|
||||
https://gcc.gnu.org/projects/tree-ssa/vectorization.html[in GCC4.3 with
|
||||
specific compiler flags]
|
||||
* We can consider assembly but we don't officially support it -- We leave the
|
||||
holes there for people to patch up later. Unofficial ports may come up, and
|
||||
maybe a few years down the line we can reconsider assembly and start to
|
||||
reimplement it down the road.
|
||||
* Find a SIMD library for C/C++ -- Intel's ICC and
|
||||
http://gcc.gnu.org/onlinedocs/gcc-3.4.6/gcc/Vector-Extensions.html[GCC] both
|
||||
https://gcc.gnu.org/onlinedocs/gcc-3.4.6/gcc/Vector-Extensions.html[GCC] both
|
||||
have non-standard extensions to C that roughly translate to these
|
||||
instructions. There is also the
|
||||
http://www.pixelglow.com/macstl/valarray/[macstl valarray library] mentioned
|
||||
|
|
|
|||
|
|
@ -70,7 +70,7 @@ Conclusion
|
|||
----------
|
||||
|
||||
This Design Proposal is 'superseded' by a much more advanced proposal:
|
||||
link:DelectusShotEvaluator[Delectus]
|
||||
link:/rfc/DelectusShotEvaluator.html[Delectus]
|
||||
|
||||
(Dropping it doesn't mean disapproval)
|
||||
|
||||
|
|
|
|||
|
|
@ -74,9 +74,9 @@ Comments
|
|||
use to drive tests, should be something smaller and more sane than python.
|
||||
Needs certainly more discussion. For simple unit tests some C/C++ harness and
|
||||
bit shell scripting would suffice, I really want to integrate this with
|
||||
link:NoBug[].
|
||||
https://nobug.pipapo.org/[NoBug].
|
||||
-- link:ct[] [[DateTime(2007-06-17T17:32:27Z)]]
|
||||
|
||||
|
||||
''''
|
||||
Back to link:../DesignProcess[]
|
||||
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]
|
||||
|
|
|
|||
|
|
@ -51,7 +51,7 @@ the hierarchy,
|
|||
==== The Uppermost Layer
|
||||
|
||||
At the highest, uppermost layer is the document
|
||||
https://lumiera.org/documentation/user/intro/intro.html[Lumiera (as seen) from Outer Space]. This is the node
|
||||
link:user/intro/intro.html[Lumiera (as seen) from Outer Space]. This is the node
|
||||
on the left in the illustration above. All new to Lumiera should read this document. You can always return
|
||||
to this document later if you are entirely lost and wish to find your bearings before navigating into the
|
||||
deeper documentation dungeons.
|
||||
|
|
@ -76,15 +76,15 @@ section has two main sections:
|
|||
[width="90%",frame="topbot",options="header",cols="^,2<"]
|
||||
|================================================================================================
|
||||
|Sub-System|Remarks
|
||||
|https://lumiera.org/documentation/design/architecture/index.html[Architecture]|Structure of Lumiera
|
||||
|https://lumiera.org/documentation/design/gui/index.html[GUI]|The Lumiera ⟷ user interaction layer
|
||||
|https://lumiera.org/documentation/design/model/index.html[Model]|Low-level and high-level models
|
||||
|https://lumiera.org/documentation/design/engine/index.html[Engine]|Renderer, output generation, ...
|
||||
|https://lumiera.org/documentation/design/lowlevel/index.html[Low-level]|Low-level and system services
|
||||
|https://lumiera.org/documentation/design/application/index.html[Application]|Application framework
|
||||
|https://lumiera.org/documentation/design/plugins/index.html[Plugins]|Dynamically loaded Extensions
|
||||
|https://lumiera.org/documentation/design/workflow/index.html[Workflow]|Workflow and Interaction Design
|
||||
|https://lumiera.org/documentation/design/governance/index.html[Governance]|Meta project concerns
|
||||
|link:design/architecture/[Architecture]|Structure of Lumiera
|
||||
|link:design/gui/[GUI]|The Lumiera ⟷ user interaction layer
|
||||
|link:design/model/[Model]|Low-level and high-level models
|
||||
|link:design/engine/[Engine]|Renderer, output generation, ...
|
||||
|link:design/lowlevel/[Low-level]|Low-level and system services
|
||||
|link:design/application/[Application]|Application framework
|
||||
|link:design/plugins/[Plugins]|Dynamically loaded Extensions
|
||||
|link:design/workflow/[Workflow]|Workflow and Interaction Design
|
||||
|link:design/governance/[Governance]|Meta project concerns
|
||||
|================================================================================================
|
||||
|
||||
|
||||
|
|
@ -94,15 +94,15 @@ section has two main sections:
|
|||
[width="90%",frame="topbot",options="header",cols="^,2<"]
|
||||
|================================================================================================
|
||||
|Sub-System|Remarks
|
||||
|https://lumiera.org/documentation/technical/build/index.html[Build System]|Build, Packaging and CI
|
||||
|https://lumiera.org/documentation/technical/stage/index.html[Stage]|GUI (technical aspects)
|
||||
|https://lumiera.org/documentation/technical/steam/index.html[Steam]|Session and processing coordination
|
||||
|https://lumiera.org/documentation/technical/vault/index.html[Vault]|Low-level operations
|
||||
|https://lumiera.org/documentation/technical/library/index.html[Support lib]|Interface and support libraries
|
||||
|https://lumiera.org/documentation/technical/code/index.html[Code base]|Code management, organisation, ...
|
||||
|https://lumiera.org/documentation/technical/infra/index.html[Infrastructure]|Website and developer tooling ...
|
||||
|https://lumiera.org/documentation/technical/howto/index.html[Developer HowTos]|Instructions and guides for developers
|
||||
|link:/doxy/index.html[API Doc]|Using link:http://doxygen.org[Doxygen] to generate doc from code
|
||||
|link:technical/build/[Build System]|Build, Packaging and CI
|
||||
|link:technical/stage/[Stage]|GUI (technical aspects)
|
||||
|link:technical/steam/[Steam]|Session and processing coordination
|
||||
|link:technical/vault/[Vault]|Low-level operations
|
||||
|link:technical/library/[Support lib]|Interface and support libraries
|
||||
|link:technical/code/[Code base]|Code management, organisation, ...
|
||||
|link:technical/infra/[Infrastructure]|Website and developer tooling ...
|
||||
|link:technical/howto/[Developer HowTos]|Instructions and guides for developers
|
||||
|link:/doxy/[API Doc]|Using https://www.doxygen.nl/[Doxygen] to generate doc from code
|
||||
|================================================================================================
|
||||
|
||||
|
||||
|
|
@ -113,13 +113,13 @@ mostly used as design notebook, featuring day-to-day design sketches, notes but
|
|||
quite some more persistent planning. Finished documentation text is constantly
|
||||
moved over to the documentation section(s) of the Lumiera website.
|
||||
|
||||
-> access the Development link:{l}/wiki/renderengine.html[TiddlyWiki online here]
|
||||
-> access the Development link:/wiki/renderengine.html[TiddlyWiki online here]
|
||||
|
||||
|
||||
== Media and Presentations ==
|
||||
|
||||
This section holds documents and materials used to present and promote Lumiera,
|
||||
articles, summaries and whitepapers
|
||||
-> link:/media/index.html[Index]
|
||||
-> link:/media/[Index]
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -89,7 +89,7 @@ Libraries
|
|||
|
||||
* BOOST
|
||||
* link:http://nobug.pipapo.org/[NoBug]
|
||||
* http://gmerlin.sourceforge.net/gavl.html[GAVL] (for raw media support)
|
||||
* https://github.com/bplaum/gavl[GAVL] (for raw media support)
|
||||
* ALSA: libasound2-dev
|
||||
* for the GUI: (*GTK-3*) gtkmm-3.0 gdlmm-3.0 glibmm-2.4 cairomm-1.0 xv
|
||||
- libgtkmm-3.0-dev
|
||||
|
|
|
|||
|
|
@ -59,25 +59,25 @@ Ok that above doesnt look good, but would do the job with some efforts
|
|||
Now lets factor this to some shell functions:
|
||||
|
||||
------------------------------------------------------------
|
||||
function link:AddToReport[]()
|
||||
function AddToReport()
|
||||
{
|
||||
cat >>,build_drone_report
|
||||
}
|
||||
|
||||
function link:GitPull[]()
|
||||
function GitPull()
|
||||
{
|
||||
local dir="$1"
|
||||
local repo="${2:-origin}"
|
||||
local branch="${3:-master}"
|
||||
ACTION="GitPull $*"
|
||||
RESULT=FAILURE
|
||||
cd "$dir" 2>&1 | link:AddToReport[] , return 1
|
||||
git pull "$repo" "$branch" 2>&1 | link:AddToReport[] , return 1
|
||||
cd "$dir" 2>&1 | AddToReport , return 1
|
||||
git pull "$repo" "$branch" 2>&1 | AddToReport , return 1
|
||||
RESULT=SUCCESS
|
||||
return 0
|
||||
}
|
||||
|
||||
function link:SendMail[]
|
||||
function SendMail
|
||||
{
|
||||
cat ,build_drone_mail <<EOF
|
||||
Subject: Build Drone Report
|
||||
|
|
@ -98,10 +98,10 @@ EOF
|
|||
now we can do following: (looks much nicer or?)
|
||||
|
||||
------------------------------------------------------------
|
||||
if link:GitPull[] project_dir; then
|
||||
link:SendMail[] foo@bar.com other@blah.net
|
||||
if GitPull project_dir; then
|
||||
SendMail foo@bar.com other@blah.net
|
||||
else
|
||||
link:SendMail[] boss@bar.com
|
||||
SendMail boss@bar.com
|
||||
fi
|
||||
------------------------------------------------------------
|
||||
|
||||
|
|
@ -113,11 +113,11 @@ for i in "/build_drone/project/*"; do
|
|||
(
|
||||
source "$i"
|
||||
)
|
||||
link:CallTrigger[]
|
||||
CallTrigger
|
||||
done
|
||||
------------------------------------------------------------
|
||||
|
||||
... ok enough for now, whats needed is the link:CallTrigger[] implementation,
|
||||
... ok enough for now, whats needed is the CallTrigger implementation,
|
||||
stopping processes waiting (either reading on a pipe or wait for signal (-CONT
|
||||
for success, -TERM for failure))
|
||||
|
||||
|
|
@ -140,7 +140,7 @@ Example:
|
|||
|
||||
|
||||
------------------------------------------------------------
|
||||
function link:BatchJob[]()
|
||||
function BatchJob()
|
||||
{
|
||||
batch <<EOF
|
||||
|
||||
|
|
@ -169,16 +169,16 @@ Actions and Handlers Brainstorming
|
|||
|
||||
Ideas, not in order
|
||||
|
||||
link:SendMail[]::
|
||||
SendMail::
|
||||
send report as email
|
||||
link:GitPull[]::
|
||||
GitPull::
|
||||
updates a git checkout +
|
||||
Split this in
|
||||
* link:GitFetch[]
|
||||
* GitFetch
|
||||
fetch from remote
|
||||
* link:GitHasChanges[]
|
||||
* GitHasChanges
|
||||
are there changes between HEAD and remote?
|
||||
* link:GitCheckout[]
|
||||
* GitCheckout
|
||||
reset to the remote head and checkout
|
||||
Bootstrap::
|
||||
autoreconf and configure
|
||||
|
|
@ -190,10 +190,10 @@ Distcheck::
|
|||
runs 'make distcheck'
|
||||
Doxygen::
|
||||
runs doxygen
|
||||
link:StyleCheck[]::
|
||||
StyleCheck::
|
||||
checks if files violate the style rules, something like:
|
||||
'astyle --style=gnu <$FILE.c | diff -u FILE.c - ...'
|
||||
link:ToDos[]::
|
||||
ToDos::
|
||||
greps for TODO (with some -A context) and produces a report
|
||||
* beautify (asciidoc) reports
|
||||
* publish reports, packages etc to the webserver (scp, rsync)
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ SCons Build-System
|
|||
|
||||
//MENU: label SCons Build
|
||||
|
||||
Lumiera uses a build system based on link:http://scons.org[SCons]
|
||||
Lumiera uses a build system based on https://scons.org/[SCons]
|
||||
|
||||
SCons is an open source software construction tool based on Python build definition scripts.
|
||||
Within these build scripts, we define a data structure to describe the parts and dependencies
|
||||
|
|
@ -14,7 +14,7 @@ the source tree to derive a build strategy, which is then performed.
|
|||
|
||||
SCons core concepts
|
||||
-------------------
|
||||
^_this section is based on the introductory pages on the link:http://www.scons.org/wiki/BasicConcepts[SCons Wiki]_^
|
||||
^_this section is based on the introductory pages on the https://github.com/SCons/scons/wiki/BasicConcepts[SCons Wiki]_^
|
||||
|
||||
.SCons Environment
|
||||
When SCons starts building the project, it creates its own environment with dependency trees,
|
||||
|
|
@ -127,7 +127,7 @@ are defined as SVG graphics. The build process creates a helper executable (+rsv
|
|||
these vector graphics with the help of lib Cairo into icon collections of various sizes.
|
||||
|
||||
.documentation
|
||||
Largely, the documentation is written in Asciidoc and provided online at link:{ldoc}[the documentation section]
|
||||
Largely, the documentation is written in Asciidoc and provided online at link:{ldoc}/[the documentation section]
|
||||
of our website. The plain-text sources of this documentation tree is shipped alongside with the code.
|
||||
Besides, we build *Doxygen* API documentation there, and we create design and technical specs and drawings
|
||||
in SVG and in UML.
|
||||
|
|
|
|||
|
|
@ -14,6 +14,6 @@ build -- continuous integration -- packaging
|
|||
* link:BuildDependencies.html[Lumiera Build Dependencies]
|
||||
* link:BuildDroneDraft.html[»Builddrone« concept from 2008]
|
||||
* Packaging: link:LumieraDebianPackage.html[Debian] RPM
|
||||
* Lumiera link:../infra/debianDepot.html/[debian depot]
|
||||
* Lumiera link:{ldoc}/technical/infra/debianDepot.html[debian depot]
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -133,7 +133,7 @@ General Code Arrangement and Layout
|
|||
code size. Avoid unnecessary includes. Use forward declarations where applicable.
|
||||
Yet still, _all immediately required direct dependencies should be mentioned_, even if already
|
||||
included by another dependency. See the extensive discussion of these
|
||||
link:{ldoc}/technical/code/linkingStructure.html#_imports_and_import_order[issues of code organisation]
|
||||
link:{ldoc}/technical/code/LinkingStructure.html#_imports_and_import_order[issues of code organisation]
|
||||
- The include block starts with our own dependencies, followed by a second block with the library
|
||||
dependencies. After that, optionally some symbols may be brought into scope (through +using+ clauses).
|
||||
Avoid cluttering top-level namespaces. Never import full namespaces.footnote:[No `using namespace gtk;`
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ releases and bugfixes directly as structure in the Git history, without much nee
|
|||
release planning, coordination and management.
|
||||
|
||||
TIP: The principles and procedures of *Git-flow* are explained in this
|
||||
->{nbsp}{l}/project/background/GitFlow.html[Background Article]. First
|
||||
-> link:/project/background/GitFlow.html[Background Article]. First
|
||||
link:https://nvie.com/posts/a-successful-git-branching-model/[published in 2010]
|
||||
by _Vincent Driessen_, meanwhile it is widely applied in projects with regular releases
|
||||
and external liabilities -- and often seen as the counterpoint to trunk centred
|
||||
|
|
|
|||
|
|
@ -351,7 +351,7 @@ actively step by step
|
|||
Gui.resourcepath:: the place where the GTK-UI looks for further resources, most notably...
|
||||
|
||||
Gui.stylesheet:: the name of the CSS-stylesheet for GTK-3, which defines the
|
||||
application specific look, link:{ldoc}/technical/stage/style[styling and theme].
|
||||
application specific look, link:{ldoc}/technical/stage/style/[styling and theme].
|
||||
|
||||
While the first two steps, the relative locations `$ORIGIN/modules` and `$ORIGIN/setup.ini`
|
||||
are hard-wired, the further resolution steps rely on the contents of 'setup.ini' and are
|
||||
|
|
@ -426,8 +426,8 @@ https://wiki.debian.org/RpathIssue[this Debian page] ] -- with the exception of
|
|||
intended for usage by the given executable or other libraries within the same source package.
|
||||
|
||||
In the new system, the precedence order is as follows footnote:[see
|
||||
http://linux.die.net/man/8/ld.so[ld.so manpage on die.net] or
|
||||
http://manpages.ubuntu.com/manpages/lucid/man8/ld.so.8.html[ld.so manpage ubuntu.com (more recent)] ]
|
||||
https://linux.die.net/man/8/ld.so[ld.so manpage on die.net] or
|
||||
https://manpages.ubuntu.com/manpages/jammy/man8/ld.so.8.html[ld.so manpage ubuntu.com (more recent)] ]
|
||||
|
||||
. `LD_LIBRARY_PATH` entries, unless the executable is `setuid`/`setgid`
|
||||
. `DT_RUNPATH` from the `.dynamic` section of that ELF binary, library or executable
|
||||
|
|
@ -444,9 +444,9 @@ NOTE: The new-style `DT_RUNPATH` is not extended recursively when resolving tran
|
|||
visit _only_ the `RUNPATH` given in 'libB.so', but _not_ the `RUNPATH` given in 'libA.so'
|
||||
(to the contrary, the old `RPATH` used to visit all these locations). +
|
||||
This behaviour was chosen deliberately, in compliance with the ELF spec, as can be seen in this
|
||||
link:https://sourceware.org/bugzilla/show_bug.cgi?id=13945[glibc bug #13945] and the
|
||||
https://sourceware.org/bugzilla/show_bug.cgi?id=13945[glibc bug #13945] and the
|
||||
developer comment by
|
||||
link:https://sourceware.org/ml/libc-hacker/2002-11/msg00011.html[Roland McGrath from 2002]
|
||||
https://sourceware.org/legacy-ml/libc-hacker/2002-11/msg00011.html[Roland McGrath from 2002]
|
||||
mentioned therein.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -46,7 +46,7 @@ Guidelines
|
|||
////
|
||||
|
||||
''''
|
||||
* also see the link:{ldoc}/devel/rfc.html[Design Process] for ongoing discussions
|
||||
* also see the link:{ldoc}/devel/rfc/index.html[Design Process] for ongoing discussions
|
||||
* see the link:/devs-vault/[Developers Vault] for frequently used developer's resources
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@ from libstdcxx.v6.printers import register_libstdcxx_printers
|
|||
register_libstdcxx_printers (None)
|
||||
end
|
||||
----
|
||||
For more informations link:http://sourceware.org/gdb/wiki/STLSupport[see here..]
|
||||
For more informations https://sourceware.org/gdb/wiki/STLSupport[see here..]
|
||||
|
||||
.Hello World
|
||||
[source,C]
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ Using Boost Libraries
|
|||
|
||||
//Menu: label using Boost
|
||||
|
||||
_some arbitrary hints and notes regarding the use of link::http://www.boost.org[Boost Libraries] in Lumiera_
|
||||
_some arbitrary hints and notes regarding the use of https://www.boost.org/[Boost Libraries] in Lumiera_
|
||||
|
||||
Notable Features
|
||||
----------------
|
||||
|
|
|
|||
|
|
@ -8,12 +8,14 @@ Developer HOWTOs
|
|||
This section contains a loose collection of instructions, recipes, tutorials and
|
||||
similar usefull pieces of information targeted at Lumiera developers. See also
|
||||
|
||||
- the general link:{l}/project/faq.html[Lumiera FAQ]
|
||||
- the general link:/project/faq.html[Lumiera FAQ]
|
||||
- the link:{ldoc}/user/index.html[User documentation]
|
||||
- link::{ldoc}/technical/code/index.html[Codebase organisation]
|
||||
|
||||
== Notepad
|
||||
- a link:crackNuts.html[collection] of solution ideas
|
||||
- link:DebugGdbPretty.html[Python pretty printers for GDB]
|
||||
- link:IdeSetup.html[hints for using some IDE(s)]
|
||||
- link:UsingBoost.html[some remarks regarding libBoost]
|
||||
- link:HashFunctions.html[Notes regarding standard hash functions]
|
||||
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ link:overview.html[Lumiera the Inner Core]
|
|||
|
||||
The technical documentation is split in three parts, one for each of the three
|
||||
main layers of Lumiera. You may want to read the
|
||||
link:../design/index.html[Design Documents] first to get an overview of all the
|
||||
link:{ldoc}/design/index.html[Design Documents] first to get an overview of all the
|
||||
components.
|
||||
|
||||
* link:stage/index.html[*Stage Layer*] : Documents related to the GTK based Lumiera GUI
|
||||
|
|
@ -30,13 +30,13 @@ components.
|
|||
== Tools
|
||||
|
||||
.Development
|
||||
* link:http://www.lumiera.org/doxy/[*Doxygen generated documentation*] : API documentation of the Lumiera code.
|
||||
* link:/doxy/[*Doxygen* generated documentation] : API documentation of the Lumiera code.
|
||||
* organisation of the link:code/index.html[Code Base] in general
|
||||
* link:code/codingGuidelines.html[Coding Style] and further guidelines
|
||||
* link:/x/CodingGuidelines.html[Coding Style] and further guidelines
|
||||
|
||||
.Building
|
||||
* link:build/index.html[*Buildsystem*] : Installation & compilation tools, dependencies and packaging.
|
||||
* link:build/index.html[Buildsystem] : Installation & compilation tools, dependencies and packaging.
|
||||
|
||||
.HOWTO
|
||||
* link:howto/index.html[*Developer HOWTOs*] : Collection of instructions, recipes, hints and similar
|
||||
* link:/x/DevHowto.html[Developer *HOWTOs*] : Collection of instructions, recipes, hints and similar
|
||||
materials intended for developers
|
||||
|
|
|
|||
|
|
@ -6,7 +6,9 @@ Lumiera Debian Package and Depot maintainance
|
|||
//Menu: label Debian Depot
|
||||
|
||||
This Debian-Depot is part of the Lumiera build infrastructure.
|
||||
It is managed automatically, based on the link:http://mirrorer.alioth.debian.org/[reprepro] tool by Bernhard Link
|
||||
It is managed automatically, based on the
|
||||
https://salsa.debian.org/brlink/reprepro[reprepro] tool by Bernhard Link
|
||||
-> https://manpages.debian.org/trixie/reprepro/reprepro.1.en.html[man page]
|
||||
|
||||
|
||||
The Lumiera debian package
|
||||
|
|
|
|||
|
|
@ -126,7 +126,7 @@ _assuming full portability and arbitrary target platform._ Since our focus is pr
|
|||
this argument seems to lean more to the theoretical side though, since the x86/64 platform is known to employ rather
|
||||
strong memory and cache coherency constraints. With the recent advent of ARM systems, the situation has changed however.
|
||||
Anyway, since C++11 there
|
||||
link:http://preshing.com/20130930/double-checked-locking-is-fixed-in-cpp11[is now a portable solution available]
|
||||
https://preshing.com/20130930/double-checked-locking-is-fixed-in-cpp11/[is now a portable solution available]
|
||||
for writing a correct DCL implementation, based on `std::atomic`.
|
||||
|
||||
The idea underlying Double Checked Locking is to optimise for the access path, which is achieved by moving the
|
||||
|
|
@ -136,7 +136,7 @@ and lock-free concurrency implement this relation by establishing a *synchronise
|
|||
on a common *guard* entity -- for traditional locking, this would be a Lock, Mutex, Monitor or Semaphore, while
|
||||
lock-free concurrency uses the notion of a _fence_ connected with some well defined action on a userspace guard variable.
|
||||
In modern C++, typically we use _Atomic variables_ as guard. In addition to well defined semantics regarding concurrent
|
||||
visibility of changes, these link:http://en.cppreference.com/w/cpp/atomic["atomics"] offer indivisible access and
|
||||
visibility of changes, these https://en.cppreference.com/w/cpp/atomic.html["atomics"] offer indivisible access and
|
||||
exchange operations. A correct concurrent interaction must involve some kind of well defined handshake to establish
|
||||
the aforementioned _synchronises-with_ relation -- otherwise we just can not assume anything. Herein lies the problem
|
||||
with Double Checked Locking: when we move all concurrency precautions away from the optimised access path, we get
|
||||
|
|
@ -177,7 +177,7 @@ the actual costs of object allocation.
|
|||
Some observations:
|
||||
|
||||
- The numbers obtained pretty much confirm
|
||||
link:http://www.modernescpp.com/index.php/thread-safe-initialization-of-a-singleton[other people's measurments].
|
||||
http://www.modernescpp.com/index.php/thread-safe-initialization-of-a-singleton/[other people's measurments].
|
||||
- Synchronisation is indeed necessary;
|
||||
the unprotected lazy init crashed several times randomly during multithreaded tests.
|
||||
- Contention on concurrent access is very tangible;
|
||||
|
|
|
|||
|
|
@ -136,7 +136,7 @@ permutation diff. If we thus consider -- in theory -- the _inserts_ and _deletes
|
|||
filtered away, what remains is a permutation of index numbers to cause the re-ordering.
|
||||
We may describe this re-ordering by the index numbers in the new sequence, given in the order
|
||||
of the old sequence. For such a re-ordering permutation, the theoretically optimal result
|
||||
can be achieved by http://wikipedia.org/wiki/Cycle_sort[Cycle Sort] in _linear time_.footnote:[
|
||||
can be achieved by https://en.wikipedia.org/wiki/Cycle_sort[Cycle Sort] in _linear time_.footnote:[
|
||||
assuming random access by index is possible, *Cycle Sort* walks the sequence once. Whenever
|
||||
encountering an element out-of order, i.e. new postion != current position, we leap to the
|
||||
indicated new position, which necessarily will be out-of-order too, so we can leap from there
|
||||
|
|
@ -201,7 +201,7 @@ changes in hierarchical data: traverse the structure and account for each elemen
|
|||
Such a description of changes won't be _optimal_ though. What appears as a insertion or deletion locally,
|
||||
might indeed be just the result of rearranging subtrees as a whole. The _tree diff problem_ in this general
|
||||
form is known to be a rather tough challenge. But our goals are different here. Lumiera relies on a
|
||||
link:{ldoc}/design/architecture/ExternalTreeDescription.html[»External Tree Description«] for
|
||||
link:{ldoc}/design/architecture/ETD.html[»External Tree Description«] for
|
||||
_symbolic representation_ of hierarchically structured elements, without actually implementing them.
|
||||
The purpose of this ``external'' description is to largely remove the need for a central data model
|
||||
to work against. A _symbolic diff message_ allows to propagate data and structure changes,
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
Iterators and Pipelines
|
||||
=======================
|
||||
|
||||
The link:http://c2.com/cgi/wiki?IteratorPattern[Iterator Pattern] allows to
|
||||
The http://wiki.c2.com/?IteratorPattern[Iterator Pattern] allows to
|
||||
expose the contents or elements of any kind of collection, set or container
|
||||
for use by client code, without exposing the implementation of the underlying
|
||||
data structure. Thus, iterators are one of the primary API building blocks.
|
||||
|
|
@ -14,7 +14,7 @@ Unfortunately the C++ standard library uses a very elaborate and rather low-leve
|
|||
notion of iterators, which does not mix well with the task of building clean interfaces.
|
||||
|
||||
Thus, within the Lumiera core application, we're using our own Iterator concept,
|
||||
initially defined as link:{ldoc}/devel/rfc/LumieraForwardIterator.html[RfC],
|
||||
initially defined as link:/x/rfc/LumieraForwardIterator.html[RfC],
|
||||
which places the primary focus on interfaces and decoupling, trading off
|
||||
readability and simplicity for (lesser) performance.
|
||||
|
||||
|
|
|
|||
|
|
@ -67,14 +67,14 @@ website you're reading right now. Besides that, a summary and introduction
|
|||
for various components can be found in the file-level doxygen comments, while
|
||||
details are usually explained in the class and function level comments.
|
||||
|
||||
==== the TiddlyWiki
|
||||
==== the Development TiddlyWiki
|
||||
Currently, Lumiera is still in the design- and evolution phase. Documentation
|
||||
is written as an ongoing effort.
|
||||
There is an embedded JavaScript wiki (TiddlyWiki) within the source tree, mostly
|
||||
used as design notebook, featuring day-to-day design sketches and notes, but also
|
||||
quite some more persistent planning. Finished documentation text is constantly
|
||||
moved over to the documentation section(s) of the Lumiera website. +
|
||||
-> access the development link:{l}/wiki/renderengine.html[TiddlyWiki online here]
|
||||
-> access the development link:/wiki/renderengine.html[TiddlyWiki online here]
|
||||
|
||||
|
||||
Test Driven Development
|
||||
|
|
@ -888,7 +888,7 @@ with an type specific access functor. Together, this allows to translate
|
|||
transparently and typesafe from symbolic ID to object instance, which
|
||||
is an prerequisite for integrating a rules based system. Besides, these
|
||||
tables allow unique IDs per type +
|
||||
-> more details about this concept link:{l}/wiki/renderengine.html#EntryID%20TypedID%20TypedLookup[in the TiddlyWiki]
|
||||
-> more details about this concept link:/wiki/renderengine.html#EntryID%20TypedID%20TypedLookup[in the TiddlyWiki]
|
||||
|
||||
|
||||
Allocators
|
||||
|
|
|
|||
|
|
@ -48,23 +48,28 @@ class constructor,_ which makes them more or less hard wired. The `Gtk::Widget`
|
|||
their own naming scheme, apart from the basic GTK+ (C language) names, and it is _basically not possible_ for _custom widgets_
|
||||
to expose their distinct type names -- rather they will show up under the name of the base class used from Gtkmm.]
|
||||
Widgets may also expose CSS classes for styling -- the standard widgets define a generic set
|
||||
of https://developer.gnome.org/gtk3/3.4/GtkStyleContext.html#gtkstylecontext-classes[predefined CSS style classes],
|
||||
of https://docs.gtk.org/gtk3/class.StyleContext.html#style-classes-gtkstylecontext-classes[predefined CSS style classes],
|
||||
which can be used to establish the foundation for theming. Obviously it is preferable to keep styling rules as
|
||||
concise, generic and systematic as possible; yet we may still refer to individual GUI elements by name (`#ID`) though.
|
||||
|
||||
Recommended reading
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
* for technically precise coverage, consult the pages
|
||||
https://developer.gnome.org/gtk3/3.4/GtkCssProvider.html[GtkCssProvider]
|
||||
https://docs.gtk.org/gtk3/class.CssProvider.html[GtkCssProvider]
|
||||
and
|
||||
https://developer.gnome.org/gtk3/3.4/GtkStyleContext.html#gtkstylecontext-classes[predefined style classes]
|
||||
https://docs.gtk.org/gtk3/class.StyleContext.html#style-classes-gtkstylecontext-classes[predefined style classes]
|
||||
in the GTK-3 reference manual.
|
||||
* there is an https://developer.gnome.org/gtk3/stable/chap-css-overview.html[overview page in the developer manual],
|
||||
and a https://developer.gnome.org/gtk3/stable/chap-css-properties.html[reference of supported properties].
|
||||
* to start, look at this http://thegnomejournal.wordpress.com/2011/03/15/styling-gtk-with-css/[introductory text],
|
||||
or the more http://worldofgnome.org/making-gtk3-themes-part-1-basics/[hands-on series of articles from world of gnome]
|
||||
* this http://forums.fedoraforum.org/showthread.php?t=281568[post from fedora forum] features a concise description
|
||||
of the task of theme creation
|
||||
* there is an
|
||||
https://docs.gtk.org/gtk3/css-overview.html[overview page in the developer manual],
|
||||
and a
|
||||
https://docs.gtk.org/gtk3/css-properties.html[reference of supported properties].
|
||||
* to start, look at this https://thegnomejournal.wordpress.com/2011/03/15/styling-gtk-with-css/[introductory text],
|
||||
or the more
|
||||
https://web.archive.org/web/20201112013720/http://worldofgnome.org/making-gtk3-themes-part-1-basics/[hands-on series of articles from world of gnome]
|
||||
* this
|
||||
https://forums.fedoraforum.org/showthread.php?281568-Tutorial-for-making-GTK3-themes[post from fedora forum]
|
||||
(https://web.archive.org/web/20250703120330/https://forums.fedoraforum.org/showthread.php?281568-Tutorial-for-making-GTK3-themes[Archive.org])
|
||||
features a concise description of the task of theme creation
|
||||
* to understand the old (now obsolete) GTK-2 stylesheets, you might
|
||||
http://orford.org/gtk/[look here]
|
||||
|
||||
|
|
@ -86,7 +91,8 @@ A good recommendation is really to ``probe'' settings by changing them temporari
|
|||
the GTK+ inspector
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
An essential tool when working with styles and Gtk widgets in general is the
|
||||
https://wiki.gnome.org/Projects/GTK%2B/Inspector[GTK+ inspector], which is part of the standard GTK distribution.
|
||||
https://developer.gnome.org/documentation/tools/inspector.html[GTK+ inspector]
|
||||
, which is part of the standard GTK distribution.
|
||||
It allows to inspect all GTK objects with their properties, and to see the actual tree of CSS nodes and the
|
||||
corresponding selectors. You can even add a style class or state flag (like ``hover'') dynamically, and you
|
||||
may add style rules and verify the effect on the application immediately. To use this ispector, launch the
|
||||
|
|
@ -96,11 +102,11 @@ application like `GTK_DEBUG=interactive target/lumiera`
|
|||
binary themes
|
||||
~~~~~~~~~~~~~
|
||||
GTK-3 supports binary theme bundles, which combine CSS style sheets and accompanying images and vector graphics
|
||||
into a single archive file. See http://wibblystuff.blogspot.de/2012/06/building-binary-for-gtk3-theme.html[this blog entry]
|
||||
into a single archive file. See https://wibblystuff.blogspot.com/2012/06/building-binary-for-gtk3-theme.html[this blog entry]
|
||||
for a tutorial. But when it comes to investigating an existing theme, we need a way to 'extract' the original sources
|
||||
from such a distribution bundle. This can be achieved with the help of the `gresource` command. The following bash
|
||||
script footnote:[published by mailto:peter@thecodergeek.com[Peter Gordon] to the Public Domain
|
||||
http://projects.thecodergeek.com/scripts/gresource-extract[at his blog] in 2012] simplifies this process, allowing
|
||||
https://projects.thecodergeek.com/scripts/gresource-extract[at his blog] in 2012] simplifies this process, allowing
|
||||
to extract all resource files in a given GResource file, with the given base URL. For example, if a GResource file
|
||||
contained the resource with the URL `/org/foo/bar/baz.txt`, and the base URL defined as `"/org/foo/"`, then the resource
|
||||
named `/org/foo/bar/baz.txt` in that file would be extracted and written to `bar/baz.txt` in the current directory.
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ While additions to the TiddlyWiki generally propagate to Lumiera/Master through
|
|||
the normal merges, we've put up a rsynced version of the TiddlyWiki online for
|
||||
direct access (of course read-only).
|
||||
|
||||
-> access the Proy-Layer link:{l}/wiki/renderengine.html[TiddlyWiki online here]
|
||||
-> access the Proy-Layer link:/wiki/renderengine.html[TiddlyWiki online here]
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ ordered by priority and observing specific timing constraints.
|
|||
NOTE: Subject to [yellow-background]#active design and implementation# work as of 10/2023
|
||||
|
||||
Work-in-progress documentation can be found in the
|
||||
link:{l}/wiki/renderengine.html#PlaybackVerticalSlice%20RenderEngine%20Scheduler%20SchedulerWorker%20SchedulerMemory%20RenderActivity%20Player%20FrameDispatcher%20JobPlanningPipeline%20PlayProcess%20Rendering%20ProcNode%20NodeOperationProtocol[Tiddly Wiki]
|
||||
link:imp/PlaybackVerticalSlice.html[DevWiki: PlaybackVerticalSlice]
|
||||
|
||||
|
||||
About Jobs
|
||||
|
|
|
|||
|
|
@ -226,7 +226,7 @@ to facilitate automated processing.
|
|||
|
||||
Now it is time to take a look at the preliminary Lumiera GUI:
|
||||
|
||||
image:{l}/images/lumiera_gui_small.png[Current Lumiera GUI Screenshot]
|
||||
image:/images/lumiera_gui_small.png[Current Lumiera GUI Screenshot]
|
||||
|
||||
We expect this GUI to change once we are at the point of having feedback from actual users.
|
||||
|
||||
|
|
|
|||
|
|
@ -159,7 +159,8 @@ the package. With the exception of the following:
|
|||
- the top entry in the 'debian/changelog' defines the *actual package name and version*
|
||||
- the actual build process is conducted by invoking several pre defined targets in the
|
||||
'debian/rules' *makefile*. But modern debian packages often make use of the ``common
|
||||
debian build system'' link:http://build-common.alioth.debian.org/cdbs-doc.html[CDBS] --
|
||||
debian build system''
|
||||
https://web.archive.org/web/20170708155303/http://build-common.alioth.debian.org/cdbs-doc.html[CDBS] --
|
||||
basically a set of macros allowing to write these _rules_ in a very short and concise fashion
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -49,19 +49,19 @@ then usually the build system is right...]
|
|||
More specifically, you'll need the GNU C/C\++ compiler with C++17 support (Version >= 7)
|
||||
in addition to the following tools and libraries:
|
||||
|
||||
* link:http://git-scm.com/[Git] (version management system)
|
||||
* link:http://www.scons.org/[SCons build system]
|
||||
* link:http://www.boost.org/[Boost libraries]
|
||||
* link:http://gmerlin.sourceforge.net/[GAVL library]
|
||||
* link:http://nobug.pipapo.org/[NoBug] (see below)
|
||||
* https://git-scm.com/[Git] (version management system)
|
||||
* https://www.scons.org/[SCons build system]
|
||||
* https://www.boost.org/[Boost libraries]
|
||||
* https://github.com/bplaum/gavl[GAVL library]
|
||||
* https://nobug.pipapo.org/[NoBug] (see below)
|
||||
* Lumiera source code
|
||||
|
||||
The GUI depends on the following:
|
||||
|
||||
* link:http://www.gtkmm.org/en/[gtkmm]
|
||||
* link:http://cgit.freedesktop.org/xorg/lib/libXv[libXv]
|
||||
* link:https://wiki.gnome.org/LibRsvg[lib rSVG]
|
||||
* link:https://git.gnome.org/browse/gdl[lib GDL]
|
||||
* https://gtkmm.gnome.org/en/[gtkmm]
|
||||
* https://cgit.freedesktop.org/xorg/lib/libXv[libXv]
|
||||
* https://wiki.gnome.org/Projects/LibRsvg[lib rSVG]
|
||||
* https://gitlab.gnome.org/Archive/gdl.git[lib GDL]
|
||||
|
||||
TIP: Generally speaking, when you want to build software, you'll need the
|
||||
_development_ version of the packages that contain the headers and pre-built
|
||||
|
|
@ -213,7 +213,7 @@ Currently, this will bring up the GUI, _without any further functionality_ (!)
|
|||
|
||||
You should see something like this:
|
||||
|
||||
image:{l}/images/lumiera_gui_small.png[Current Lumiera GUI Screenshot]
|
||||
image:/images/lumiera_gui_small.png[Current Lumiera GUI Screenshot]
|
||||
|
||||
|
||||
What's next?
|
||||
|
|
|
|||
|
|
@ -50,8 +50,8 @@ right away and present your first results to the _mob repository_.
|
|||
First steps with Git
|
||||
^^^^^^^^^^^^^^^^^^^^
|
||||
One very useful place to begin with learning Git is the
|
||||
link:http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html[basic Git tutorial at Kernel.org]. +
|
||||
For more specific questions, you might consulte a link:http://gitref.org/[Git reference]
|
||||
https://www.kernel.org/pub/software/scm/git/docs/gittutorial.html[basic Git tutorial at Kernel.org]. +
|
||||
For more specific questions, you might consult a https://git-scm.com/docs[Git reference]
|
||||
|
||||
In the following, we assume you have set up Git on your system. If you are
|
||||
experiencing problems with Git, just ask the Lumiera community.
|
||||
|
|
@ -222,7 +222,7 @@ Besides, the Lumiera community generally meets on the second Thursday of
|
|||
each month at 20:00 UTC on IRC. All are more than welcome to join and
|
||||
to contribute to the discussions there.
|
||||
|
||||
-> contact information link:{l}/project/contact.html[Mailing List & IRC]
|
||||
-> contact information link:/project/contact.html[Mailing List & IRC]
|
||||
|
||||
''''
|
||||
|
||||
|
|
|
|||
|
|
@ -8,5 +8,5 @@ This page contains tutorials for beginners interested in Lumiera development.
|
|||
* link:building.html[Building Lumiera from source]
|
||||
* link:DebianBuilding.html[Building from Debian source package]
|
||||
* link:contributing.html[Contributing to Lumiera]
|
||||
** link:{l}/project/contact.html[Mailing List & IRC]
|
||||
** link:/project/contact.html[Mailing List & IRC]
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue