From 25eb6a61e39e0f968a087f0ffce6af7cba025145 Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Tue, 2 Sep 2025 19:42:49 +0200 Subject: [PATCH] clean-up: link maintenance - use HTTPS - avoid redirects - supply Archive.org snapshots for old resources --- doc/design/application/Config.txt | 2 +- doc/design/engine/PlayModes.txt | 3 +- .../GuiDiscussion/ConceptProposals/Barnes.txt | 2 +- .../GuiBrainstormingReviewed.txt | 7 ++-- .../GuiBrainstormingWontImplement.txt | 3 +- .../gui/GuiDiscussion/TimelineDiscussion.txt | 4 +- doc/design/gui/GuiDiscussion/Workspaces.txt | 2 +- doc/devel/meeting_summary/2008-09-04.txt | 2 +- doc/devel/meeting_summary/2008-12-10.txt | 4 +- doc/devel/meeting_summary/2011-03-09.txt | 2 +- doc/devel/meeting_summary/2011-04-13.txt | 2 +- doc/devel/meeting_summary/2012-09-12.txt | 5 ++- doc/devel/meeting_summary/2013-09-12.txt | 2 +- doc/devel/meeting_summary/2023-11-08.txt | 2 +- doc/devel/meeting_summary/2024-01-10.txt | 2 +- doc/devel/meeting_summary/index.txt | 4 +- doc/devel/report.txt | 12 ++---- doc/devel/rfc/AllPluginInterfacesAreC.txt | 2 +- doc/devel/rfc/ArchitectureOverview.txt | 7 +--- doc/devel/rfc/CCodingStyleGuide.txt | 3 +- doc/devel/rfc/CodingStyle.txt | 2 +- doc/devel/rfc/ConfigLoader.txt | 2 +- doc/devel/rfc/DelectusShotEvaluator.txt | 5 ++- doc/devel/rfc/DesignParamAutomation.txt | 2 +- doc/devel/rfc/DesignRenderNodesInterface.txt | 6 +-- doc/devel/rfc/LumieraDesignProcess.txt | 2 +- doc/devel/rfc/Manifest.txt | 6 +-- doc/devel/rfc/MarbleMode.txt | 2 +- doc/devel/rfc/MistakestoAvoid.txt | 2 +- doc/devel/rfc/NoBugFlags.txt | 9 ++-- doc/devel/rfc/OfficialAssemblyLanguage.txt | 4 +- doc/devel/rfc/TagCloudsOnResources.txt | 2 +- doc/devel/rfc/UnitTests_Python.txt | 4 +- doc/index.txt | 42 +++++++++---------- doc/technical/build/BuildDependencies.txt | 2 +- doc/technical/build/BuildDroneDraft.txt | 36 ++++++++-------- doc/technical/build/SCons.txt | 6 +-- doc/technical/build/index.txt | 2 +- doc/technical/code/CodingGuidelines.txt | 2 +- doc/technical/code/GitBranching.txt | 2 +- doc/technical/code/LinkingStructure.txt | 10 ++--- doc/technical/code/index.txt | 2 +- doc/technical/howto/DebugGdbPretty.txt | 2 +- doc/technical/howto/UsingBoost.txt | 2 +- doc/technical/howto/index.txt | 4 +- doc/technical/index.txt | 10 ++--- doc/technical/infra/debianDepot.txt | 4 +- doc/technical/library/Dependencies.txt | 6 +-- doc/technical/library/DiffFramework.txt | 4 +- doc/technical/library/iterator.txt | 4 +- doc/technical/overview.txt | 6 +-- doc/technical/stage/style/index.txt | 30 +++++++------ doc/technical/steam/index.txt | 2 +- doc/technical/vault/scheduler.txt | 2 +- doc/user/intro/intro.txt | 2 +- doc/user/tutorials/DebianBuilding.txt | 3 +- doc/user/tutorials/building.txt | 20 ++++----- doc/user/tutorials/contributing.txt | 6 +-- doc/user/tutorials/index.txt | 2 +- 59 files changed, 170 insertions(+), 163 deletions(-) diff --git a/doc/design/application/Config.txt b/doc/design/application/Config.txt index e6cbaf1e7..dec73272b 100644 --- a/doc/design/application/Config.txt +++ b/doc/design/application/Config.txt @@ -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) diff --git a/doc/design/engine/PlayModes.txt b/doc/design/engine/PlayModes.txt index d616aff9e..8e95583a3 100644 --- a/doc/design/engine/PlayModes.txt +++ b/doc/design/engine/PlayModes.txt @@ -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:: diff --git a/doc/design/gui/GuiDiscussion/ConceptProposals/Barnes.txt b/doc/design/gui/GuiDiscussion/ConceptProposals/Barnes.txt index b97a18128..b91be4aed 100644 --- a/doc/design/gui/GuiDiscussion/ConceptProposals/Barnes.txt +++ b/doc/design/gui/GuiDiscussion/ConceptProposals/Barnes.txt @@ -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 *********************************************************************************************************** diff --git a/doc/design/gui/GuiDiscussion/GuiBrainstormingReviewed.txt b/doc/design/gui/GuiDiscussion/GuiBrainstormingReviewed.txt index ca21bc5ab..5e63fa8af 100644 --- a/doc/design/gui/GuiDiscussion/GuiBrainstormingReviewed.txt +++ b/doc/design/gui/GuiDiscussion/GuiBrainstormingReviewed.txt @@ -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. diff --git a/doc/design/gui/GuiDiscussion/GuiBrainstormingWontImplement.txt b/doc/design/gui/GuiDiscussion/GuiBrainstormingWontImplement.txt index 8a3f92e15..55c0fdddc 100644 --- a/doc/design/gui/GuiDiscussion/GuiBrainstormingWontImplement.txt +++ b/doc/design/gui/GuiDiscussion/GuiBrainstormingWontImplement.txt @@ -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. diff --git a/doc/design/gui/GuiDiscussion/TimelineDiscussion.txt b/doc/design/gui/GuiDiscussion/TimelineDiscussion.txt index 6c6c2a6e9..502cd8f21 100644 --- a/doc/design/gui/GuiDiscussion/TimelineDiscussion.txt +++ b/doc/design/gui/GuiDiscussion/TimelineDiscussion.txt @@ -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 diff --git a/doc/design/gui/GuiDiscussion/Workspaces.txt b/doc/design/gui/GuiDiscussion/Workspaces.txt index 3e42239f0..937458a5e 100644 --- a/doc/design/gui/GuiDiscussion/Workspaces.txt +++ b/doc/design/gui/GuiDiscussion/Workspaces.txt @@ -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)]] diff --git a/doc/devel/meeting_summary/2008-09-04.txt b/doc/devel/meeting_summary/2008-09-04.txt index dbb7b0e5a..903756d79 100644 --- a/doc/devel/meeting_summary/2008-09-04.txt +++ b/doc/devel/meeting_summary/2008-09-04.txt @@ -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]## diff --git a/doc/devel/meeting_summary/2008-12-10.txt b/doc/devel/meeting_summary/2008-12-10.txt index 412a89a95..8e65b80fc 100644 --- a/doc/devel/meeting_summary/2008-12-10.txt +++ b/doc/devel/meeting_summary/2008-12-10.txt @@ -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 diff --git a/doc/devel/meeting_summary/2011-03-09.txt b/doc/devel/meeting_summary/2011-03-09.txt index 34d372a44..3e30b4da6 100644 --- a/doc/devel/meeting_summary/2011-03-09.txt +++ b/doc/devel/meeting_summary/2011-03-09.txt @@ -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 diff --git a/doc/devel/meeting_summary/2011-04-13.txt b/doc/devel/meeting_summary/2011-04-13.txt index 08de58437..af8d619b6 100644 --- a/doc/devel/meeting_summary/2011-04-13.txt +++ b/doc/devel/meeting_summary/2011-04-13.txt @@ -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. diff --git a/doc/devel/meeting_summary/2012-09-12.txt b/doc/devel/meeting_summary/2012-09-12.txt index 97d961efa..3b52a5331 100644 --- a/doc/devel/meeting_summary/2012-09-12.txt +++ b/doc/devel/meeting_summary/2012-09-12.txt @@ -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. diff --git a/doc/devel/meeting_summary/2013-09-12.txt b/doc/devel/meeting_summary/2013-09-12.txt index ae5ab1243..1130824d7 100644 --- a/doc/devel/meeting_summary/2013-09-12.txt +++ b/doc/devel/meeting_summary/2013-09-12.txt @@ -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. diff --git a/doc/devel/meeting_summary/2023-11-08.txt b/doc/devel/meeting_summary/2023-11-08.txt index 4bbde8449..920ec6fed 100644 --- a/doc/devel/meeting_summary/2023-11-08.txt +++ b/doc/devel/meeting_summary/2023-11-08.txt @@ -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]. diff --git a/doc/devel/meeting_summary/2024-01-10.txt b/doc/devel/meeting_summary/2024-01-10.txt index 90265a892..e6c6ed32e 100644 --- a/doc/devel/meeting_summary/2024-01-10.txt +++ b/doc/devel/meeting_summary/2024-01-10.txt @@ -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__ diff --git a/doc/devel/meeting_summary/index.txt b/doc/devel/meeting_summary/index.txt index 52c26ee7f..0649bf9f6 100644 --- a/doc/devel/meeting_summary/index.txt +++ b/doc/devel/meeting_summary/index.txt @@ -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 diff --git a/doc/devel/report.txt b/doc/devel/report.txt index 4d7bca080..1faa55e65 100644 --- a/doc/devel/report.txt +++ b/doc/devel/report.txt @@ -6,29 +6,23 @@ Statistics and Reports ++++++++++++++++++++++++++++++++++++++
- +
++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++
- +

++++++++++++++++++++++++++++++++++++++ '''' -^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 ------- diff --git a/doc/devel/rfc/AllPluginInterfacesAreC.txt b/doc/devel/rfc/AllPluginInterfacesAreC.txt index 2ee7b40ca..00558497e 100644 --- a/doc/devel/rfc/AllPluginInterfacesAreC.txt +++ b/doc/devel/rfc/AllPluginInterfacesAreC.txt @@ -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) diff --git a/doc/devel/rfc/ArchitectureOverview.txt b/doc/devel/rfc/ArchitectureOverview.txt index 4ece11a7c..79a03f1fc 100644 --- a/doc/devel/rfc/ArchitectureOverview.txt +++ b/doc/devel/rfc/ArchitectureOverview.txt @@ -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 diff --git a/doc/devel/rfc/CCodingStyleGuide.txt b/doc/devel/rfc/CCodingStyleGuide.txt index 7325b3961..25281d8ef 100644 --- a/doc/devel/rfc/CCodingStyleGuide.txt +++ b/doc/devel/rfc/CCodingStyleGuide.txt @@ -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. diff --git a/doc/devel/rfc/CodingStyle.txt b/doc/devel/rfc/CodingStyle.txt index 73d79ba94..1cef4e0a1 100644 --- a/doc/devel/rfc/CodingStyle.txt +++ b/doc/devel/rfc/CodingStyle.txt @@ -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! diff --git a/doc/devel/rfc/ConfigLoader.txt b/doc/devel/rfc/ConfigLoader.txt index 71c7b799b..6daa255ab 100644 --- a/doc/devel/rfc/ConfigLoader.txt +++ b/doc/devel/rfc/ConfigLoader.txt @@ -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 diff --git a/doc/devel/rfc/DelectusShotEvaluator.txt b/doc/devel/rfc/DelectusShotEvaluator.txt index becb61afd..186769f87 100644 --- a/doc/devel/rfc/DelectusShotEvaluator.txt +++ b/doc/devel/rfc/DelectusShotEvaluator.txt @@ -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, diff --git a/doc/devel/rfc/DesignParamAutomation.txt b/doc/devel/rfc/DesignParamAutomation.txt index 9ed2d9b4a..4d1fc201a 100644 --- a/doc/devel/rfc/DesignParamAutomation.txt +++ b/doc/devel/rfc/DesignParamAutomation.txt @@ -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 diff --git a/doc/devel/rfc/DesignRenderNodesInterface.txt b/doc/devel/rfc/DesignRenderNodesInterface.txt index b55402ede..bac8623e3 100644 --- a/doc/devel/rfc/DesignRenderNodesInterface.txt +++ b/doc/devel/rfc/DesignRenderNodesInterface.txt @@ -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) diff --git a/doc/devel/rfc/LumieraDesignProcess.txt b/doc/devel/rfc/LumieraDesignProcess.txt index 1c8331e74..a19afab99 100644 --- a/doc/devel/rfc/LumieraDesignProcess.txt +++ b/doc/devel/rfc/LumieraDesignProcess.txt @@ -35,7 +35,7 @@ planning: Tasks ~~~~~ - * We need to refine link:Lumiera/DesignProcessTemplate[]. + * We need to refine the `Lumiera/DesignProcessTemplate`. Pros ~~~~ diff --git a/doc/devel/rfc/Manifest.txt b/doc/devel/rfc/Manifest.txt index 8d27ceeb3..d90b4a89b 100644 --- a/doc/devel/rfc/Manifest.txt +++ b/doc/devel/rfc/Manifest.txt @@ -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 diff --git a/doc/devel/rfc/MarbleMode.txt b/doc/devel/rfc/MarbleMode.txt index 1a7be25c4..75568dc33 100644 --- a/doc/devel/rfc/MarbleMode.txt +++ b/doc/devel/rfc/MarbleMode.txt @@ -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 diff --git a/doc/devel/rfc/MistakestoAvoid.txt b/doc/devel/rfc/MistakestoAvoid.txt index 4c671b8c8..cf61b8df3 100644 --- a/doc/devel/rfc/MistakestoAvoid.txt +++ b/doc/devel/rfc/MistakestoAvoid.txt @@ -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 diff --git a/doc/devel/rfc/NoBugFlags.txt b/doc/devel/rfc/NoBugFlags.txt index 753ecd452..c2094bae0 100644 --- a/doc/devel/rfc/NoBugFlags.txt +++ b/doc/devel/rfc/NoBugFlags.txt @@ -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); diff --git a/doc/devel/rfc/OfficialAssemblyLanguage.txt b/doc/devel/rfc/OfficialAssemblyLanguage.txt index a60444951..237b9d5ad 100644 --- a/doc/devel/rfc/OfficialAssemblyLanguage.txt +++ b/doc/devel/rfc/OfficialAssemblyLanguage.txt @@ -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 diff --git a/doc/devel/rfc/TagCloudsOnResources.txt b/doc/devel/rfc/TagCloudsOnResources.txt index 2c36d76dc..e3589f15f 100644 --- a/doc/devel/rfc/TagCloudsOnResources.txt +++ b/doc/devel/rfc/TagCloudsOnResources.txt @@ -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) diff --git a/doc/devel/rfc/UnitTests_Python.txt b/doc/devel/rfc/UnitTests_Python.txt index 9d71205e6..27b203893 100644 --- a/doc/devel/rfc/UnitTests_Python.txt +++ b/doc/devel/rfc/UnitTests_Python.txt @@ -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] diff --git a/doc/index.txt b/doc/index.txt index 9bc0f11e6..676804e85 100644 --- a/doc/index.txt +++ b/doc/index.txt @@ -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] diff --git a/doc/technical/build/BuildDependencies.txt b/doc/technical/build/BuildDependencies.txt index 20ca64f97..38dfe9581 100644 --- a/doc/technical/build/BuildDependencies.txt +++ b/doc/technical/build/BuildDependencies.txt @@ -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 diff --git a/doc/technical/build/BuildDroneDraft.txt b/doc/technical/build/BuildDroneDraft.txt index b3da2fddd..84cb38fb0 100644 --- a/doc/technical/build/BuildDroneDraft.txt +++ b/doc/technical/build/BuildDroneDraft.txt @@ -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 <{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 diff --git a/doc/technical/code/LinkingStructure.txt b/doc/technical/code/LinkingStructure.txt index 54e3c8971..c1ab3700a 100644 --- a/doc/technical/code/LinkingStructure.txt +++ b/doc/technical/code/LinkingStructure.txt @@ -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. diff --git a/doc/technical/code/index.txt b/doc/technical/code/index.txt index eaaffa3e4..df26c567c 100644 --- a/doc/technical/code/index.txt +++ b/doc/technical/code/index.txt @@ -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 diff --git a/doc/technical/howto/DebugGdbPretty.txt b/doc/technical/howto/DebugGdbPretty.txt index f26d09315..9f10f5661 100644 --- a/doc/technical/howto/DebugGdbPretty.txt +++ b/doc/technical/howto/DebugGdbPretty.txt @@ -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] diff --git a/doc/technical/howto/UsingBoost.txt b/doc/technical/howto/UsingBoost.txt index 6e68963c8..76a06869b 100644 --- a/doc/technical/howto/UsingBoost.txt +++ b/doc/technical/howto/UsingBoost.txt @@ -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 ---------------- diff --git a/doc/technical/howto/index.txt b/doc/technical/howto/index.txt index 6a32b998f..0f06aaf60 100644 --- a/doc/technical/howto/index.txt +++ b/doc/technical/howto/index.txt @@ -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] diff --git a/doc/technical/index.txt b/doc/technical/index.txt index aa1452023..f3ace95bd 100644 --- a/doc/technical/index.txt +++ b/doc/technical/index.txt @@ -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 diff --git a/doc/technical/infra/debianDepot.txt b/doc/technical/infra/debianDepot.txt index 16a29719e..bd9b2e439 100644 --- a/doc/technical/infra/debianDepot.txt +++ b/doc/technical/infra/debianDepot.txt @@ -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 diff --git a/doc/technical/library/Dependencies.txt b/doc/technical/library/Dependencies.txt index 6379c450e..de5124447 100644 --- a/doc/technical/library/Dependencies.txt +++ b/doc/technical/library/Dependencies.txt @@ -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; diff --git a/doc/technical/library/DiffFramework.txt b/doc/technical/library/DiffFramework.txt index f8502f7fc..c8048f45d 100644 --- a/doc/technical/library/DiffFramework.txt +++ b/doc/technical/library/DiffFramework.txt @@ -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, diff --git a/doc/technical/library/iterator.txt b/doc/technical/library/iterator.txt index 16de43426..e622d3a37 100644 --- a/doc/technical/library/iterator.txt +++ b/doc/technical/library/iterator.txt @@ -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. diff --git a/doc/technical/overview.txt b/doc/technical/overview.txt index b4cee81b9..6649057bf 100644 --- a/doc/technical/overview.txt +++ b/doc/technical/overview.txt @@ -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 diff --git a/doc/technical/stage/style/index.txt b/doc/technical/stage/style/index.txt index 4438d64c2..fb1039eee 100644 --- a/doc/technical/stage/style/index.txt +++ b/doc/technical/stage/style/index.txt @@ -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. diff --git a/doc/technical/steam/index.txt b/doc/technical/steam/index.txt index af5f57e74..56c69524b 100644 --- a/doc/technical/steam/index.txt +++ b/doc/technical/steam/index.txt @@ -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] diff --git a/doc/technical/vault/scheduler.txt b/doc/technical/vault/scheduler.txt index 508cce15e..88bf9e9c0 100644 --- a/doc/technical/vault/scheduler.txt +++ b/doc/technical/vault/scheduler.txt @@ -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 diff --git a/doc/user/intro/intro.txt b/doc/user/intro/intro.txt index 4a8f7e6d3..457d5b701 100755 --- a/doc/user/intro/intro.txt +++ b/doc/user/intro/intro.txt @@ -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. diff --git a/doc/user/tutorials/DebianBuilding.txt b/doc/user/tutorials/DebianBuilding.txt index 9337efb0a..1af8aa542 100644 --- a/doc/user/tutorials/DebianBuilding.txt +++ b/doc/user/tutorials/DebianBuilding.txt @@ -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 diff --git a/doc/user/tutorials/building.txt b/doc/user/tutorials/building.txt index 68acaa3bf..becc7813f 100644 --- a/doc/user/tutorials/building.txt +++ b/doc/user/tutorials/building.txt @@ -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? diff --git a/doc/user/tutorials/contributing.txt b/doc/user/tutorials/contributing.txt index 5391bca0b..a647e7fcf 100644 --- a/doc/user/tutorials/contributing.txt +++ b/doc/user/tutorials/contributing.txt @@ -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] '''' diff --git a/doc/user/tutorials/index.txt b/doc/user/tutorials/index.txt index fd1d6ed59..eddb1bf03 100644 --- a/doc/user/tutorials/index.txt +++ b/doc/user/tutorials/index.txt @@ -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]