Return-Path: X-Original-To: apmail-incubator-ooo-commits-archive@minotaur.apache.org Delivered-To: apmail-incubator-ooo-commits-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id C12977B77 for ; Fri, 25 Nov 2011 23:40:31 +0000 (UTC) Received: (qmail 13330 invoked by uid 500); 25 Nov 2011 23:40:31 -0000 Delivered-To: apmail-incubator-ooo-commits-archive@incubator.apache.org Received: (qmail 13302 invoked by uid 500); 25 Nov 2011 23:40:31 -0000 Mailing-List: contact ooo-commits-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: ooo-dev@incubator.apache.org Delivered-To: mailing list ooo-commits@incubator.apache.org Received: (qmail 13295 invoked by uid 99); 25 Nov 2011 23:40:31 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 25 Nov 2011 23:40:31 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=5.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.4] (HELO eris.apache.org) (140.211.11.4) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 25 Nov 2011 23:40:20 +0000 Received: from eris.apache.org (localhost [127.0.0.1]) by eris.apache.org (Postfix) with ESMTP id 4546B23889BB; Fri, 25 Nov 2011 23:39:57 +0000 (UTC) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: svn commit: r1206376 [1/2] - /incubator/ooo/ooo-site/trunk/content/installation/pics/ Date: Fri, 25 Nov 2011 23:39:54 -0000 To: ooo-commits@incubator.apache.org From: kschenk@apache.org X-Mailer: svnmailer-1.0.8-patched Message-Id: <20111125233957.4546B23889BB@eris.apache.org> X-Virus-Checked: Checked by ClamAV on apache.org Author: kschenk Date: Fri Nov 25 23:39:52 2011 New Revision: 1206376 URL: http://svn.apache.org/viewvc?rev=1206376&view=rev Log: kls -- updating installation/pics Added: incubator/ooo/ooo-site/trunk/content/installation/pics/ incubator/ooo/ooo-site/trunk/content/installation/pics/automatical_assignments.html (with props) incubator/ooo/ooo-site/trunk/content/installation/pics/how_to_create_native_installer.gif (with props) incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_directory.html (with props) incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_file.html (with props) incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_folder.html (with props) incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_folderitem.html (with props) incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_installation.html (with props) incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_mergemodule.html (with props) incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_module.html (with props) incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_profile.html (with props) incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_profileitem.html (with props) incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_registryitem.html (with props) incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_scpaction.html (with props) incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_shortcut.html (with props) incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_templatemodule.html (with props) incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_unixlink.html (with props) incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_windowscustomaction.html (with props) incubator/ooo/ooo-site/trunk/content/installation/pics/undefining_gids.html (with props) incubator/ooo/ooo-site/trunk/content/installation/pics/understanding_the_lng_files.html (with props) incubator/ooo/ooo-site/trunk/content/installation/pics/understanding_the_patch_flag.html (with props) incubator/ooo/ooo-site/trunk/content/installation/pics/understanding_the_scipt_elements.html (with props) incubator/ooo/ooo-site/trunk/content/installation/pics/understanding_the_scipt_language.html (with props) incubator/ooo/ooo-site/trunk/content/installation/pics/understanding_the_scp_project.html (with props) Added: incubator/ooo/ooo-site/trunk/content/installation/pics/automatical_assignments.html URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/installation/pics/automatical_assignments.html?rev=1206376&view=auto ============================================================================== --- incubator/ooo/ooo-site/trunk/content/installation/pics/automatical_assignments.html (added) +++ incubator/ooo/ooo-site/trunk/content/installation/pics/automatical_assignments.html Fri Nov 25 23:39:52 2011 @@ -0,0 +1,56 @@ + + + + + + + + + + + +

Automatical +assignments of global IDs to modules

+



+

+

The scp linker automatically +optimizes the setup script to reduce the efforts needed in scp files:

+
    +

  • Global IDs that are not + assigned to a module, are automatically assigned to the root module. + +

    +

  • Global IDs that are + assigned to modules, but are not defined, are automatically removed + from modules.

    +
+

This is only relevant for +Directories, Files, Customs and Procedures, because all other items +do not belong to modules (Installation, HelpText, ...) or have to +contain a ModuleID in their definition block (ProfileItem, +RegistryItem, ...) .

+

Example: +

+

If you only define a file and do +not include it into the list ( Files = ( ... ); ) of a module, the +file is automatically added to the root module. Therefore you only +have to edit one scp file. +

+

The second case is not less +important. If you define in a module definition a file list like

+

Files = (gid_File_Only_Windows, +gid_File_Only_Linux, gid_File_Only_Solaris);

+

you do not need to write any +platform dependencies inside this definition (take care of the +filenames ;-) )

+

If you build a Windows script, in +which the definitions of gid_File_Only_Linux and +gid_File_Only_Solaris do not occur, you do not have to take care of +the module assignments. The scplinker automatically removes these two +assignments and writes

+

Files = (gid_File_Only_Windows);

+

into the setup script in the +installation set. +

+ + \ No newline at end of file Propchange: incubator/ooo/ooo-site/trunk/content/installation/pics/automatical_assignments.html ------------------------------------------------------------------------------ svn:eol-style = native Added: incubator/ooo/ooo-site/trunk/content/installation/pics/how_to_create_native_installer.gif URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/installation/pics/how_to_create_native_installer.gif?rev=1206376&view=auto ============================================================================== Binary file - no diff available. Propchange: incubator/ooo/ooo-site/trunk/content/installation/pics/how_to_create_native_installer.gif ------------------------------------------------------------------------------ svn:mime-type = image/gif Added: incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_directory.html URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_directory.html?rev=1206376&view=auto ============================================================================== --- incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_directory.html (added) +++ incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_directory.html Fri Nov 25 23:39:52 2011 @@ -0,0 +1,81 @@ + + + + + + + + + + + +

Definition +of a Directory +

+



+

+

The +keyword for a directory definition is Directory. A global ID +of a directory should begin with gid_Dir . Directories have to +be assigned to modules in the definition block of the module. If a +directory is not assigned to any module, it is automatically assigned +to the root module by the scplinker. A typical definition of a +directory in the scp projects looks like:

+

Directory +gid_Dir_Autotext
ParentID = gid_Dir_Share;
DosName = +"autotext";
End

+

Directory +gid_Dir_Share_Autocorr
ParentID = gid_Dir_Share;
DosName = +"autocorr";
Styles = (CREATE);
End

+

As +you can see, the definition of a directory is very simple. A +directory has a name (DosName) and a parent. Every directory has a +parent, resulting in a directory tree. For the most directories, the +ParentID is a global ID, which is defined in the script before. Some +directories of course have to be defined by the setup. The most +important is the directory:

+

PREDEFINED_PROGDIR + +

+

which +is for example used in the definition:

+

Directory +gid_Dir_Program
ParentID = PREDEFINED_PROGDIR;
DosName = +"program";
End

+

The +directory program is created below the Office installation root. And +this is described by the PREDEFINED_PROGDIR, which has to be found by +the setup. By the way, the PREDEFINED_PROGDIR is defined by the user, +during the installation process. +

+

Further +predefined directories are:

+

PREDEFINED_HOMEDIR +: The user's home directory

+

PREDEFINED_CONFIGDIR: +The system's configuration directory

+

PREDEFINED_OSSHELLNEWDIR: +The shellnew directory for Windows

+

PREDEFINED_OSSYSTEMFONTDIR: +The system font directory

+



+

+

A +directory is created, if it is necessary to create it. This means: +For example we take a file gid_File_A, that belongs to gid_Module_B, +and has to be installed into directory gid_Dir_C. If the module is +selected in the user defined installation, the file has to be +installed. Then it is necessary for the setup, to create the +directory gid_Dir_C. If the module is not selected, the file has not +to be installed and, if there is no other file in gid_Dir_C, this +gid_Dir_C must no be created. +

+

Some +directories have to be created empty. As in the example above the +directory gid_Dir_Share_Autocorr has the flag CREATE. This +flag means, that the directory shall be created, even though there is +no file in it.

+



+

+ + \ No newline at end of file Propchange: incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_directory.html ------------------------------------------------------------------------------ svn:eol-style = native Added: incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_file.html URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_file.html?rev=1206376&view=auto ============================================================================== --- incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_file.html (added) +++ incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_file.html Fri Nov 25 23:39:52 2011 @@ -0,0 +1,156 @@ + + + + + + + + + + + +

Definition +of a File +

+



+

+

The +keyword for a file definition is File. A global ID of a file +should begin with gid_File_ . Files have to be assigned to +modules in the definition block of the module. If a file is not +assigned to any module, it is automatically assigned to the root +module by the scplinker. A typical definition of a file in the scp +projects looks like:

+

File +gid_File_Lib_Dbp
BIN_FILE_BODY;
Name = LIBNAME(dbp);
Dir = +gid_Dir_Program;
Styles = (PACKED, UNO_COMPONENT);
RegistryID = +gid_Starregistry_Applicat_Rdb;
End

+

This +definition describes the library dbp. The macro LIBNAME is defined in +the included file macros.inc. You find there some very important +macro definitions:

+

#ifdef +UNX
#define LIBNAME(name) +STRING(CONCAT5(lib,name,OFFICEUPD,DLLSUFFIX,.so))
#define +LIBSHORTNAME(name) STRING(CONCAT4(lib,name,DLLSUFFIX,.so))
#define +LIBVERYSHORTNAME(name) STRING(CONCAT3(lib,name,.so))
#define +FILTER_LIBNAME(name) LIBNAME(name)
#define EXENAME(name) +STRING(name)
#define PROFILENAME(name) +STRING(CONCAT2(name,rc))
#else
#define LIBNAME(name) +STRING(CONCAT4(name,OFFICEUPD,DLLSUFFIX,.dll))
#define +LIBSHORTNAME(name) STRING(CONCAT3(name,DLLSUFFIX,.dll))
#define +LIBVERYSHORTNAME(name) STRING(CONCAT2(name,.dll))
#define +FILTER_LIBNAME(name) LIBNAME(name)
#define EXENAME(name) +STRING(CONCAT2(name,.exe))
#define PROFILENAME(name) +STRING(CONCAT2(name,.ini))
#endif

+

You +can see, that for many different kinds of names exist different +macros. LIBNAME(dbp) will be expanded for Solaris-Sparc in a +src641 to libdbp641ss.so, but for Windows to dbp641mi.dll. +If there is a language dependent name, like for resource files, there +are other macro definitions: +

+

File +gid_File_Res_Dba
TXT_FILE_BODY;
RESFILE_ALL_LANG(dba);
Dir = +gid_Dir_Resource;
Styles = (PACKED);

+

End

+

RESFILE_ALL_LANG +is also defined in macros.inc. You find there:

+

#define +RESFILE_ALL_LANG(name) \
Name (01) = RESFILENAME(name,01); \
Name +(03) = RESFILENAME(name,03); \
Name (07) = RESFILENAME(name,07); +\
Name (30) = RESFILENAME(name,30); \
Name (31) = +RESFILENAME(name,31); \
Name (33) = RESFILENAME(name,33); \
Name +(34) = RESFILENAME(name,34); \
Name (35) = RESFILENAME(name,35); +\
Name (37) = RESFILENAME(name,37); \
Name (39) = +RESFILENAME(name,39); \
Name (45) = RESFILENAME(name,45); \
Name +(46) = RESFILENAME(name,46); \
Name (48) = RESFILENAME(name,48); +\
Name (49) = RESFILENAME(name,49); \
Name (81) = +RESFILENAME(name,81); \
Name (82) = RESFILENAME(name,82); \
Name +(86) = RESFILENAME(name,86); \
Name (88) = RESFILENAME(name,88); +\
Name (90) = RESFILENAME(name,90); \
Name (96) = +RESFILENAME(name,96); \
Name (99) = RESFILENAME(name,99)

+

and +also RESFILENAME is a macro defined in macros.inc:

+

#define +RESFILENAME(name,lang) STRING(CONCAT4(name,OFFICEUPD,lang,.res))

+

At +the moment there are many macros for different file names, that is +would be too much, to desribe here. Take a look into the macros.inc +file, and you will find the macro you need. +

+

Back +to the definition of File gid_File_Lib_Dbp. Another entry in the +definition block defines the directory. In this case the library +shall be intalled into gid_Dir_Program. As you can see, this is also +a global ID, which has to be defined in the script before the +definition of this file. You see, everything in the setup script is +defined in these definition blocks. +

+

The +next two lines in the definition of gid_File_Lib_Dbp are important +for registering the services inside this library to the internal +registry:

+

Styles += (PACKED, UNO_COMPONENT);
RegistryID = +gid_Starregistry_Applicat_Rdb;


+

+

The +second line describes, in which internal registry file, the service +shall be registered. This is the global ID +gid_Starregistry_Applicat_Rdb, which again has to be defined in this +setup script, before the definition of this file. That there is a +service to register, shows the style UNO_COMPONENT. All libraries, +that want to register a service need this flag. +

+

At +the moment there are many flags for files and very often new flags +are created or some that are no longer needed are deleted. Here a +short description of the available flags:

+

PACKED: +This is the mostly used flag. It says, that the file is zipped into +the file f_xyz in the installation set.

+

ARCHIVE: +This is important for files, that are already zipped in the output +tree. In the packing process, these files must not be zipped once +more, therefore they have to get the flag ARCHIVE.

+

UNO_COMPONENT: +This flag is important for all libraries, that want to register a +service. If this flag is set, you also have to define the RegistryID, +as shown in the example above.

+

FONT: +This flag marks all font files.

+

DONT_DELETE: +This flag shows, that the file is not deleted, if the Office +installation is removed. This is for example important for all fonts. + +

+

FONT_WARN_IF_EXISTS: +Also a typical font flag. If there is already a font defined with the +same name, a dialog box must appear during setup, to ask the user, +whether he wants to overwrite the existing font. +

+

OVERWRITE: +Overwrite the file, if it already exists, without warning. For +example the Shellnew files have this flag.

+

DONT_OVERWRITE: +Do not overwrite the file, if it already exists, for example in one +of the Windows system directories.

+

DELETE_ONLY: +This is important for a deinstallation of the Office. This file +definition block describes a file, that does not exist during setup, +but is created by the Office. This flag shows, that this new created +file, shall also be deleted during the deinstallation. +

+

CHECK_TIMESTAMP: +This flag is also only important for the deinstallation and the +DELETE_ONLY flag. If this flag is set, the installation date is also +controlled before deleting the file.

+

PATCH: +Files containing this flag are included into a patch product. For more information please look at +Understanding the PATCH flag. +

+



+

+ + \ No newline at end of file Propchange: incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_file.html ------------------------------------------------------------------------------ svn:eol-style = native Added: incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_folder.html URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_folder.html?rev=1206376&view=auto ============================================================================== --- incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_folder.html (added) +++ incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_folder.html Fri Nov 25 23:39:52 2011 @@ -0,0 +1,38 @@ + + + + + + + + + + + +

Definition +of a Folder +

+



+

+

The keyword for a folder +definition is Folder. A global ID of a folder should begin +with gid_Folder. Folders are global and cannot be assigned to +modules. Folders represent directories in the Windows system, making +possible that the office can be started via the Windows start menu. +Folders are during the setup process filled with FolderItems. +A typical definition of a folder in the scp projects looks like:

+

Folder +gid_Folder_Staroffice
Name = "%PRODUCTNAME +%PRODUCTVERSION";
End

+

As you can see, the definition of +a folder needs only a name. In this case this is %PRODUCTNAME and +%PRODUCTVERSION, which are defined in the Installation +object. Therefore the Folder name will be for example OpenOffice.org +2.0.

+

Only +if at least one FolderItem exist, the Folder will be created. The +Folder is realized by the setup as directory in the Windows system, +for example below the start menu directory. +

+ + \ No newline at end of file Propchange: incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_folder.html ------------------------------------------------------------------------------ svn:eol-style = native Added: incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_folderitem.html URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_folderitem.html?rev=1206376&view=auto ============================================================================== --- incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_folderitem.html (added) +++ incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_folderitem.html Fri Nov 25 23:39:52 2011 @@ -0,0 +1,43 @@ + + + + + + + + + + + +

Definition +of a FolderItem

+



+

+

The keyword for a FolderItem +definition is FolderItem. A global ID of a FolderItem +should begin with gid_Folderitem. FolderItems +contain the information about the assigned module in their definition +block. FolderItems represent +entries into Folders, which exist +in the Windows system, for example the Windows start menu folder. A +typical definition of a FolderItem +in the scp projects looks like:

+

FolderItem +gid_Folderitem_Staroffice_Setup
ModuleID = gid_Module_Abc
Name += "setup";
FolderID = gid_Folder_Staroffice;
FileID = +gid_File_Bin_Setup;
IconFile = gid_File_Bin_Setup;
IconID = +15;
Parameter = ".uno:NewDoc";
End

+

The +definition of a FolderItem cotains some different entries. The +FolderItem needs a name, which is after the installation visible in +the Windows start menu folder. Therefore this name often has to be +localized. Of course a FolderItem has to know, to which Folder it +belongs. Every FolderItem is a link to a file, therefore the FileID +has to be defined. In this case this is the setup file.

+

The +FolderItem is realized as link to the file assigned to the FileID in +the directory, that is specified as FolderID.

+



+

+ + \ No newline at end of file Propchange: incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_folderitem.html ------------------------------------------------------------------------------ svn:eol-style = native Added: incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_installation.html URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_installation.html?rev=1206376&view=auto ============================================================================== --- incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_installation.html (added) +++ incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_installation.html Fri Nov 25 23:39:52 2011 @@ -0,0 +1,39 @@ + + + + + + + + + + + +

Definition +of Installation +

+



+

+

The keyword for the Installation +block definition is Installation. A global ID of a +Installation should with gid_Installation. Installation +definitions cannot be assigned to modules, they are global. The +Installation block is the first block in each setup script. There is +exact one Installation block in each setup script. In this block some +important global values are assigned. A typical definition of a n +Installation block in the scp projects looks like:

+

Installation +gid_Installation
ProductName = "OpenOffice.org";
ProductVersion += ''680'';
DefaultDestPath = +"<winprogpath>\%PRODUCTNAME%PRODUCTVERSION";
End

+

In +this Installation object the variable ProductName is set to +OpenOffice.org and ProductVersion is set to 680. Therefore the +variables %PRODUCTNAME and %PRODUCTVERSION will contain these values. +The DefaultDestPath is shown the user during the setup.

+



+

+



+

+ + \ No newline at end of file Propchange: incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_installation.html ------------------------------------------------------------------------------ svn:eol-style = native Added: incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_mergemodule.html URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_mergemodule.html?rev=1206376&view=auto ============================================================================== --- incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_mergemodule.html (added) +++ incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_mergemodule.html Fri Nov 25 23:39:52 2011 @@ -0,0 +1,54 @@ + + + + + + + + + + + +

Definition +of a MergeModule

+



+

+

The keyword for a definition of a +Microsoft merge module is +MergeModule. +A global ID of a MergeModule should begin with +gid_Mergemodule. +MergeModules are not assigned to modules defined in the scp project. But for the merge process +it is necessary, that the merge module knows the directory and the feature (in Windows Installer terminology) +under which it is integrated into the Windows Installer database. Additionally the name of the cabinet file +has to be determined, because the cabinet file, that is included into in the msm file, always has to have the same +specific name(MergeModule.CABinet).Therefore the definition of a merge module in scp project is straightforward. An example +definition of a Microsoft VC80 runtime merge module looks like:

+

+ +MergeModule gid_Mergemodule_Microsoft_Vc80_Crt_X86 +
Name = "Microsoft_VC80_CRT_x86.msm"; +
Cabfilename = "openofficeorg-vc80crt.cab"; +
Feature = "gm_Root"; +
Rootdir = "TARGETDIR"; +
End

+

+ +The definition of a MergeModule requires a name, that is the name of +the msm file. This file has to be located into one of the include pathes +that are defined in the cvs module instsetoo_native/util/openoffice.lst. There +the file has to be found during packaging process. +The defined Cabfilename is used in that way, that after successful packaging process +a cabinet file with this name can be found next to the msi database. +Feature and Rootdir are required, because the merge process has to know, +under which directory and under which feature the content of the msm file has +to be integrated into the msi database. For the Rootdir the standard value is +"TARGETDIR", which is the correct choice in most cases. +The Feature is the installation unit that can be selected or deselected during +installation process. In most cases "gm_Root" is a good choice, so that +the content of the msm file cannot be deselected during installation process. +

+



+

+ + \ No newline at end of file Propchange: incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_mergemodule.html ------------------------------------------------------------------------------ svn:eol-style = native Propchange: incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_mergemodule.html ------------------------------------------------------------------------------ svn:executable = * Added: incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_module.html URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_module.html?rev=1206376&view=auto ============================================================================== --- incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_module.html (added) +++ incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_module.html Fri Nov 25 23:39:52 2011 @@ -0,0 +1,124 @@ + + + + + + + + + + + +

Definition +of a Module +

+



+

+

The keyword for a module +definition is Module. A global ID of a module should begin +with gid_Module. Modules are the most important structure +element inside the setup script and also inside the complete scp +projects. Modules are used, to make a user defined installation +possible. During the installation it is possible for the user to +select or deselect some modules, meaning some functuality, he is not +interested in. Each product can be understand as a composition of +modules. Every directory in the scp projects defines a module. +Modules consist of files, directories and the many other items that +are explained in this help. And products like StarOffice consist of +the different modules. There is always one module, the root module, +that cannot be deselected by the user.

+

A typical definition of a module +in the scp projects looks like:

+

Module +gid_Module_Prg_Calc_Bin
MOD_NAME_DESC ( MODULE_PRG_CALC_BIN +);
ParentID = gid_Module_Prg_Calc;
Default = YES;
Minimal = +YES;
Files = +(gid_File_Exe_Scalc,gid_File_Lib_Calc,gid_File_Lib_Sc,gid_File_Res_Sc);
Unixlinks += (gid_Unixlink_Zip);
Dirs = (gid_Dir_Program_Calc);
End


+

+

First +of all, a module needs next to the lists, that assign Directories, +Files, and Unixlinks to modules, some module specific assignments. +This are a Name, a Description, a ParentID, values for Default and +Minimal and optionally some styles. The Name and Description are +visible during the setup and have therefore to be localized. The +module gid_Module_Prg_Calc_Bin above is such a module, making the +functuality of the application Calc available, if the user wants so. +Therefore the Name and Description is defined in the macro +MOD_NAME_DESC, which is defined in the included file macros.inc. +

+

#define +MOD_NAME_DESC(id) \
ALL_LANG(Name,STR_NAME_##id); +\
ALL_LANG(Description,STR_DESC_##id)

+

MOD_NAME_DESC uses the macro +ALL_LANG, which is also defined in macros.inc. In this case the two +strings STR_NAME_MODULE_PRG_CALC_BIN and STR_DESC_MODULE_PRG_CALC_BIN +are therefore used in this module, describing the name and the +description of the module. For the translation process it is +therefore important that these two strings are defined and translated +in the corresponding lng +files. +

+

There +is also a feature, which is used, when the user shall be warned if he +deselects a module. This is for example important if all fonts are +deselected. With the help of the macro MOD_NAME_DESC_ON_DESELECT, +which is also defined in the macros.inc, there can be localized a +text, which is shown in a textbox, when the module is deselected.

+

#define +MOD_NAME_DESC_ON_DESELECT(id) \
MOD_NAME_DESC(id); +\
ALL_LANG(OnDeselect,STR_DESELECT_##id)

+

Very +important for the module is the ParentID, showing that all modules +belong to a module tree. The upper module in each setup script is the +module gid_Module_Root. All other modules have to be in a correlation +to this module, and every module knows its parent. In this example +the module gid_Module_Prg_Calc_Bin, which is the program module of +the Calc application, has the parent Calc. Also below the parent are +modules for the Calc Samples, the Calc Templates and so on. On the +other hand, the Calc application module is located below the all +application module and this again is located below the root module, +which cannot be selected by the user and is also not visible for the +user. For a better understanding of this module tree you should start +a installation and select the user defined installation.

+

The +two lines:

+

Default += YES;
Minimal = YES;

indicate, that the module is selected +in a Default and in a Minimal installation. If the user does not +select a user defined installation, he has the choice between default +or minimal. With the help of these two values, you can define, +whether the module shall be installed in these installation types or +not. +

+

There +are also some optional styles, which can be assigned to a module: +

+

HIDDEN_ROOT +: This flag hides the module for the user and does not show it during +the installation. A module that has the HIDDEN_ROOT flag is not +selectable or deselectable by the user in a user defined +installation.

+

The +great part of the modules are the lists for the scp items, that have +to be assigned to modules. There are lists for:

+

Files
Dirs
Unixlinks

+

+

Language specific modules +: Beginning with src680m242 the new concept of template modules was introduced. +This includes the new file type sct (script template file) +which represents files, that contain module definitions +without assignments. The sct file is expanded during scp2 build and the resulting +inc-file is included into a scp file. In this way modules for all available languages +are created automatically. +

+

+The assignment of "Files", "Dirs" or other items can be achieved by using +template modules, that are not used to define "real" modules, but only +assignments to modules. This template modules require the flag +TEMPLATEMODULE. This modules can be included from every non template +module using the key "Assigns=...". More information is available here: +Language specific modules. +

+ + \ No newline at end of file Propchange: incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_module.html ------------------------------------------------------------------------------ svn:eol-style = native Added: incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_profile.html URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_profile.html?rev=1206376&view=auto ============================================================================== --- incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_profile.html (added) +++ incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_profile.html Fri Nov 25 23:39:52 2011 @@ -0,0 +1,40 @@ + + + + + + + + + + + +

Definition +of a Profile +

+



+

+

The +keyword for a profile definition is Profile. A global ID of a +profile should begin with gid_Profile . Profiles have be +assigned to modules. The assigned module has to be listed inside the +definition block of the Profile. Profiles represent ini- or +.rc-files, which are created from the setup, for example sversion.ini +respectively .sversionrc. A typical definition of a profile in the +scp projects looks like:

+

Profile +gid_Profile_Bootstrap_Ini
ModuleID = gid_Module_Abc
#ifdef +UNX
Name = "bootstraprc";
#else
Name = +"bootstrap.ini";
#endif
Dir = gid_Dir_Program;
Styles += (NETWORK);
End

+

As +you can see, the definition of a profile is very simple. The profile +needs a ModuleID a name, a directory in which the file shall be +created and optionally some styles. In this case the +gid_Profile_Bootstrap_Ini is defined, which is named for unix +bootstraprc and for all other platforms bootstrap.ini. It is +installed into gid_Dir_Program.

+



+

+ + \ No newline at end of file Propchange: incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_profile.html ------------------------------------------------------------------------------ svn:eol-style = native Added: incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_profileitem.html URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_profileitem.html?rev=1206376&view=auto ============================================================================== --- incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_profileitem.html (added) +++ incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_profileitem.html Fri Nov 25 23:39:52 2011 @@ -0,0 +1,43 @@ + + + + + + + + + + + +

Definition +of a ProfileItem

+



+

+

The keyword for a profileitem +definition is ProfileItem. A global ID of a profileitem should +begin with gid_Profileitem. ProfileItems +have to be assigned to modules. The assigned module has to be listed +inside the definition block of the ProfileItem. +ProfileItems represent entries in ini- or .rc-files, the Profiles, +for example sversion.ini respectively .sversionrc. A typical +definition of a profileitem in the scp projects looks like:

+

ProfileItem +gid_Profileitem_Bootstrap_Section
ModuleID = +gid_Module_Abc;
ProfileID = gid_Profile_Bootstrap_Ini;
Section += "Bootstrap";
Order = 3;
Key = "Section";
Value += "Versions";
End

+

As +you can see, the definition of a profileitem is also very simple. The +profileitem needs a ProfileID, that is the global ID of the +corresponding profile. In this case this is the +gid_Profile_Bootstrap_Ini, meaning that this entry is written into +the file bootstrap.ini respectively bootstraprc. Profiles consist of +sections, in this case the section is called Bootstrap. Inside this +section in the third order is written the key-value pair:

+

[Bootstrap]
Section += Versions +

+



+

+ + \ No newline at end of file Propchange: incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_profileitem.html ------------------------------------------------------------------------------ svn:eol-style = native Added: incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_registryitem.html URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_registryitem.html?rev=1206376&view=auto ============================================================================== --- incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_registryitem.html (added) +++ incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_registryitem.html Fri Nov 25 23:39:52 2011 @@ -0,0 +1,44 @@ + + + + + + + + + + + +

Definition +of a RegistryItem

+


+

+

The keyword for a RegistyItem +definition is RegistryItem. A global ID of a RegistyItem +should begin with gid_Regitem or gid_Registryitem. +RegistyItems have to be assigned to modules. The assigned module has +to be listed in the definition block of the RegistryItem. +RegistyItems represent entries into the Windows registry. A typical +definition of a RegistyItem in the scp projects looks like:

+

RegistryItem +gid_Regitem_Soffice_Starcalcdocument_6_Defaulticon
ModuleID = +gid_Module_Abc;
ParentID = PREDEFINED_HKEY_CLASSES_ROOT;
Subkey += "soffice.StarCalcDocument.6\DefaultIcon";
Value = +"<progpath>\program\soffice.exe,3";
End

+

The +RegistryItem definition needs a ParentID, a Subkey and a Value. The +ParentID is one of the Windows registry sections, in this case the +PREDEFINED_HKEY_CLASSES_ROOT. The subkey is created, if he does not +exist. This means in this example that below the folder +soffice.StarCalcDocument.6 a key DefaultIcon is created. And this key +gets the value <progpath>\program\soffice.exe,3, where +<progpath> is a variable, substituted by the setup. +

+

+It is also possible to add the flag PATCH to a RegistryItem. In this +case it will be included into a patch. For more information about the PATCH flag please have a look at +Understanding the PATCH flag. + +



+ + \ No newline at end of file Propchange: incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_registryitem.html ------------------------------------------------------------------------------ svn:eol-style = native Added: incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_scpaction.html URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_scpaction.html?rev=1206376&view=auto ============================================================================== --- incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_scpaction.html (added) +++ incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_scpaction.html Fri Nov 25 23:39:52 2011 @@ -0,0 +1,55 @@ + + + + + + + + + + + +

Definition +of a ScpAction +

+



+

+

The keyword for the ScpAction +definition is ScpAction. A global ID of a ScpAction should +begin with gid_Scpaction. ScpAction definitions cannot be +assigned to modules, they are global. They even do not appear in the +final setup script, which is placed into the installation set next to +the setup executable. They are useful for scpzip to copy files from +the output tree into the installation set. A restriction for these +files is, that they cannot be packed. The classical exercise for +ScpActions is the copying of the loader from the language dependent +output tree directory. The loader is created in the setup project and +has the name loader.bin respectively loader.exe. In the installation +set you find this file as setup respectively setup.exe. A typical +definition of a ScpAction in the scp projects looks therefore like:

+

ScpAction +gid_Scpaction_Copy_loader
#ifdef UNX
Copy = +"loader.bin";
#else
Copy = +EXENAME(loader);
#endif
Name = EXENAME(setup);
End

+

The +ScpAction definition needs only two assignment. The source name and +the destination name. Copy describes the source name, in this case +loader.bin for Unix and EXENAME(loader) for all other platforms. The +macro EXENAME is defined in the included file macros.inc. The Name +describes the destination name, in this case EXENAME(setup). For +Windows does this mean: Copy the file loader.exe from the output tree +into the installation set as setup.exe. And for Unix: Copy the file +loader.bin from the output tree into the installation set as file +setup. A packing or other feature are not available for ScpActions.

+

ScpAction +gid_Scpaction_Flatloader
FlatLoaderZip = "setup_services.rdb";
End

+

Another +ScpAction needs only one assignment. This is the FlatLoaderZip. The +assigned file setup_services.rdb is needed as internal registry for +the setup. This file is not copied into the installation during the +setup. But the file is packed into the setup zip and therefore +available during the setup process.

+



+

+ + \ No newline at end of file Propchange: incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_scpaction.html ------------------------------------------------------------------------------ svn:eol-style = native Added: incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_shortcut.html URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_shortcut.html?rev=1206376&view=auto ============================================================================== --- incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_shortcut.html (added) +++ incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_shortcut.html Fri Nov 25 23:39:52 2011 @@ -0,0 +1,53 @@ + + + + + + + + + + + +

Definition +of a Shortcut

+



+

+

The keyword for a Shortcut +definition is Shortcut. A global ID of a ShortCut should begin +with gid_Shortcut . Shortcuts are not assigned to modules, +they are always connected with a file. Shortcuts represent links to +files, which can exist in all available platform. The classical +Shortcuts are the links to the executables setup and soffice +(respectively setup.exe and soffice.exe), which are installed into +the program directory. The links exist in the root of the Office +installation. +

+

The Shortcut to the Office +executable, which is defined as global ID gid_File_Bin_Soffice can +therefore be defined as you can see below:

+

Shortcut +gid_Shortcut_Soffice
FileID = gid_File_Bin_Soffice;
Dir = +PREDEFINED_PROGDIR;
#ifdef WNT
Name = "%PRODUCTNAME +%PRODUCTVERSION";
#else
Name = "soffice";
#endif
Styles += (STANDALONE, WORKSTATION, ALL_USERS);
End

+

The +Shortcut definition needs first of all the FileID of the file, to +which the link shall be created. Of course this FileID is also +realized as global ID. The next assignment is the directory, in which +the link shall be created. And of course also this directory is +defined as global ID, or as in this case as a setup variable. The +PREDEFINED_PROGDIR defines the Office installation root. The next +assignment is necessary for the name of the link. As you can see, +this can be platform dependent. For Windows the name "%PRODUCTNAME +%PRODUCTVERSION" is used. For Unix the link is simply named +soffice. Optionally there are also some styles. which define, where +the link is created. +

+

It is +also possible to create links to other links. In this case the +definition block does not contain a FileID, but a ShortcutID.

+



+

+ + \ No newline at end of file Propchange: incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_shortcut.html ------------------------------------------------------------------------------ svn:eol-style = native Added: incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_templatemodule.html URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_templatemodule.html?rev=1206376&view=auto ============================================================================== --- incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_templatemodule.html (added) +++ incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_templatemodule.html Fri Nov 25 23:39:52 2011 @@ -0,0 +1,146 @@ + + + + + + + + + + + +

+Defining Modules With Language Specific Files

+


+

+

+Before understanding this section, you have to know the scp item +Module. Documentation about this item can be found +here.

+

+The strict separation of language dependent and language independent files +that is required for the new package structure of an OpenOffice.org 3.0 and the +huge number of supported languages, made is necessary to introduce a new process +of module creation in scp tooling. +

+

+This new process supports automatic module generation for all languages supported +by OpenOffice.org. Therefore it was necessary to add to the existing script particle +files (scp) the new script template files (sct). sct files contain abstract module +definitions, without assignments of scp items like "Files", "Dirs", ... and with +placeholders for language settings. This sct files are evaluated during +scp2 build by Perl programs, that resolve the language settings in the +abstract module definitions. In this process the sct file is expanded to an inc file, +which is again included into a scp file. The result is a scp file that can be very big. +Because of the huge number of languages it can contain thousand of module definitions. +

+

+The assignments of scp items like "Files", "Dirs", ... should not be done inside +the sct file, but as you are used to, inside a scp file. Therefore template modules +were introduced, that are not a visible module during product installation, but are +only used for assignments. This modules must have the flag TEMPLATEMODULE and are +defined in scp files. Especially language specific files should be assigned to modules +with flag TEMPLATEMODULE in the future. The abstract modules that are defined in the +sct files can reference this modules using the new key "Assigns=...". If the module +shall also be used for package creation (RPM, Solaris Package, ...), it is additionally +necessary to define a file, containing the package information for this module. This +happens with the key "PackageInfo=..." in the Module definition. +

+

+In the following there is a step-by-step explanation of this new process for +language dependent modules with language specific files: +

+

+Step 1:
+All sct files are currently located in the folder scp2/source/templates, +where they are found by the Perl program, that resolves the languages. +The Perl program expands the abstract modules for each available +language to an inc file. The inc files are created at scp2/<platform>/inc/<incfilename>. +From there they can be included into scp files. +
+Example for an abstract module definition: +

+Module gid_Module_Langpack_Calc_<LANGUAGE_>
+ ParentID = gid_Module_Prg_Calc_Bin;
+ Sortkey = "450";
+ Language = "<LANGUAGE>";
+ Assigns = gid_Module_Langpack_Calc_Template;
+ Name = "gid_Module_Langpack_Calc_<LANGUAGE_>";
+ Description = "gid_Module_Langpack_Calc_<LANGUAGE_>";
+ PackageInfo = "packinfo_office_lang.txt";
+ Styles =(HIDDEN_ROOT, LANGUAGEMODULE);
+End
+
+The occurences of "<LANGUAGE>" and "<LANGUAGE_>" are resolved for all supported languages +(taking care of underlines, like "en-US" or "en_US"). In this example the file can +be named "alllangmodules_calc.inc". +

+

+Step 2:
+The created inc file is included into a real scp file, +for example in scp2/source/calc/module_calc.scp:

+#include "alllangmodules_calc.inc" +

+

+Step 3:
+The assignments of files and directories to modules with +language dependent files must be done at modules that have the +flag TEMPLATEMODULE. This modules can be defined in scp files. +From this modules no packages can be created. They are only +used as "assignment-container" for other modules, that reference +this module.
+Example for a template module:

+Module gid_Module_Langpack_Calc_Template
+ ParentID = gid_Module_Prg_Calc_Bin;
+ Name = "gid_Module_Langpack_Calc_Template";
+ Description = "gid_Module_Langpack_Calc_Template";
+ Styles = (TEMPLATEMODULE);
+ Files = (gid_File_Help_Scalc_Zip,
+ gid_File_Res_Analysis,
+ gid_File_Res_Bf_Sc,
+ gid_File_Res_Date,
+ gid_File_Res_Sc);
+End
+

+

+Step 4:
+Modules can reference another module, that has style +TEMPLATEMODULE. This happens with the key "Assigns" in the +module definition (see example in step 1).
+Example:
+Assigns = gid_Module_Langpack_Calc_Template;
+
+The standard case is the following:
+The module definition in the sct file is language dependent. +But all languages use the same assignments. Therefore this module +definition uses the "Assigns"-key. The referenced module must +have the style TEMPLATEMODULE. The files and directories, that +are assigned to the module with flag TEMPLATEMODULE are +assigned to the referencing module during packaging process. +

+

+Step 5:
+Package creation cannot be done for abstract template modules, +but only for specific modules. The modules defined in sct files +normally are used for package creation. Therefore this modules +have to know file containing the package info. This file has to be found +in the solver. It can be referenced with the key "PackageInfo" +(see example in step 1).
+PackageInfo = “packinfo_office_lang.txt”; +

+

+Step 6:
+Modules with language dependent files must have the flag "LANGUAGEMODULE" +(see example in step 1). This is necessary, because not all language +modules are required during packaging of one specific installation set. +

+

+Because of this changes in the SRC680 m242 it is strictly recommended, +that all language specific files are assigned to modules with flag TEMPLATEMODULE. +If there are wrong assignments, so that language specific files and not language +specific files are assigned to one module, the packaging process can find this +errors and stops the creation of the installation set. +

+

+ + \ No newline at end of file Propchange: incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_templatemodule.html ------------------------------------------------------------------------------ svn:eol-style = native Propchange: incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_templatemodule.html ------------------------------------------------------------------------------ svn:executable = * Added: incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_unixlink.html URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_unixlink.html?rev=1206376&view=auto ============================================================================== --- incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_unixlink.html (added) +++ incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_unixlink.html Fri Nov 25 23:39:52 2011 @@ -0,0 +1,46 @@ + + + + + + + + + + + +

Definition +of a Unixlink +

+



+

+

The +keyword for a link definition on Unix systems is Unixlink. A +global ID of a unixlink should begin with gid_Unixlink . +Unixlinks have to be assigned to modules in the definition block of +the module. A typical definition of a procedure in the scp projects +looks like:

+

#ifdef +UNX
Unixlink gid_Unixlink_Zip
BIN_FILE_BODY;
Styles = +();
Dir = gid_Dir_Program;
Name = „ziplink“;
Target += „/usr/bin/zip“;
End
#endif

+

#ifdef +UNX
Unixlink gid_Unixlink_Unzip
BIN_FILE_BODY;
Styles = +();
Dir = gid_Dir_Program;
Name = „unziplink“;
Target += „/usr/bin/unzip“;
End
#endif

+

Assignment +at a Module:

+

Unixlinks += (gid_Unixlink_Zip, gid_Unixlink_Unzip);

+

The +definition of a Unixlink is simple. The link has a name, some +privileges (555 in the case of BIN_FILE_BODY), a directory, in which +the link is created, and a target. In the first example above, a link +named „ziplink“ is created in the program directory in +the Office installation, that points to the file „/usr/bin/zip“. + +

+



+

+ + \ No newline at end of file Propchange: incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_unixlink.html ------------------------------------------------------------------------------ svn:eol-style = native Propchange: incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_unixlink.html ------------------------------------------------------------------------------ svn:executable = * Added: incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_windowscustomaction.html URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_windowscustomaction.html?rev=1206376&view=auto ============================================================================== --- incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_windowscustomaction.html (added) +++ incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_windowscustomaction.html Fri Nov 25 23:39:52 2011 @@ -0,0 +1,49 @@ + + + + + + + + + + + +

Definition +of a WindowsCustomAction

+



+

+

The keyword for a definition of a +custom action for the Windows Installer service is +WindowsCustomAction. +A global ID of a WindowsCustomAction should begin with +gid_Customaction. +WindowsCustomActions are not assigned to modules. They know their +file, that contains the code of the Custom Action. A typical +definition of a WindowsCustomAction in the scp projects looks like:

+

WindowsCustomAction +gid_Customaction_Shellextensionsdll3
Name = +"Shellextensionsdll3";
Typ = "65";
Source = +"shlxtmsi.dll";
Target = +"InstallStartmenuFolderIcon";
Inbinarytable = +1;
Assignment1 = ("InstallExecuteSequence", "Not +REMOVE=\"ALL\" And Not PATCH", "end");
End

+

The +WindowsCustomAction has a name, that is the unique identifier in the +table „CustomAction“ in the Windows Installer database. +The type is included into the „Type“ column of the table +„CustomAction“. The same with the source, which is in +this case a library, that is included into the table „Binary“ +of the msi database. Therefore the key „Inbinarytable“ is +set to „1“. The target is the name of the procedure, that +is started by the Windows Installer service. And finally the +Assignment1 (many more assignments are possible with increasing +numbers) defines the table, in which the CustomAction is included +into the action order. Possible values are InstallExecuteSequence, +InstallAdminSequence, InstallUISequence, ... . In this case als a +condition for the execution can be defined and the position in the +execute sequence.

+



+

+ + \ No newline at end of file Propchange: incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_windowscustomaction.html ------------------------------------------------------------------------------ svn:eol-style = native Propchange: incubator/ooo/ooo-site/trunk/content/installation/pics/scpitem_windowscustomaction.html ------------------------------------------------------------------------------ svn:executable = * Added: incubator/ooo/ooo-site/trunk/content/installation/pics/undefining_gids.html URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/installation/pics/undefining_gids.html?rev=1206376&view=auto ============================================================================== --- incubator/ooo/ooo-site/trunk/content/installation/pics/undefining_gids.html (added) +++ incubator/ooo/ooo-site/trunk/content/installation/pics/undefining_gids.html Fri Nov 25 23:39:52 2011 @@ -0,0 +1,58 @@ + + + + + + + + + + + +

Undefining +global IDs

+



+

+

Beginning with src680m25 the +concept of undefining global IDs is introduced. This is a very +important, if a new product shall be created. Because many of our +products are very similar, it is better, to define only the +difference of two setup scripts. Even OpenOffice.org, StarOffice and +StarOfficeMulti can be defined by describing only the differences +compared to OpenOffice.org. Therefore all scp files need only to be +build once, which reduces the build time of the scp projects +dramatically. Furthermore definitions like OSL_PRODUCT, FAT_PRODUCT +or FAM_PRODUCT are no longer required, which increases the +readability of scp files.

+

The introduction of +difference-files leads to the introduction of product families:

+

OpenOffice.org -> StarOffice +-> StarOfficeMulti

+

Adabas -> AdabasMulti

+

This means, that OpenOffice.org +and Adabas are base products. A StarOffice uses the same scp files as +OpenOffice.org and contains some additional scp files, in which new +global IDs are defined and other global IDs are undefined.

+

The undefining of a global ID is +a very simple process. To undefine the file defined with the global +ID ''gid_File_Lib_Abc'', you only have to include in one of the scp +files, that are part of the product, the following line:

+

UnFile gid_File_Lib_Abc

+

That's all! You only have to list +the global ID and the item type, with an ''Un'', before the keyword +used for the definition. Take care, all strings are case sensitive!

+

You can also use:

+

UnInstallation
UnHelpText
UnStarRegistry
UnDataCarrier
....

+

and so on. +

+

If you want to undefine a file +that is added to a module, you also only have to write this one +undefinition line. The process of removal of non defined global IDs +from modules, automatically removes the global ID from the module +definition.

+



+

+



+

+ + \ No newline at end of file Propchange: incubator/ooo/ooo-site/trunk/content/installation/pics/undefining_gids.html ------------------------------------------------------------------------------ svn:eol-style = native Added: incubator/ooo/ooo-site/trunk/content/installation/pics/understanding_the_lng_files.html URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/installation/pics/understanding_the_lng_files.html?rev=1206376&view=auto ============================================================================== --- incubator/ooo/ooo-site/trunk/content/installation/pics/understanding_the_lng_files.html (added) +++ incubator/ooo/ooo-site/trunk/content/installation/pics/understanding_the_lng_files.html Fri Nov 25 23:39:52 2011 @@ -0,0 +1,162 @@ + + + + + + + + + + + +

Understanding +the lng files

+



+

+

Some content of the scp projects +has to be translated in the supported languages. This is important +for localized directory names, or text output of some basic scripts. +This translation happens with the help of the so called lng files, +which are automatically included into the translation process. These +files must have the same names as the scp files, in which the +translated string is needed, but its extensions are .lng. One example +shows this simple behaviour:

+

Module +gid_Module_Prg_Calc_Bin
MOD_NAME_DESC ( MODULE_PRG_CALC_BIN +);
ParentID = gid_Module_Prg_Calc;
Default = YES;
Minimal = +YES;
Files = +(gid_File_Exe_Scalc,gid_File_Lib_Calc,gid_File_Lib_Sc,gid_File_Res_Sc);
End

+

As you can see, this is the +definition of a module block. In the user defined installation, there +is a user interface for selecting the modules. This cotains a name +and a description of each module. And of course these have to be +localized. In the module definition you see the line:

+

MOD_NAME_DESC ( +MODULE_PRG_CALC_BIN );

+

MOD_NAME_DESC is a macro defined +in macros.inc. There you find:

+

#define MOD_NAME_DESC(id) +\
ALL_LANG(Name,STR_NAME_##id); +\
ALL_LANG(Description,STR_DESC_##id)

+

Therefore this can be resolved to +the two macros: +

+

ALL_LANG(Name,STR_NAME_ +MODULE_PRG_CALC_BIN )
ALL_LANG(Description,STR_DESC_ +MODULE_PRG_CALC_BIN )

+


And ALL_LANG is also defined +in macros.inc, but this is not important yet. Important are the two +strings STR_NAME_ MODULE_PRG_CALC_BIN and STR_DESC_ +MODULE_PRG_CALC_BIN, which exist in the scp file, in which the module +gid_Module_Prg_Calc_Bin is defined. For this file xyz.scp there has +to be also a files xyz.lng. The filenames have to be identical, +without the extensions. Therefore in the lng file, we find the +following two entries:

+

[STR_NAME_MODULE_PRG_CALC_BIN]
49 += "Programmodul"
01 = "Program Module"
07 = +"Ïðîãðàììíûé +ìîäóëü"
55 = +"Programmodul"
37 = "Módulo del programa"
03 += "Módulo do programa"
30 = "ËåéôïõñãéêÞ +ìïíÜäá ðñïãñÜììáôïò"
31 += "Programma module"
33 = "Module"
34 = +"Módulo del programa"
35 = "Ohjelmamoduuli"
39 += "Modulo programma"
45 = "Programmodul"
46 += "Programmodul"
48 = "Modu³ programu"
81 += "ÌßÛ¸Þ×ÑÓ¼Þ­°Ù"
82 += "ÇÁ·Î±×·¥ +¸ðµâ"
86 = "³ÌÐòÄ£¿é"
88 += "µ{¦¡¼Ò¶ô"
90 += "Program modülü"
96 = "æÍÏÉ +ÈÑäÇãÌ äãØíÉ"

+

[STR_DESC_MODULE_PRG_CALC_BIN]
49 += "Die Anwendung %PRODUCTNAME Calc"
01 = "The +application %PRODUCTNAME Calc"
07 = "Ïðèëîæåíèå +%PRODUCTNAME Calc"
55 = "Die Anwendung %PRODUCTNAME +Calc"
37 = "La aplicación %PRODUCTNAME Calc"
03 += "A aplicação %PRODUCTNAME Calc"
30 = "Ç +åöáñìïãÞ +%PRODUCTNAME Calc"
31 = "De applicatie %PRODUCTNAME +Calc"
33 = "L'application %PRODUCTNAME Calc"
34 += "La aplicación %PRODUCTNAME Calc"
35 = +"Sovellus %PRODUCTNAME Calc"
39 = "L'applicazione +%PRODUCTNAME Calc"
45 = "Applikationen %PRODUCTNAME +Calc"
46 = "Tillämpningen %PRODUCTNAME Calc"
48 += "Zastosowanie %PRODUCTNAME Calc"
81 = "%PRODUCTNAME +Calc ±Ìßع°¼®Ý"
82 += "%PRODUCTNAME Calc ÀÀ¿ëÇÁ·Î±×·¥"
86 += "%PRODUCTNAME Calc Ó¦ÓóÌÐò"
88 += "À³¥Îµ{¦¡ +%PRODUCTNAME Calc"
90 = "%PRODUCTNAME Calc +uygulamasý"
96 = "ÇáÊØÈíÞ +%PRODUCTNAME Calc"

+

The names and descriptions are +translated in any supported language. Therefore the scp linker will +create a module definition, which looks like:

+

Module +gid_Module_Prg_Calc_Bin
ParentID = gid_Module_Prg_Calc;
Minimal += YES;
Default = YES;
Files = (gid_File_Exe_Scalc, +gid_File_Lib_Calc, gid_File_Lib_Sc, +gid_File_Res_Sc);
ConfigurationItems = ( +gid_Configurationitem_Soffice_Apps_Scalc5);
FolderItems = +(gid_Folderitem_Scalc);
Name (03) = "Módulo do +programa";
Description (03) = "A aplicação +%PRODUCTNAME Calc";
Name (07) = "Ïðîãðàììíûé +ìîäóëü";
Description (07) += "Ïðèëîæåíèå +%PRODUCTNAME Calc";
Name (30) = "ËåéôïõñãéêÞ +ìïíÜäá ðñïãñÜììáôïò";
Description +(30) = "Ç åöáñìïãÞ +%PRODUCTNAME Calc";
Name (31) = "Programma +module";
Description (31) = "De applicatie %PRODUCTNAME +Calc";
Name (33) = "Module";
Description (33) = +"L'application %PRODUCTNAME Calc";
Name (34) = "Módulo +del programa";
Description (34) = "La aplicación +%PRODUCTNAME Calc";
Name (35) = "Ohjelmamoduuli";
Description +(35) = "Sovellus %PRODUCTNAME Calc";
Name (37) = "Módulo +del programa";
Description (37) = "La aplicación +%PRODUCTNAME Calc";
Name (39) = "Modulo +programma";
Description (39) = "L'applicazione +%PRODUCTNAME Calc";
Name (45) = "Programmodul";
Description +(45) = "Applikationen %PRODUCTNAME Calc";
Name (46) = +"Programmodul";
Description (46) = "Tillämpningen +%PRODUCTNAME Calc";
Name (48) = "Modu³ +programu";
Description (48) = "Zastosowanie %PRODUCTNAME +Calc";
Name (49) = "Programmodul";
Description +(49) = "Die Anwendung %PRODUCTNAME Calc";
Name (81) = +"ÌßÛ¸Þ×ÑÓ¼Þ­°Ù";
Description +(81) = "%PRODUCTNAME Calc ±Ìßع°¼®Ý";
Name +(82) = "ÇÁ·Î±×·¥ +¸ðµâ";
Description (82) = "%PRODUCTNAME +Calc ÀÀ¿ëÇÁ·Î±×·¥";
Name +(86) = "³ÌÐòÄ£¿é";
Description +(86) = "%PRODUCTNAME Calc Ó¦ÓóÌÐò";
Name +(88) = "µ{¦¡¼Ò¶ô";
Description +(88) = "À³¥Îµ{¦¡ +%PRODUCTNAME Calc";
Name (90) = "Program +modülü";
Description (90) = "%PRODUCTNAME Calc +uygulamasý";
Name (96) = "æÍÏÉ +ÈÑäÇãÌ äãØíÉ";
Description +(96) = "ÇáÊØÈíÞ +%PRODUCTNAME Calc";
Name (99) = +"STR_NAME_MODULE_PRG_CALC_BIN";
Description (99) = +"STR_DESC_MODULE_PRG_CALC_BIN";
Name (01) = "Program +Module";
Description (01) = "The application +%PRODUCTNAME Calc";
End

+

You see, that most of the module +definition is translation stuff. Finally it is the scpzip that +creates installation sets for special languages. Therefore the final +result for an english installation set looks like:

+

Module +gid_Module_Prg_Calc_Bin
ParentID = gid_Module_Prg_Calc;
Name = +"Program Module";
Description = "The application +%PRODUCTNAME Calc";
Minimal = YES;
Default = YES;
Files += (gid_File_Exe_Scalc, gid_File_Lib_Calc, gid_File_Lib_Sc, +gid_File_Res_Sc);
End

+

This module definition you can +finally find in the setup script in the installation set next to the +setup.

+



+

+ + \ No newline at end of file Propchange: incubator/ooo/ooo-site/trunk/content/installation/pics/understanding_the_lng_files.html ------------------------------------------------------------------------------ svn:eol-style = native