VdrAssistant

is "only" a frame or environment for the loadable applications and for so slightly invisible. It offers base functionality like database access, configuration by XML-files, desktop-environment for loadable applications, interface for loadable services, etc.

So the jar-file VdrAssistant is more like a rack than an image - a rack gets its value from the things you put in - so VdrAssistant gets its value by the extensions loaded at runtime.

VdrAssistant is the application startet by the enduser, but the real application is the extension from a subdirectory loaded at runtime.

One of the visible parts of the application frame is the "About"-dialog, which tells some information about the application. This dialog, as well as most of its content is created by the application frame. Each loadable application may tell about itself in a given area and all those areas are displayed in a scrollable box.

Another dialog from the application frame is the settings dialog. There exists settings common to all applications (like database connection parameters) and those unique to each loadable application. So each loadable application may create a dialog-page, which the application frame takes to build a multipage settings dialog.

The common pages are the first (desktop) and the last (services). A doubleclick on a list item opens the preferences dialog for that service. You may change the user, that runs the service or add wrapper scripts for start and stop of the service.

If you change the userid of the service, it may be necessary to change permission of several files and directories on the host, that runs that service.

Further functionality of the application frame is the management of the menuebar entries as well as the exchange of active menuebars (depending on the active window manager, the menuebar changes with the active application), or toolbars. There exists 2 types of toolbars (quickstart actions) - the main toolbar, which is the leftmost horizontal toolbar. The application frame adds common symbols (like Exit, Help, or the like). The other type of toolbar is the extension toolbar. Each application may specify, whether it should be displayed horizontally or vertically.

Last not least there exists a common help browser, that shows up the help-pages provided by all applications.

System services will be added to database at installation time and may not be changed by number. But each serivce has certain parameters, that can be changed. This configuration will be performed using the command center. The changeable parameters include the time, the service will sleep at idle state, the log configuration and the individual service parameters.

If a service does not need parameters, the textbox may stay empty. One service, that is known to require parameters is the Epg-Importer.

New: for each service, two scripts may be defined. A pre-start-script and a post-stop-script. Both scripts may be the same script. The pre-start-script is intended to be used to wake another machine by WOL and mount an exported drive. Therefore a trigger-file may be defined. That triggerfile may be a file from the exported drive, so the successful mount can be validated. If a triggerfile is defined, the service will be started only when the triggerfile exists.

Beside the filenames, two sleeptimes can be defined: the sleeptime before start and the sleeptime after stop. The sleeptime before start is intended to match the boot time of that machine + the time needed to mount the exported drive. The sleeptime after stop is intended to ensure that the service has no more locks on the exported drive, so that it can be unmounted.

See also Services