CWS networker2 specification

Document - ID	Specification Owner	Last Change	Status
	Ingo Schmidt	26.11.03	
Conforms to	
Applies to	
Task ID(s)	i22553
Category	Feature

Abstract

In the cws networker2 the hidden responsefile installation from within the Office has to be removed. The Office has to be able to start without the necessity of a user installation that was executed before. The possibility to make a user installation via setup will be removed, too.

i-Team Members

	Name	E-mail Address
Specification Owner	Ingo Schmidt (is)	Ingo.Schmidt@Sun.COM
User Experience		
Development	Dirk Völzke	Dirk.Voelzke@Sun.COM
Development	Lars Oppermann	Lars.Oppermann@Sun.COM
Development	Oliver Braun	Oliver.Braun@Sun.COM
Development	Ingo Schmidt (is)	Ingo.Schmidt@Sun.COM
Development	Tino Rachui (tra)	Tino.Rachui@Sun.COM
Development	Gregor Hartmann (gh)	Gregor.Hartmann@Sun.COM
Quality Assurance	Olaf Felka (of)	Olaf.Felka@Sun.COM
Quality Assurance	Jörg Skottke (jsk)	Joerg.Skottke@Sun.COM
Documentation		

Approved for Implementation

	Approved by	Date
User Experience	<Name>	<Date>
Development		
Quality Assurance		
Documentation		
String Review		

Document Change History

Rev. Level	Change	Initials	Date
1.0	Initial release	is	24.10.03

CWS networker2:

The StarOffice has to be able to start directly after the network installation. The responsefile user installation has to be removed.

Setup:

After cws networker there were still two possibilities to start the setup, that was installed during the network installation:

The setup starts the network setup in maintenance mode. This was started after „setup -net“.

The setup started with „setup“ started the user installation.

After cws „networker2“ the command „setup“ starts the maintenance mode. There is no more chance to make a user installation. The setup user installation has to be removed, because otherwise two ways of a user installation had to be supported. One with the setup (with links, sversionrc, ...) and one from within the soffice (without links, sversionrc, ...). Furthermore the introduction of the „One user“ and „All user“ installation (see below) causes the removal of the flag WORKSTATION from basic scripts and Custom actions. These basic scripts and custom actions have to be executed during the new only installation type. Because this is a network installation, actions with flag WORKSTATION would not be executed by the setup.

If the soffice starts without a hidden user installation the following changes occur, that have to be announced publicly (ToDo IS):

there is no more sversion.ini (sversionrc).

there are no more links in the user directory to the network installation.

All other parts of the user installation (listed below) have to be removed, to be done by the setup or to be done by the soffice.

Systemintegration:

There has to be a new dialog in the (network) setup, in which the user is asked, whether the systemintegration has to be done for:

0 user (only for installations on a file server) (OPTIONAL)

1 user (the user installing StarOffice)

all users at the computer

A system integration for all users would require root rights at the PC.

On a Windows system, the setup tests whether it can write into HkeyLocalMachine. If this is not possible it will automatically write into HkeyCurrentUser. On Unix platforms the systemintegration is more complex. We offer it for CDE, KDE and Gnome, on Linux only for KDE and Gnome. The system integration for all users at the computer is currently only possible for CDE. For StarOffice 8 (but after cws networker2), the system integration for all users of a PC will be more important than the systemintegration for only the current user. But this problem has to be solved after cws networker2. Therefore the user will be asked, for whom (0, 1 or all users) the systemintegration shall be done. In our standard dialog with the module selection, the user selects between CDE, KDE and Gnome.

Additional Tasks:

Investigate functionality of user installation that needs to be transfered to the Setup, to the Office startup or that needs to be removed (IS)

Announce removal of sversion.ini and links in user installation (IS)

ToDos of a user installation:

During the user installation in OpenOffice.org 1.1 the user must accept the license file and can read the readme file. He can determine the destination directory in which the setup installs all files containing the flag WORKSTATION. In a multilingual network installation the Setup presents a dialog, in which the user determines the language of the user installation.

-> License and language selection dialog have to included into soffice start.

-> Readme-Dialog (needs to be discussed).

(see Appendix1: Dialogs)

The Setup installs all files containing the flag WORKSTATION

The Setup creates empty directories: user/autotext, user/temp, user/autocorr, ...

Instead of the Setup, these two tasks are done by the Office itself. It copies the files from the network installation into the user directory and creates empty directories.

-> Files and directories (not systemintegration) are created by the soffice

The following tasks are done by the normal user installation and by the responsefile user installation:

Creation of shortcuts: setup, soffice, spadmin

-> will no longer be needed

Creation of the file sversion.ini (sversionrc). This file has not the flag WORKSTATION but INSTALL_INFO.

-> will no longer be needed

Configuration: Different Config entries with WORKSTATION flag

-> These ConfigurationItems should no longer be needed. If it is not possible to delete them, they have to be written by the soffice.

Succeeding is a list of all basic scripts and CustomActions that are executed during the user installation. Part of the Setup has to be for instance the system wide systemintegration, which has to be available before the first Office start. Part of the Office startup has to be for instance the migration, because the Setup network installation cannot migrate any user data.

Basic scripts of the user installation:

Instead of the flags NETWORK, WORKSTATION and STANDALONE the new installation mechanism provides an ALL_USER or an ONE_USER installation type. This is important for all basic scripts affecting the system integration (nearly all).

gid_Procedure_Kill_Plugin_Wrkstn: Deletes empty directories program/addin and

share/autocorr on the user side

-> no longer needed, because user directories are created by the soffice.

gid_Procedure_Rename_Basicdir: renames user/basic to user/__basic_60

(-> problem of migration, script written by AB)

The migration can only be executed by the Office in the future, no longer from the Setup. A network installation cannot migrate the user data. This basic script must therefore be removed.

-> migration of user data still needs to be specified. This script will no longer be the solution and can therefore be removed. Already removed in cws networker

gid_Procedure_Copy_Readme_File: Copies the readme and license files into the user installation. The readme- and license files shall in the future no longer be copied into the OpenOffice.org directory in the user home directory (because this is not visible for the user, especially if we rename the destination directory to .OpenOffice.org1.1 for Unix). The Office has to show these files. It finds them in the network installation. Therefore also this basic script can be removed.

-> no longer needed, already removed in cws networker

gid_Procedure_Remove_Readme_File: Deletes the readme and license files at the deinstallation. Because these files are no longer copied in the installation, they do not need to be deleted during deinstallation. Therefore this script can be removed

-> no longer needed, already removed in cws networker

gid_Procedure_Start_Regsvrex: Calling regsvrex.exe shlxthdl.dll

-> The flag WORKSTATION has to be removed. Concerning to TRA this basic script can be executed always, independent from ALLUSER or ONEUSER. If the user has not sufficient rights, the functionality will not be available (same as in StarOffice 7).

gid_Procedure_Uninstall_Regsvrex: Calling regsvrex.exe /u shlxthdl.dll at the deinstallation

-> The flag WORKSTATION has to be removed.

gid_Procedure_Check_Uno_Packages_Workstation: Calling pkgchk.exe -r

-> gid_Procedure_Check_Uno_Packages_Workstation already removed in cws networker

gid_Procedure_Autostart_Inst: Calling quickstart.exe

-> This basic script cannot be started in a network installation for all users. Therefore it will only be started if the installation is done for one user (new STANDALONE installation).

gid_Procedure_Adabas_Inst: Adabas as FollowUpApplication

This script starts the Adabas FollowUpApplication. This can be solved in cws networker:

user installation started with ./setup: No change.

user installation started with ./soffice: During the Office startup the Adabas installation would be very disturbing. Because the user installation is started with a responsefile, the Adabas module is deselected in this file.

-> this cannot be supported anymore. The basic script has to be removed. In cws networker this module was always deselected in the responsefile.

gid_Procedure_Javafilter_Xmergesync_Pword_Reg_Install (from Ireland):

Entries for the Windows registry (contains: GetSetupEnv.IsInstallForAllUser)

gid_Procedure_Javafilter_Xmergesync_Pword_Reg_Uninstall (from Ireland):

Deleting the Windows registry entries at the deinstallation

gid_Procedure_Javafilter_Xmergesync_Pexcel_Reg_Install

gid_Procedure_Javafilter_Xmergesync_Pexcel_Reg_Uninstall

-> To be rewritten, concerning the ALLUSER or ONEUSER installation. The flag WORKSTATION has to be removed.

gid_Procedure_Cde_Dtint: Calling dtint (Attention: Language parameter)

gid_Procedure_Cde_Deinstall: Calling dtint -remove at deinstallation

gid_Procedure_Gnome_Install: Calling gnomeint

gid_Procedure_Gnome_Deinstall: Calling gnomeint at deinstallation

gid_Procedure_Kde_Inst_For_Redhat: KDE integration

gid_Procedure_Kde_Create_Links: KDE integration

gid_Procedure_Kde_Remove_Links: KDE deintegration

These seven basic scripts make the Unix systemintegration.

-> Systemintegration is still part of the setup. But the basic scripts shall be removed and replaced by shell scripts from OBR (#111798).

Difficulties with the basic scripts:

Which language and which destination directory shall these scripts use? There is no more dialog during the setup.

CustomActions of the user installation:

Instead of the flags NETWORK, WORKSTATION and STANDALONE the new installation mechanism provides an ALL_USER or an ONE_USER installation type. This is important for all custom actions affecting the system integration.

gid_Custom_Del for deinstallation

-> This CustomAction removes things, that are no longer part of StarOffice. Therefore this CustomAction and the del library can be removed (#i22715)

gid_Custom_Usp at Installation (migration from 6.0 to 7, TPF)

This custom action will be removed, because the migration will be part of the soffice, no longer part of the setup.

gid_Cust_Mig ( has only Migration flag )

-> The migration will be part of the office, no longer part of the setup. If there is a multiuser installation a migration of user data does not make any sense. This custom action will be removed in cws networker2.

gid_Custom_Reg4msdoc

At the user installation started with ./setup (therefore with GUI) nothing will be changed. At the user installation in responsefile mode started from within the Office there have to be defined settings for the MS file type registration in the response file

This custom action already contains the difference between ONEUSER and ALLUSER. Therefore it will be executed during setup in any case. The flag WORKSTATION has to be removed.

gid_Custom_Jvm (Java-Installation, works already on demand concerning to MBA)

At the user installation started with ./setup (therefore with GUI) nothing will be changed. At the user installation in responsefile mode started from within the Office the corresponding value will be set to „InstalledorNone“ (-> ToDo IS).

The custom action gid_Custom_Reg4msdoc has the flags NETWORK, STANDALONE and WORKSTATION. Therefore it will be executed during the standard installation, independent, whether the installation is done for ALLUSER or ONEUSER. During the soffice start is will not be executed.

gid_Custom_Regactivex for the ActiveX control

This custom action already contains the difference between ONEUSER and ALLUSER. Therefore it will be executed during setup in any case. The flag WORKSTATION has to be removed.

gid_Custom_Regmimetypes (Unix)

This CustomAction contains references to the links in the user directory. If these links will no longer be created, these CustomAction have to be rewritten (this will be a ToDo for OBR and TRA) (Task i22671).

The custom action gid_Custom_Regmimetypes has to be executed during setup in both cases: Installation for ONEUSER or ALLUSER.

ConfigurationItems:

The following ConfigurationItems are written during the user installation. Additionally there are further ConfigurationItems for the user data, which were asked for during the workstation installation. This user data ConfigurationItems will no longer be supported. Therefore there are five ConfigurationItems left, which have to be written by the soffice during first startup (LO):

ConfigurationItem gid_Configurationitem_User_Office_Installpath

ModuleID	= gid_Module_Root;

Path	= "org.openoffice.Setup/Office";

Key	= "ooSetupInstallPath";

Value	= "<workpath>\user";

Styles	= (CFG_STRING, WORKSTATION);

End

ConfigurationItem gid_Configurationitem_Common_Path_Officeinstall

ModuleID	= gid_Module_Root;

Path	= "org.openoffice.Office.Common/Path/Current";

Key	= "OfficeInstall";

Value	= "<progpath>";

Styles	= (CFG_STRING, WORKSTATION);

End

ConfigurationItem gid_Configurationitem_User_User_Language

ModuleID	= gid_Module_Root;

Path	= "org.openoffice.Setup/L10N";

Key	= "ooLocale";

Styles	= (CFG_STRING, WORKSTATION);

Value (03)	= "pt";

Value (07)	= "ru";

Value (30)	= "el";

Value (31)	= "nl";

Value (33)	= "fr";

Value (34)	= "es";

Value (35)	= "fi";

Value (36)	= "hu";

Value (37)	= "ca";

Value (39)	= "it";

Value (42)	= "cs";

Value (43)	= "sk";

Value (44)	= "en-GB";

Value (45)	= "da";

Value (46)	= "sv";

Value (47)	= "no";

Value (48)	= "pl";

Value (49)	= "de";

Value (55)	= "pt-BR";

Value (66)	= "th";

Value (77)	= "et";

Value (81)	= "ja";

Value (82)	= "ko";

Value (86)	= "zh-CN";

Value (88)	= "zh-TW";

Value (90)	= "tr";

Value (91)	= "hi-IN";

Value (96)	= "ar";

Value (97)	= "he";

Value (99)	= "ISO_CODE";

Value (01)	= "en-US";

End

ConfigurationItem gid_Configurationitem_Linguistic_General_Default_Locale

ModuleID	= gid_Module_Root;

Path	= "org.openoffice.Office.Linguistic/General";

Key	= "DefaultLocale";

Styles	= (CFG_STRING, WORKSTATION);

Value (03)	= "pt";

Value (07)	= "ru";

Value (30)	= "el";

Value (31)	= "nl";

Value (33)	= "fr";

Value (34)	= "es";

Value (35)	= "fi";

Value (36)	= "hu";

Value (37)	= "ca";

Value (39)	= "it";

Value (42)	= "cs";

Value (43)	= "sk";

Value (44)	= "en-GB";

Value (45)	= "da";

Value (46)	= "sv";

Value (47)	= "no";

Value (48)	= "pl";

Value (49)	= "de";

Value (55)	= "pt-BR";

Value (66)	= "th";

Value (77)	= "et";

Value (81)	= "en-US";

Value (82)	= "en-US";

Value (86)	= "en-US";

Value (88)	= "en-US";

Value (90)	= "tr";

Value (91)	= "hi-IN";

Value (96)	= "ar";

Value (97)	= "he";

Value (99)	= "ISO_CODE";

Value (01)	= "en-US";

End

ConfigurationItem gid_Configurationitem_Linguistic_General_Default_Locale_Cjk

ModuleID	= gid_Module_Root;

Path	= "org.openoffice.Office.Linguistic/General";

Key	= "DefaultLocale_CJK";

Styles	= (CFG_STRING, WORKSTATION);

Value (82)	= "ko";

Value (86)	= "zh-CN";

Value (88)	= "zh-TW";

Value (81)	= "ja";

End

Appendix1: Dialogs

Language Selection

The language dialog only shown when multiple Languages are installed

The language dialog is the first visible dialog after the splashscreen, since all further dialogs depend on the selection that is made in it.

The user must select one and only one language from the list of installed languages

The language is shown by a text (e.g. 'Use StarOffice in English', 'StarOffice auf Deutsch verwenden')

By selecting a text and clicking OK the user decides to use that language

Screenshot of Language selection dialog:

ToDo:

finish design of dialog

License Agreement

After the user has selected a language and the user installation has been finalized, a license dialog with the license text in the selected language is shown

if only one language is avalable (default case) the dialog is shown with the license text in that version since no language could be selected

The user not accept the license until he has scrolled all the way to the bottom of the text area

when the license is not accepted, office will exit. If started again, the license dialog will be shown.

Screenshot:

Readme

is a readme dialog to be displayed?

If yes, when?

Appendix2: Third party applications (TestTool)

Third party applications like the testtool have to find the StarOffice. In the cws networker2 we agreed, that the setup still writes a file named „sversion.ini“ (Windows) respectively „.sversionrc“ (Unix).

Some changes in the setup and in the testtool are needed, because this file has to be written during the standard (network) installation type.

The file sversion.ini (.sversionrc) will be created by the setup in the folder PREDEFINED_CONFIGDIR. PREDEFINED_CONFIGDIR will be defined as:

Windows:

single user install: <Application Data> folder for the current user.

all user install:	<Application Data> folder for all users.

network install:	<Application Data> folder for the current user.

UNIX / LINUX:

single user install: <home directory> of the current user.

all user install + root rights:	/etc/.

all user install without root rights:	<home directory> of the current user.

network install:	<home directory> of the current user.

To enable the testtool to find these directories also there is a new command in the testtool.

It works the same as the already existing command

String GetApplicationPath

which delivers the path for the single user and the network install.

String GetCommonApplicationPath

delivers the path for an all user installation.

In order to find the installation place of an office it would then be necessary to check both locations for an appropriate file with appropriate content.

Ingo Schmidt

2003-08-25T15:49:31

Ingo Schmidt