ARCS/en
Un article de Wiki-evr@.
Version du 20 juillet 2006 à 10:35 (modifier) Gi (Discuter | Contributions) (→Components) ← Différence précédente |
Version du 20 juillet 2006 à 10:37 (modifier) (défaire) Gi (Discuter | Contributions) (→Signal/slots) Différence suivante → |
||
Ligne 22 : | Ligne 22 : | ||
=== Signal/slots === | === Signal/slots === | ||
+ | Our solution is based on the signal/slot communication | ||
+ | model between components. This paradigm, mainly | ||
+ | used in user interfaces API, tends to reach other scopes | ||
+ | of specific programming. Some libraries are implementing | ||
+ | it, for example: QT [http://www.trolltech.com ], | ||
+ | libsigc++ [http://libsigc.sourceforge.net] derived from | ||
+ | GTK+, sigslot [http://sigslot.sourceforge.net] and boost [http://www.boost.org]. Signals represent callbacks | ||
+ | with multiple targets. Signals are connected to some | ||
+ | set of slots, which are callback receivers. They are | ||
+ | triggered when the signal is ”emitted”. Signals and | ||
+ | slots can be connected and disconnected dynamically | ||
+ | at runtime and are managed. That is to say, connections | ||
+ | are tracked by objects owning signals and slots. | ||
+ | They’re able to automatically disconnect signal/slot | ||
+ | connections when one of the object involved in communication | ||
+ | is destroyed. This allows the user to make | ||
+ | signal/slot connections without expending a great effort | ||
+ | to manage the lifetimes of those connections with | ||
+ | regard to the lifetimes of all objects involved. | ||
=== Why programming with components ? === | === Why programming with components ? === |
Version du 20 juillet 2006 à 10:37
ARCS (for Augmented Reality Component System) is a framework dedicated to the design of augmented reality applications. The core of the framework is a general purpose component system cutomized to meet the requirements of augmented reality applications (mostly real-time constraints). A set of components is developped on top of this system for augmented reality applications.
Sommaire |
Basics
Components
According to Szyperski’s definition [Szyperski02], “A component is a coherent package of software that can be independently developed and delivered as a unit, and that offers interfaces by which it can be connected, unchanged, with other components to compose a larger system”.
It means that, the way components will communicate with each other should be described, how they’re implemented, how they’re initialized and how we can use them to build applications.
Before detailing our components, we should introduce the main communication mechanism we use, which is based on the signal/slot paradigm.
Signal/slots
Our solution is based on the signal/slot communication model between components. This paradigm, mainly used in user interfaces API, tends to reach other scopes of specific programming. Some libraries are implementing it, for example: QT [1], libsigc++ [2] derived from GTK+, sigslot [3] and boost [4]. Signals represent callbacks with multiple targets. Signals are connected to some set of slots, which are callback receivers. They are triggered when the signal is ”emitted”. Signals and slots can be connected and disconnected dynamically at runtime and are managed. That is to say, connections are tracked by objects owning signals and slots. They’re able to automatically disconnect signal/slot connections when one of the object involved in communication is destroyed. This allows the user to make signal/slot connections without expending a great effort to manage the lifetimes of those connections with regard to the lifetimes of all objects involved.
Why programming with components ?
The ARCS Core
Components
Compositions of components
The sheet, an explicit composition
Initialisations of components
Other composition mechanism
Extending the sheet capabilities
Publications
J.Y. Didier, S. Otmane, M. Mallem - A Component Model for Augmented/Mixed Reality Applications with Reconfigurable Data-flow