An application is something that runs as separate process - the 'executables' are in the ccp4i2/bin directory. They are often a shell script that sets up the Python environment and then calls a Python script.
| ccp4 | The main ccp4i2 gui | Uses ccp4 (shell) and browser.py |
| runTask | The non-graphical app to run one task as separate process | |
| pyi2 | A Python command line interface with ccp4i2 libraries loaded | |
| testi2sys | Runs the test suite | |
| defEd | Graphical tool for creating/editing the xml def files | |
| listProcesses | Used on remote servers to create list of processes to return to ccp4i2 gui | |
| ccp4-update | Run ccp4 update from ccp4i2 |
ccp4i2/utils/startup.py contains functions to bootstrap i2 and these are called in browser.py.Applications that use Qt must also create a Qt QApplication (see Qt docs) - there is a i2 CApplication subclass in utils/QApp.py that loads any Qt plugins.
The default config file for graphical i2 is local_setup/ccp4i2_config.params.xml - when user first runs i2 a copy is made to there .CCP4I2/configs directory and any changes in this will override the default.
There is presently no gui to edit configuration - this may become necessary particularly if i2 supports alternative database formats.
The config file is handled by core/CCP4Config.py - where the CONFIG() function returns the single instance of CConfig. There are also functions to access the config parameters. The parameters in the config are:
| developer | DEVELOPER() | True if user is a developer - some extra functionality shown and less error trapping at key points in code |
| version | VERSION() | The ccp4i2 version taken from core/version.params.xml |
| graphical | GRAPHICAL() | True for main gui but harwired false in core/runTask.py so will skip loading graphical modules that may crash on servers without graphical support |
| qt | QT() | If false attempt to make core data objects not Qt-dependent - that option not tested for years. |
| xmlParser | XMLPARSER() | Attempt to make xml parser flexible - lxml is now hardcoded in many places |
| dbMode | DBMODE() | Choice of sql mechanism - currently sqlite |
| dbFile | DBFILE() | Database file |
| dbUser | DBUSER() | Name of user recognised by the database |
A lot of key core functionality is in classes that we expect to have only one instance. Functions in core/CCP4Modules.py will either create or return the existing instance of the class. These functions are:
| QTAPPLICATION() | utils.QApp.py | The Qt QApplication object |
| PREFERENCES() | CCP4Preferences.CPreferences | The users preferences (as edited through Preferences window) |
| TASKMANAGER() | CCP4TaskManager.CTaskManager | Manage the tasks/wrappers/pipelines code from wrappers and pipelines directories |
| CCP4DataManager.DATAMANAGER() | CCP4DataManager.CDataManager | Manage the data classes in core: CCP4Data.py,CCP4ModelData.py,CPP4XtalData.py etc. |
| PROCESSMANAGER() | CCP4ProcessManager.CProcessManager | Manages non-graphical child processes |
| LAUNCHER() | CCP4Launcher.CLauncher | Manages interactive child processes |
| JOBCONTROLLER() | CCP4JobController.CJobController | Manages running jobs (uses PROCESSMANAGER()) |
| PROJECTSMANAGER() | CCP4ProjectsManager.CProjectsManager | Wide range of functionality applied to projects |
| PROJECTSMANAGER().db() | CCP4DbApi.CDbApi | The database api |
| WEBBROWSER(!!!) | CCP4WebBrowser.CWebBrowser | Opens browser. This function has arguments and there may be more than one browser window. |
| MIMETYPESHANDLER() | CCP4CustomMimeTypes.CCustomMimeTypes | Mime types to support Qt file display |
| PRINTHANDLER() | CCP4PrintHandler.CPrintHandler | Intercepts stdour & stderr |
| PIXMAPMANAGER() | CCP4Widgets.CPixmapManager | Return images from qticons directory as QPixmap |
| FILEWATCHER() | CCP4AbstractViewer.CFileWatchTimer | A sub-class of QFileWatcher used to watch file system |
| HTTPSERVER() | CCP4HTTPServerThread.CHTTPServerThread | Thread which acts as http server (especially for reports) |
| DBSERVER() | CCP4DbThread.CDbThread | Database thread used in HTTPSERVER |
| DEMODATAMANAGER() | CCP4DemoData.CDemoData | Handle demo data as presented in Utilities menu |
| JOBCONTROLLERGUI() | CCP4JobControlGui.CServerParamsDialog | Gui for running remote jobs |
| SERVERSETUP() | CCP4JobController.CServerSetup | Used in running remote jobs |
A users preferences are saved in $HOME/.CCP4I2/configs/guipreferences.params.xml. The preferences are defined by the same mechanism as tasks with gui and the initial def file in wrappers2/guipreferences. CCP4Preferences.CPreferences (acessed via CCP4Modelus.PREFERENCES()) is a sub-class of a CContainer that holds the preferences. Note that this emits a 'preferencesSaved' signal when preferences are changed.
task-managerNew tasks can be added to i2 by adding appropriate code to the wrappers or pipelines directory. On startup CTaskManager.buildLookup() uses Python introspection tools to create a list of all tasks in these directories using the TASKNAME parameter in each file to link together scripts, guis and reports. The TASKMODULE parameter says where the task should appear in the menu. There is also a TASKVERSION parameter which might be needed to allow multiple simultaneous versions but this is not seriously tested. The class contains numerous 'getters' which usually have the taskName as argument. The taskTree() method returns a tree of module and tasknames to appear in the task menu.
A listing of task info can be accessed by Utilities->Developer tools->List tasks
See dev docs for overview of data classes and containers.
Accessed via CCP4DataManager.DATAMANAGER() function. Works similar to the Task manager - at instantiation CDataManager.buildClassLookup() searches all files in core directory for classes that sub-class CCP4Data.CData and all files in the qtgui directory for classes that sub-class CCP4Widgets.CViewWidget. Note that if the configure option GRAPHICAL() is False then it will not attempt to load the qtgui code since this will, via loading Qt, attempt to load system graphical libraries which potentially do not exist on 'headless' servers.
When i2 'opens' a task, either for a task input gui or within a script it creates a CContainer object and populates it with the data objects specified in the task 'def.xml' file. For each parameter in the def.xml file there is a name and, at least, a text string classname. CDataManager.getClass() will return a reference to the appropriate data class for an given classname.
CViewWidget classes have a MODEL_CLASS parameter which is a reference to the model class for which it provides a view. Many data classes do not have their own view class but use one from a super-class. When generating task input guis CDataManager.getWidgetClass() is used to find the most appropriate view class for any input model class.
CDataManager.makeHtmlClassListing() will autogenerate documentation for the data classes and by default place in docs/developers/modules. This function should be run from the pyi2 interface.