Free marie software for linux

MARIE project is a robotic development and integration environment focused on software reusability and exploitation of already available APIs and middlewares frequently used in robotics.
The main purpose of MARIE is to create a rapid-prototyping approach to software development in robotics.
MARIE proposes a development environment, which copes directly with inter-application communications, creating transparency for communications between them and their localization.
Each application interacts with MARIE communication system, instead of the typical application-to-application relation. It proposes a development environment, which helps and supports distributed system creation. We can see it as a toolbox appropriate for creation of robotics system, plus development guidelines and some APIs to support what is specific in applications.
MARIE uses the mediator design pattern for distributed system in order to cope with different applications not sharing the same communication protocol. This mediator design pattern creates a centralized control unit (the mediator) which interacts with each colleague (the applications) independently.
It coordinates global interactions between colleagues in order to realize the desired system. The five principal consequences from this design are: limiting subclassing, decoupling colleagues, simplifying object protocols, abstracting how objects cooperate and centralizing control.
Application Adapters are responsible for sending service requests and communications from the centralized control unit to the applications, and vice versa, using an application proxy. Each application to be integrated must have its own Application Adapter that encapsulates communication mechanism, the services it provides and the specific configurations it needs.
Communication Adapters are responsible for translating information between different communication protocols and mechanisms.
Communication Managers are responsible of creating and managing communication links between Application Adapters that need to be connected together.
Application Managers manage and control the entire system by coordinating system states, achieving coherence and stability, and configuring and controlling of all components available in the system.
Ports & Communication Strategies are responsible of interconnections between MARIEs components. Each components have one or more Ports that are used as tap points where communication links can be established. Each Port can have its own strategy, called Communication Strategy(CS), on how it handles incoming and outgoing data. Typically, CS implements or is based on a known protocol, such as TCP, UDP or IPC, but it can be any other strategies as well (shared memory, files, direct function calls, ...). Decoupling Communication Strategy from Port functionnalities opens the possibility to choose which protocol is used for each Port without having to modify code related to Ports/components functionnalities.
Enhancements:
- Lots of changes were made in this release.
- A build system based on Scons is used.
- Component creation was simplified.
- User-defined plugins were added for CFB, CS, and Data Factory (SerDes).
- Project file description is used instead of start scripts.
- Socket port number is now automatically managed.
- A new console and GUI Application Manager were added.
- A toolbox for RobotFlow was added.
- Unit tests were introduced.
- New documentation was written.
- A new wiki-based Web site used.
- Code bugs and issues were corrected.

Kard is a Memory-like game for young children. It allows very young children to start using a mouse.
Click on two cards, remember their picture or color and match the same cards in pairs.
Main features:
- set the number of cards to 4, 8, 12, 16, 20 or 24
- 6 card themes: color, house objects, geometrical opposites, animals food and syllables
- set the timer to slow (2 seconds), medium (1 second) or quick (0.5 second). The timer sets the time to display the cards.
- Full Screen mode
Aim:
- use of the mouse for very young children
- memory trainer and shape/letter recognition
- help in memorizing global words associated with pictures
Enhancements:
- new themes: animals and food.

OpenOffice::OODoc::Image is a Perl module for image manipulation methods.

The OpenOffice::OODoc::Image class is a derivative of OpenOffice::OODoc::XPath designed for the manipulation of graphics objects contained in documents. It mainly allows you to modify the size and position of an image and exchange its content outside the document.

This class should not be explictly used in an ordinary application, because all its features are available in the OpenOffice::OODoc::Document class, in combination with other features. So, each time an application needs to get an image-focused access to a document, it should use the general ooDocument() constructor instead of the ooImage() one.

Practically, the present manual is provided to describe the image-container processing features of OpenOffice::OODoc::Document (knowing that these features are technically supported by the OpenOffice::OODoc::Image component of the API).

Knowing that an image is displayed or printed according to a style, the OpenOffice::OODoc::Image features should be used in conjunction with the OpenOffice::OODoc::Styles ones. The OpenOffice::OODoc::Document class allows the user to invoke text-, style- and image-focused methods from the same object.

All the methods described here can equally be used with images contained in style sheets (headers, footers) as with images contained in the body of a document. It can therefore be associated just as well with a "styles.xml" member as with a "content.xml" member of an OpenOffice.org file.

This class works with all types of document (text, presentation, etc.).

For all methods where the first argument is given below as "image", it is (unless otherwise stated) either the name of an image as it appears to the end user when editing its properties in OpenOffice.org or StarOffice or the images element reference obtained previously by the program. All these methods fail and return a null value (or in some cases produce an error message) if the argument does not correspond to a known image contained in the document.

Note: This module is not an image-processing tool. It can insert or remove images, and control the way the images are displayed in the documents. But it cant process the images themselves.

Kalcul project is a math game for children aged 8 to 15.
It has 4 levels of difficulty and the user can choose between variants that teach addition, substraction, multiplication, or division.
Enhancements:
- fixed some bugs and polished interface

OpenOffice::OODoc is The Perl Open OpenDocument Connector.

SYNOPSIS

use OpenOffice::OODoc;

# get global access to the content of an OOo file
my $document = ooDocument(file => "MyFile.odt");
# select a text element containing a given string
my $place = $document->selectElementByContent("my search string");
# insert a new text element before the selected one
my $newparagraph = $document->insertParagraph
(
$place,
position => before,
text => A new paragraph to be inserted,
style => Text body
);
# define a new graphic style, to display images
# with 20% extra luminance and color inversion
$document->createImageStyle
(
"NewImageStyle",
properties =>
{
draw:luminance => 20%,
draw:color-inversion => true
}
);
# import an image from an external file, attach it
# to the newly inserted paragraph, to be displayed
# using the newly created style
$document->createImageElement
(
"Image1",
style => "NewImageStyle",
attachment => $newparagraph,
import => "D:ImagesLandscape.jpg"
);
# save the modified document
$document->save;

This toolbox is an extensible Perl interface allowing direct read/write operations on OASIS OpenDocument Format (ISO/IEC 26300) or OpenOffice.org files.

It provides a high-level, document-oriented language, and isolates the programmer from the details of the file format. It can process different document classes (texts, spreadsheets, presentations, and drawings). It can retrieve or update styles and images, document metadata, as well as text content.

OpenOffice::OODoc is designed for data retrieval and update in existing documents, as well as full document generation.

See the OpenOffice::OODoc::Intro manual page to have a look at the main features.

OpenOffice::OODoc::Text is a Perl module for the text processing submodule of OpenOffice::OODoc.

This manual chapter describes the text-oriented methods of OpenOffice::OODoc, implemented by the OpenOffice::OODoc::Text class, and inherited by the OpenOffice::OODoc::Document class.

These methods are not essentially dedicated to string processing; they are more precisely focused on text containers. A text container is a document element which can (and must) be used in order to support a text and integrate it at the right place and according to the right presentation rules. The OpenDocument specification defines a lot of such containers, and the present API supports many of them, such as paragraphs, headings, tables (or spreadsheets), lists, sections, and draw pages. Some of these containers can host other containers: for example, a table contains rows, a row contains cells, a section can contain almost everything including other sections, etc.

These features are text-oriented, but can be used on documents of any class, such as spreadsheets or presentations as well as text documents. So, the Text word doesnt mean that the features described in the present manual chapter are dedicated to OpenOffice.org Writer documents only. In the other hand, a few methods cant apply to any document class (ex: creating or retrieving draw pages makes sense with presentation and drawing documents only).

OODoc::Text should not be explicitly used in an ordinary application, because all its features are available through the OpenOffice::OODoc::Document class, in combination with other features. Practically, the present manual is provided to describe the text-oriented features of OpenOffice::OODoc::Document (knowing that these features are technically supported by the OpenOffice::OODoc::Text component of the API).

The OpenOffice::OODoc::Text class is a specialist derivative of OpenOffice::OODoc::XPath for XML elements which describe the text content of OOo/ODF documents. Here, "text content" means containers that can host text containers (i.e. tables, lists...) as well as flat text.
Knowing that the "styles.xml" member of an OpenOffice.org file can contain text (because some style definitions, such as page headers or footers, can contain text), the presently described features can be used against this member as well as the "content.xml" member.

This module should be used in combination with OpenOffice::OODoc::Styles, via the OpenOffice::OODoc::Document class, if the application has to handle detailed presentation parameters of text elements. This is because such parameters are held in styles elements and not in the text elements themselves, according to the principle of separation of content and presentation which is one of the foundations of the OpenDocument format.

OpenOffice::OODoc::XPath is a Low-level XML navigation in the documents.

This module is a low-level class which uses OODoc::File (without inheriting anything from it) along with the classes defined in the XML::Twig module. Its a common basis for the other, more user- friendly, document-oriented modules. It uses XPath expressions in order to retrieve any document element (but it doesnt provide a full implementation of the XPath standard). In addition, while the most part of the provided methods are OpenDocument-aware, this module could be used against any other kind of XML documents, simply because it benefits from all the features of XML::Twig. Such a possibility may prove useful for applications that simultaneously process OpenDocument and non-OpenDocument XML files.

The OpenOffice::OODoc::XPath class should not be explicitly used in the applications, because all its features are available in more user-friendly classes such as OODoc::Text, OODoc::Styles, OODoc::Image, OODoc::Document and OODoc::Meta. The present manual page is provided to describe the common methods and properties that are available with all these classes.

This chapter can be skipped by programmers who are only interested in upper level methods provided by the OODoc::Text, ::Styles, ::Image and ::Meta modules. Understanding these modules is easier and using them requires less Perl and XML expertise. However, calling OODoc::XPath methods remains a good rescue option as it allows all kinds of operations on all types of XML elements contained in any OpenDocument-compliant file.

OODoc::XPath is the common foundation of OODoc::Meta, OODoc::Text, OODoc::Styles and OODoc::Image. It contains the lowest layer of navigation services for XML documents and handles the link with OODoc::File for file access. Its primary role is as an interface with the XML::Twig API.

In the present manual chapter, you will see "elements" often mentioned. When it says that a module expects a parameter or returns an element (either singly or as a list), it is referring to an XML element. It is important to distinguish elements from their content (elements being simply references to XML data structures). To read or modify the content of an element such as its text or XML attributes, use the accessors also available within OODoc::XPath.
In most cases where XPath methods require a reference to an element as an argument, there are two ways of proceeding:

- reference the element directly (obtained previously)
- or give an XPath expression and a position, being a string and an integer respectively; for example, the pair (//office:body/text:p, 12) or (//text:p, 12) represents the thirteenth occurrence of the text:p element, i.e. the 13th paragraph (occurrences are numbered starting from 0).

The second way requires the knowledge of an appropriate XPath expression (according the OOo/OpenDocument XML format specification). And a given XPath expression is not necessarily the same with an OpenDocument as in an OpenOffice.org document. So you should preferently use high level accessors (provided by derivative classes such as OODoc::Document) and avoid XPath hardcoding. However, you know you can at any time reach any element with XPath.

Of course, you will never need to use XPath expressions in order to reach the most common text elements (such as paragraphs), because the OODoc::Text module provides more friendly accessors (for example, you will probably use the getParagraph() method and forget "//text:p").
Some methods accept both forms which means that if the first parameter is recognised as an element reference, the position does not need to be given. Therefore the number of arguments for certain OODoc::XPath methods can vary.

For those who really want to access all areas there are also OODoc::XPath methods which allow unrestricted access to every element or XML attribute via an access path in XPath syntax. If you are into this kind of thing, we recommend you obtain good syntax reference manuals for XPath and OpenOffice.org and a supply of aspirin.

Methods which may return several lines of text (e.g. getTextList) do so either in the form of an unique character string containing "n" separators or in table form.

Unless otherwise stated, the word document in this chapter only refers to XML documents contained within OODoc::XPath objects and not, say, OpenOffice.org files (as an end user would use).

Amongst the different methods which return elements, attributes or text, some are called getXxx, others selectXxx or findXxx. Read methods whose names start with "get" generally refer to an unfiltered object or list, whereas others return an object or list filtered according to a parameter value. In this latter case the search parameter is treated as a standard expression and not an exact value. This means that if the search criteria is "xyz", all text containing "xyz" will be considered a match. To restrict the search to text exactly equal to "xyz", use "^xyz$" as the search criteria (following Perl regular expression syntax).

Several methods allow you to place copies of or references to elements (from other documents or from other positions in the same document) in any position in the current document. This offers powerful manoeuvrability but only if these placements conform with the destination positions context.

For example, you can easily copy a paragraph from one document to another but only if you knowingly modify the paragraphs style attribute if that style is not already defined in the destination document. You can also copy the style but only if you are sure that this style is not already defined by another unknown style in the destination document (and so on).

For advanced users familiar with the XML::Twig API, it might be interesting to know that all the objects called "elements" in the following chapters are objects of the

OpenOffice::OODoc::Element class, which is an XML::Twig::Elt derivative. So all methods associated with this class are directly applicable to these elements, on top of the functionality described in this manual. However, the knowledge of XML::Twig is not mandatory.

Important note: The applications should not explicitly work with this class. We recommend using OODoc::Meta and OODoc::Document (which are both OODoc::XPath derivatives). These two objects provide highest-level methods which are neater and more productive. Explicit use of OODoc::XPath methods (which sometimes require large numbers of parameters) should only be considered as a last resort in unexpected circumstances for access to any element or XML attribute not handled by more friendly methods. However, the present manual chapter could prove helpful because all the common features of OODoc::Meta and OODoc::Document are described here.