mainpage.doxygen   mainpage.doxygen 
skipping to change at line 41 skipping to change at line 41
The code of Stellarium is split into several main blocks: The code of Stellarium is split into several main blocks:
<ul> <ul>
<li>the main loop and main widget classes StelMainWindow, StelMainGraphicsV iew and StelAppGraphicsScene. Those classes have a single instance which is created at startup by the the ::main() function. They perform various task s such as the creation of the main program window and openGL context, the c reation of the stellarium core, the creation of the GUI. After initializati on, they manage user's input event propagation and event loop. There are he avily based on Qt features.</li> <li>the main loop and main widget classes StelMainWindow, StelMainGraphicsV iew and StelAppGraphicsScene. Those classes have a single instance which is created at startup by the the ::main() function. They perform various task s such as the creation of the main program window and openGL context, the c reation of the stellarium core, the creation of the GUI. After initializati on, they manage user's input event propagation and event loop. There are he avily based on Qt features.</li>
<li>the core which provides a number of generic services and features to th e other components. The main class is the StelApp singleton class which is used everywhere in the code to access other elements. It is the StelApp ins tance which creates all the main core services and modules at initializatio n. Example services are OpenGL textures management with the StelTextureMgr, font management with the StelFontMgr, sky images management (images which have a fixed position in the sky) with the StelSkyImageMgr etc.. Two especi ally important manager classes (the ones with the "Mgr" suffix) are the Ste lModuleMgr and StelCore classes: the first one manages the collection of St elModule instances which are registered in the program (see next point for more info on what a StelModule is). The second one provides performance cri tical features for rendering various elements using openGL, or for computin g coordinate transformation and other mathematical services.</li> <li>the core which provides a number of generic services and features to th e other components. The main class is the StelApp singleton class which is used everywhere in the code to access other elements. It is the StelApp ins tance which creates all the main core services and modules at initializatio n. Example services are OpenGL textures management with the StelTextureMgr, font management with the StelFontMgr, sky images management (images which have a fixed position in the sky) with the StelSkyImageMgr etc.. Two especi ally important manager classes (the ones with the "Mgr" suffix) are the Ste lModuleMgr and StelCore classes: the first one manages the collection of St elModule instances which are registered in the program (see next point for more info on what a StelModule is). The second one provides performance cri tical features for rendering various elements using openGL, or for computin g coordinate transformation and other mathematical services.</li>
<li>a collection of StelModule instances which display the main elements of the program such as planets and stars. Each StelModule should be registere d to the StelModuleMgr. Because many components of Stellarium derive from t he StelModule class, it is possible for the main loop to treat them generic ally by calling their standard methods such StelModule::update() and StelMo dule::draw() at each program iteration. It also allows other program compon ents to access them by name. StelModule can also be loaded dynamically by S tellarium, which is the standard way of creating @ref plugins.</li> <li>a collection of StelModule instances which display the main elements of the program such as planets and stars. Each StelModule should be registere d to the StelModuleMgr. Because many components of Stellarium derive from t he StelModule class, it is possible for the main loop to treat them generic ally by calling their standard methods such StelModule::update() and StelMo dule::draw() at each program iteration. It also allows other program compon ents to access them by name. StelModule can also be loaded dynamically by S tellarium, which is the standard way of creating @ref plugins.</li>
<li>the Graphical User Interface (StelGui). It is based on styled Qt widget s which are rendered directly in the openGL window. Users actions trigger s ignals which are connected to core and StelModules slots.</li> <li>the Graphical User Interface (StelGui). It is based on styled Qt widget s which are rendered directly in the openGL window. Users actions trigger s ignals which are connected to core and StelModules slots.</li>
<li>the script engine (StelScriptMgr) allows scripts to calls slots from th e core and StelModules slots.</li> <li>the script engine (StelScriptMgr) allows scripts to calls slots from th e core and StelModules slots.</li>
</ul> </ul>
@image html stellarium-architecture.png @image html stellarium-architecture.png
@section intro_scripts Scripting API
Stellarium uses the <a href="http://doc.trolltech.com/4.3/qtscript.html">QT
Scripting Engine</a>. The basic scripting language is
<a href="http://en.wikipedia.org/wiki/ECMAScript">ECMAScript</a>, which is
related to Javascript.
Authors of Stellarium scripts may use application specific functions from t
he following places:
- The public slots in the class StelMainScriptAPI. These are available in
the scripting engine via the
object named "core". For example, to access StelMainScriptAPI::wait() fr
om a script, the author would
use the scripting command: core.wait(...);
- The public slots for each StelModule are available in the scripting engin
e via an object with the
same name as the corresponding StelModule. For example, to access Landsc
apeMgr::setFlagAtmosphere(),
a script author would use the scripting command: LandscapeMgr.setFlagAtmo
sphere(...);
@image html stellarium-logo.png @image html stellarium-logo.png
*/ */
 End of changes. 1 change blocks. 
23 lines changed or deleted 0 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/