Issue 122398

Summary: reactivate FirstStartWizard for AOO 4.0
Product: Installation Reporter: Oliver-Rainer Wittmann <orw>
Component: codeAssignee: Oliver-Rainer Wittmann <orw>
Status: CLOSED FIXED QA Contact:
Severity: Normal    
Priority: P3 CC: awf.aoo, issues
Version: 4.0.0-dev   
Target Milestone: 4.0.0   
Hardware: All   
OS: All   
Issue Type: ENHANCEMENT Latest Confirmation in: ---
Developer Difficulty: ---
Issue Depends on:    
Issue Blocks: 122397, 123140    
Attachments:
Description Flags
Welcome page (no user profile for migration found)
none
user data page
none
migration page
none
Welcome page (user profile for migration found) none

Description Oliver-Rainer Wittmann 2013-05-28 13:09:25 UTC
Reactivate the currently deactivated FirstStartWizard for AOO 4.0

Reasons:
- It welcomes the user to the new version and allows the user to input some user data (full name and initials)
- The migration of certain user profile data from former AOO/OOo versions is part of the FirstStartWizard - it blocks bug 122397
Comment 1 Oliver-Rainer Wittmann 2013-05-28 14:57:50 UTC
Created attachment 80736 [details]
Welcome page (no user profile for migration found)

welcome page of (currently deactivated) FirstStartWizard when no user profile for migration is found
Comment 2 Oliver-Rainer Wittmann 2013-05-28 14:58:19 UTC
Created attachment 80737 [details]
user data page

user data page of (currently deactivated) FirstStartWizard
Comment 3 Oliver-Rainer Wittmann 2013-05-28 14:58:49 UTC
Created attachment 80738 [details]
migration page

migration page of (currently deactivated) FirstStartWizard
Comment 4 Oliver-Rainer Wittmann 2013-05-28 14:59:24 UTC
Created attachment 80739 [details]
Welcome page (user profile for migration found)

welcome page of (currently deactivated) FirstStartWizard when user profile for migration is found
Comment 5 Oliver-Rainer Wittmann 2013-06-18 08:11:20 UTC
solved on trunk for AOO 4.0 - revision 1494061
Comment 6 Andre 2013-06-19 15:45:33 UTC
The above changes cause the build to break on Mac and Linux.  Error message says that a symbol is defined twice.  This is triggered by one of the changes:

handleVersionException() was previously a local function defined in desktop/source/deployment/gui/dp_gui_extensioncmdqueue.cxx.  This function is now used in other places in desktop as well and had to be exported from its shared library.  The changes to export this function worked on Windows but not on Mac or Linux.

There seems to be more than one factor that prevented the function from being exported:

- The desktop/source/deployment/gui/makefile.mk used the generic map file solenv/src/component.map that only exports 
  component_getImplementationEnvironment
and 
  component_getFactory,
two methods that are exported by all libraries that only provide UNO services.

- The name of the library seems to be significant.  The line
   DLLPRE =
 (empty line after the =) prevented the library name from being prefixed with lib (on the *nix OS'ses).  But without that prefix the library can not properly linked.  Adding the library to the linker call with option -l does not work because that automatically adds the lib prefix.  The attempt to just remove the l and use -deploymentgui... failed silently and resulted in deploymentgui.uno.so not linked in at all.

- The line
SHL1LIBS = $(SLB)$/$(TARGET).lib
prevented handleVersionException() from being exported and/or linked as well.  The reason is unclear.
Comment 7 Andre 2013-06-19 15:56:07 UTC
Fixed the build breaker with revision 1494655.  Checked that the fix works on Mac and Linux (does not break the build and does not break the actual bug fix).  Windows build is running.  There may be some names that have to be adapted on Windows.


- Moved the handleVersionException() function to its own file desktop/source/deployment/gui/dp_gui_handleversionexception.cxx.

- Created local map file that exports the two functions for service factories
  component_getImplementationEnvironment
  component_getFactory
as well as
  handleVersionException

- Created dp_gui_api.hxx to define references to SAL_DLLPUBLIC_EXPORT and SAL_DLLPUBLIC_IMPORT.  Using these references to export the symbols that are listed in the map file (see above).

- Renamed the library to libdeploymentgui.uno.so.  Adapted scp2 accordingly.
  This change may not yet be handled gracefully (meaning it can cause another build breaker) on Windows.  But that should be easy to fix.

- Modified desktop/source/deployment/gui/makefile.mk to resemble .../misc/makefile.mk so that exporting symbols works better.