ichthyo/LUMIERA.clone
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

spelling and some small additions

Browse source
This commit is contained in:
Fischlurch 2011-12-10 01:41:21 +01:00
parent 8e45412513
commit 11f0438942
2 changed files with 16 additions and 10 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

8
doc/technical/code/codingGuidelines.txt
View file

@ -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!)

18
doc/technical/overview.txt
View file

@ -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...)