Component Scripting

For each component, you can specify one script that prepares the operations to be performed by the installer. The script format has to be compatible with QJSEngine.

Construction

The script has to contain a Component object that the installer creates when it loads the script. Therefore, the script must contain at least the Component() function, which performs initialization, such as putting pages in the correct places or connecting signals and slots.

The following code snippet places the ErrorPage (which is the class name of the user interface file loaded from errorpage.ui) in front of the ready for installation page and sets its completeness to false.

function Component()
{
    // Add a user interface file called ErrorPage, which should not be complete
    installer.addWizardPage( component, "ErrorPage", QInstaller.ReadyForInstallation );
    component.userInterface( "ErrorPage" ).complete = false;
}

For more information, see the documentation for installer::addWizardPage() and component::userInterface().

Installer Hooks

You can add the following hook methods into your script:

Global Variables

The installer puts the following symbols into the script space:

Message Boxes

You can show a QMessageBox from within the script by using the following static members:

• QMessageBox::critical()
• QMessageBox::information()
• QMessageBox::question()
• QMessageBox::warning()

For your convenience, the values for QMessageBox::StandardButton are made available by using QMessageBox.Ok, QMessageBox.Open, and so on.

Adding Operations to Components

You might want to add custom operations after extracting the content, when copying files or patching file content, for example. You can create and add update operations to the installation from within a script using component::addOperation(). If you need to run an operation that requires administrative rights, use component::addElevatedOperation() instead. Alternative way of adding custom operations is to use component.xml, see Package Directory

Operations need to be added before the actual installation step. Override component::createOperations() to register custom operations for a component.

Each operation has a unique key used for identification and can take up to five parameters. In the parameter values, you can use variables as set in installer::setValue(). For more information, see Predefined Variables.

For a summary of all available operations, see Operations.

Registering Custom Operations

You can register custom installation operations in the installer by deriving the KDUpdater::UpdateOperation class. The following code displays the methods that you must implement:

#include <UpdateOperation>

class CustomOperation : public KDUpdater::UpdateOperation
{
public:
  CustomOperation()
  {
      setName( "CustomOperation" );
      setGroup( Install );
  }

  void backup()
  {
      // do whatever is needed to restore the state in undoOperation()
  }

  bool performOperation()
  {
      const QStringList args = arguments();
      // do whatever is needed to do for the given arguments

      bool success = ...;
      return success;
  }

  void undoOperation()
  {
      // restore the previous state, as saved in backup()
  }

  bool testOperation()
  {
      // currently unused
      return true;
  }

  CustomOperation* clone() const
  {
      return new CustomOperation;
  }

  QDomDocument toXml()
  {
      // automatically adds the operation's arguments and everything set via setValue
      QDomDocument doc = KDUpdater::UpdateOperation::toXml();

      // if you need any information to undo the operation you did,
      // add them to the doc here

      return doc;
  }

  bool fromXml( const QDomDocument& doc )
  {
      // automatically loads the operation's arguments and everything set via setValue
      if( !KDUpdater::UpdateOperation::fromXml( doc ) )
          return false;

      // if you need any information to undo the operation you did,
      // read them from the doc here

      return true;
  }
};

Finally, you need to register your custom operation class, as follows:

#include <UpdateOperationFactory>

KDUpdater::UpdateOperationFactory::instance().registerUpdateOperation< CustomOperation >( "CustomOperation" );

Now you can use your operation in the installer in the same way as the predefined operations.

Predefined Variables

You can use the following predefined variables in scripts to facilitate directory access:

The variables can be resolved by calls to installer::value(). If embedded in '@' they can also be part of strings passed as arguments to installation operations:

if (installer.value("os") === "win") {
    component.addOperation("CreateShortcut", "@TargetDir@/MyApp.exe", "@StartMenuDir@/MyApp.lnk");
}

For example, applications directory on Windows:

Using postLoad in Component Script

By default, component scripts are evaluated before the install tree view is shown. This can have performance cost if there is a huge amount of components with component scripts. The postLoad attribute introduces a way to evaluate the component script right before installation starts, only for the components that are selected for installation or update:

<Script postLoad="true">my_install_script.qs</Script>

Whether postLoad can be set to true must be considered case by case, depending on the contents of the script. For example, if the script contents affect the install tree view, like setting <Default> to true, setting new dependencies, or adding new wizard pages, postLoad must not be used or it must be set to false. If the script contains only methods that are run during the installation, postLoad can be set to true. For example, all overridden operation functions are run during installation. For more information, see Adding Operations to Components. If you are not sure when to use postLoad, then don't use it. The performance cost is huge only when there are thousands of scripts to be evaluated.

Both <Script postLoad="true"> and <Script> tags can be used at the same time. This means that one component can have one script that is evaluated when the installation starts and another script that is evaluated before the install tree view is shown.