From 11f04389426d55e773ef2373efb3000dc07c5c79 Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Sat, 10 Dec 2011 01:41:21 +0100 Subject: [PATCH] spelling and some small additions --- doc/technical/code/codingGuidelines.txt | 8 ++++---- doc/technical/overview.txt | 18 ++++++++++++------ 2 files changed, 16 insertions(+), 10 deletions(-) diff --git a/doc/technical/code/codingGuidelines.txt b/doc/technical/code/codingGuidelines.txt index 96be8032e..1a0aeb89e 100644 --- a/doc/technical/code/codingGuidelines.txt +++ b/doc/technical/code/codingGuidelines.txt @@ -35,11 +35,11 @@ The Lumiera project uses GNU indentation style with slight adaptations. * the opening brace of namespaces is placed on the same line. Optionally, the namespace body may be indented, as long as this helps underpinning the nesting structure. But there is no need to use 3 indents on a 3 level nested namespace. One level is enough - to underpin the presence of a nesting. + to highlight the presence of a nesting. Naming conventions ~~~~~~~~~~~~~~~~~~ -Naming conventions are used to underpin the kind of element at hand and give a visual +Naming conventions are used to characterise the kind of element at hand and give a visual clue to the reader. We use our own conventions -- there is no point in arguing that this and that library or language uses other conventions. @@ -81,8 +81,8 @@ General Code Arrangement and Layout doxygen comment explaining the intention and anything not obvious from reading the code. - when arranging headers and compilation units, please take care of the compilation times and the code size. Avoid unnecessary includes. Use forward declarations where applicable. - Yet still, _all really required includes should be mentioned_ (even if already included by another - dependency) + Yet still, _all immediately required includes should be mentioned_ (even if already included by + another dependency) - 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 (no +using namespace boost;+ please!) diff --git a/doc/technical/overview.txt b/doc/technical/overview.txt index d8dbb8904..e6bc30bf0 100644 --- a/doc/technical/overview.txt +++ b/doc/technical/overview.txt @@ -100,14 +100,20 @@ several important parts of the applications are loaded as plug-ins, starting with the GUI. -User Interfaces ---------------- +User Interface(s) +----------------- The purpose of the user interface(s) is to act on the _high-level data model_ contained within the Session, which belongs to the _processing layer_ below. User interfaces are implemented as plug-ins and are pulled up on demand, they won't contain any relevant persistent state beyond presentation. +_As of 2011, the one and only interface under active development is +the Lumiera GTK GUI,_ based on GTK-2 / gtkmm. The sources are in tree +(directory 'src/gui') and it is integrated into the standard build and +installation process. By default, running the 'lumiera' executable will +load and start this GUI as a Lumiera module from 'modules/gtk_gui.lum' + Processing Layer @@ -190,9 +196,9 @@ reopened on demand. Hardlinked files are recognized and opened only once. All file access is done by memory mapping to reduce data copies between userland and kernel. Moreover the kernel becomes responsible to schedule paging (which will be augmented by lumiera) to make the best use of available -resources. Memory is mapped in biggier possibly overlapping windows of -resonable sized chunks. Requests asking for a contingous set of data from the -file in memory. +resources. Memory is mapped in larger windows of reasonable sized chunks, possibly +overlapping each other. Clients may request a specific continuous set of data from +the file to be accessible as memory block. .Indexing @@ -554,7 +560,7 @@ fail. NULL strings are propagated to "" empty strings. Polymorphic Programming in C ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Just a macro for simplyfying vtable function calls +Just a macro for simplifying vtable function calls VCALL(Handle, function, arguments...) translates to Handle->vtable->function (Handle, arguments...)