Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - help needed
Le 18/06/2013 09:26, Andrea Pescetti a écrit : On 17/06/2013 Oliver-Rainer Wittmann wrote: I want to let you know that I am currently working on the migration of AOO 3.4.x/OOo 3.x user profiles to AOO 4.0. I am also including the migration of extensions. I am currently not planning to adjust any of the mentioned strings as I think it is too late for its translation. Is this safe? In a typical scenario, then, a user would have some extensions installed and he would see them imported in 4.0 without being warned about possible compatibility problems. Most of the extensions do not have a maxversion indication, so OpenOffice 4.0 will try and install them anyway, but some might be broken. And then the user is left alone in updating his extensions (which in theory he should be prompted to do after installation, assuming this mechanism is restored), but he wouldn't have a way to go back before it's too late. Even if it's not that safe, since the new user profile will not overwrite the former (it's a major upgrade), the only risk is that it doesn't work and to reset completely the new profile (but the former one is untouched and is kept available). So we should at least try and hope that very few are broken. Thanks Oliver for your work on the profile migration, it would be a great feature for a smooth upgrade. Hagar - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - help needed
Hi, On 18.06.2013 17:20, Oliver-Rainer Wittmann wrote: Hi, On 18.06.2013 10:58, Oliver-Rainer Wittmann wrote: Hi On 28.05.2013 17:10, Oliver-Rainer Wittmann wrote: Hi, I would like to activate/introduce code which migrates certain user profile data from AOO 3.4.x and OOo 3.x installations during the reactivated FirstStartWizard when the user starts the first time an installed AOO 4.0. I have submitted two issues for this task: - 122398 for the reactivation of the FirstStartWizard [1] - 122397 for the code and configuration changes to migrate an AOO 3.4.x/OOo 3.x user profile [2] I have solved both tasks inclusive the migration of user-installed extensions. Unfortunately, my change causes build breaker on Mac OS and Linux. Root cause: My try to export a certain function from library deploymentgui.uno (module desktop) in order to use it in other libraries of module desktop failed under Mac OS and Linux. I am working on it. I asked Andre for help and he solved the problem - many kudos for Andre. Best regards, Oliver. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - help needed
On Wed, 19 Jun 2013 08:18:28 +0200 Andrea Pescetti wrote: > Rory O'Farrell wrote: > > On Tue, 18 Jun 2013 21:54:52 +0200 Andrea Pescetti wrote: > >> Ariel Constenla-Haile wrote: > >>> On Tue, Jun 18, 2013 at 5:21 AM, Oliver-Rainer Wittmann wrote: > Do you have one or two C++ extension at hand (except former Presenter > Screen > and former Presenation Minizer) for testing? > >>> The PDF Import extension: > >>> http://extensions.openoffice.org/en/project/pdfimport > >>> MySQL Connector: > >>> http://extensions.openoffice.org/en/project/mysql_connector > >>> My version of this last one: > >>> http://code.google.com/a/apache-extras.org/p/aoo-my-sdbc/ > >> This deserves some discussion: these two extensions are very popular so > >> it would be better to find a solution to this before users ask for > >> support in scores. > > For me, the absence of the Presenter Console would be a major barrier > > The "two extensions" I was referring to are: PDF Import and MySQL Connector. > > Presenter Console and Presentation Minimizer, as Oliver wrote, are > staying: they won't be packaged as extensions since they will be > directly integrated in OpenOffice. So their functionality will be > available in 4.0 with no changes and no need to update any extensions. > > Regards, >Andrea. > Thank you, Andrea; I obviously misunderstood the situation, for which I apologise. It is excellent news that the two Presenter extensions will be integrated into OpenOffice 4.0; Presenter Console, once demonstrated to a non OpenOffice User, often becomes a major factor in converting him to OpenOffice. -- Rory O'Farrell - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - help needed
Rory O'Farrell wrote: On Tue, 18 Jun 2013 21:54:52 +0200 Andrea Pescetti wrote: Ariel Constenla-Haile wrote: On Tue, Jun 18, 2013 at 5:21 AM, Oliver-Rainer Wittmann wrote: Do you have one or two C++ extension at hand (except former Presenter Screen and former Presenation Minizer) for testing? The PDF Import extension: http://extensions.openoffice.org/en/project/pdfimport MySQL Connector: http://extensions.openoffice.org/en/project/mysql_connector My version of this last one: http://code.google.com/a/apache-extras.org/p/aoo-my-sdbc/ This deserves some discussion: these two extensions are very popular so it would be better to find a solution to this before users ask for support in scores. For me, the absence of the Presenter Console would be a major barrier The "two extensions" I was referring to are: PDF Import and MySQL Connector. Presenter Console and Presentation Minimizer, as Oliver wrote, are staying: they won't be packaged as extensions since they will be directly integrated in OpenOffice. So their functionality will be available in 4.0 with no changes and no need to update any extensions. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - help needed
Hi On 18.06.2013 22:06, Rory O'Farrell wrote: On Tue, 18 Jun 2013 21:54:52 +0200 Andrea Pescetti wrote: Ariel Constenla-Haile wrote: On Tue, Jun 18, 2013 at 5:21 AM, Oliver-Rainer Wittmann wrote: Do you have one or two C++ extension at hand (except former Presenter Screen and former Presenation Minizer) for testing? The PDF Import extension: http://extensions.openoffice.org/en/project/pdfimport MySQL Connector: http://extensions.openoffice.org/en/project/mysql_connector My version of this last one: http://code.google.com/a/apache-extras.org/p/aoo-my-sdbc/ This deserves some discussion: these two extensions are very popular so it would be better to find a solution to this before users ask for support in scores. If I understand correctly, we have now have two problems with these extensions: 1) License: both extensions have GPL (or similar) dependencies, so they cannot be formally released by this Apache project. 2) Compatibility: the STLport change makes the latest versions incompatible with OpenOffice 4.0. Can the problem be solved by simply rebuilding the two extensions in the new framework? If it isn't too hard, it's better to upload an "unofficial" version (meaning: released by individual developers, but not officially by the project) to the Extensions site than dealing with feature limitations and support requests. For the time being, I updated http://wiki.openoffice.org/wiki/Extensions/Extensions_and_Apache_OpenOffice_4.0 with this information. Regards, Andrea. For me, the absence of the Presenter Console would be a major barrier to canverting my presentation laptops to AOO 4.0. I hope a way, even if not an official release, can be found to make this available more or less concurrently with the AOO 4.0 release. If Presentation Minimizer is being rewritten, some thought should be given towards adapting the code to provide a similar optimisation and reduction process for Writer documents; users often insert illustrations of considerably too higgh a resolution and size into Writer. A minimise process for this application wuld be useful. The Presenter Screen and the Presentation Minimizer have been integrated into OpenOffice as 'native' functions - Thanks to Ariel. Thus, the corresponding functionality is available in AOO 4.0. Best regards, Oliver. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - help needed
On Tue, 18 Jun 2013 21:54:52 +0200 Andrea Pescetti wrote: > Ariel Constenla-Haile wrote: > > On Tue, Jun 18, 2013 at 5:21 AM, Oliver-Rainer Wittmann wrote: > >> Do you have one or two C++ extension at hand (except former Presenter > >> Screen > >> and former Presenation Minizer) for testing? > > The PDF Import extension: > > http://extensions.openoffice.org/en/project/pdfimport > > MySQL Connector: http://extensions.openoffice.org/en/project/mysql_connector > > My version of this last one: > > http://code.google.com/a/apache-extras.org/p/aoo-my-sdbc/ > > This deserves some discussion: these two extensions are very popular so > it would be better to find a solution to this before users ask for > support in scores. > > If I understand correctly, we have now have two problems with these > extensions: > 1) License: both extensions have GPL (or similar) dependencies, so they > cannot be formally released by this Apache project. > 2) Compatibility: the STLport change makes the latest versions > incompatible with OpenOffice 4.0. > > Can the problem be solved by simply rebuilding the two extensions in the > new framework? If it isn't too hard, it's better to upload an > "unofficial" version (meaning: released by individual developers, but > not officially by the project) to the Extensions site than dealing with > feature limitations and support requests. > > For the time being, I updated > http://wiki.openoffice.org/wiki/Extensions/Extensions_and_Apache_OpenOffice_4.0 > with this information. > > Regards, >Andrea. > For me, the absence of the Presenter Console would be a major barrier to canverting my presentation laptops to AOO 4.0. I hope a way, even if not an official release, can be found to make this available more or less concurrently with the AOO 4.0 release. If Presentation Minimizer is being rewritten, some thought should be given towards adapting the code to provide a similar optimisation and reduction process for Writer documents; users often insert illustrations of considerably too higgh a resolution and size into Writer. A minimise process for this application wuld be useful. -- Rory O'Farrell - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - help needed
Ariel Constenla-Haile wrote: On Tue, Jun 18, 2013 at 5:21 AM, Oliver-Rainer Wittmann wrote: Do you have one or two C++ extension at hand (except former Presenter Screen and former Presenation Minizer) for testing? The PDF Import extension: http://extensions.openoffice.org/en/project/pdfimport MySQL Connector: http://extensions.openoffice.org/en/project/mysql_connector My version of this last one: http://code.google.com/a/apache-extras.org/p/aoo-my-sdbc/ This deserves some discussion: these two extensions are very popular so it would be better to find a solution to this before users ask for support in scores. If I understand correctly, we have now have two problems with these extensions: 1) License: both extensions have GPL (or similar) dependencies, so they cannot be formally released by this Apache project. 2) Compatibility: the STLport change makes the latest versions incompatible with OpenOffice 4.0. Can the problem be solved by simply rebuilding the two extensions in the new framework? If it isn't too hard, it's better to upload an "unofficial" version (meaning: released by individual developers, but not officially by the project) to the Extensions site than dealing with feature limitations and support requests. For the time being, I updated http://wiki.openoffice.org/wiki/Extensions/Extensions_and_Apache_OpenOffice_4.0 with this information. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - help needed
Hi, On 18.06.2013 10:58, Oliver-Rainer Wittmann wrote: Hi On 28.05.2013 17:10, Oliver-Rainer Wittmann wrote: Hi, I would like to activate/introduce code which migrates certain user profile data from AOO 3.4.x and OOo 3.x installations during the reactivated FirstStartWizard when the user starts the first time an installed AOO 4.0. I have submitted two issues for this task: - 122398 for the reactivation of the FirstStartWizard [1] - 122397 for the code and configuration changes to migrate an AOO 3.4.x/OOo 3.x user profile [2] I have solved both tasks inclusive the migration of user-installed extensions. Unfortunately, my change causes build breaker on Mac OS and Linux. Root cause: My try to export a certain function from library deploymentgui.uno (module desktop) in order to use it in other libraries of module desktop failed under Mac OS and Linux. I am working on it. Best regards, Oliver. As the translation deadline has passed I have made no string changes. Please provide feedback from your tests once a snapshot build or a buildbot build including these changes is available. Best regards, Oliver. In the last days I had a look at the user profile migration code and its configuration. I figured out how it works in general. Further investigation is needed to figure out, if and how the existing service to 'migrate' installed extensions works. I am currently not sure, if the automatic user profile migration should try to install extensions from a former version. My current preference is not to migrate extension from a former version. I need support and help with the migration of the user profile: (A) To figure out and test the user profile migration 'real-life' user profiles or 'early-alpha-testers' would be welcome. Thus, send my your AOO 3.4.x or OOo 3.x user profile in a compressed form (.zip file or .tar.gz file or ...) or let me know, if you want to try my builds. (B) The first page of the FirstStartWizard is a general welcome containing the following en-US strings. String "This wizard will guide you through the license agreement, the transfer of user data from %OLD_VERSION and the registration of %PRODUCTNAME.", if a user profile for a migration is found, and string "This wizard will guide you through the registration of %PRODUCTNAME." otherwise. Since at least OOo 3.2 no license agreement was shown --> no text for a license agreement is needed on the welcome page. Since AOO 3.4 we do not have a registration --> no text for a registration has to be shown. Thus, I am asking for new string proposals for the welcome page of the FirstStartWizard. I have attached screenshots of the currently deactivated FirstStartWizard. [1] https://issues.apache.org/ooo/show_bug.cgi?id=122398 [2] https://issues.apache.org/ooo/show_bug.cgi?id=122397 Thanks in advance, Oliver. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - help needed
On 6/18/13 2:17 PM, Oliver-Rainer Wittmann wrote: > Hi, > > On 18.06.2013 13:36, Rob Weir wrote: >> On Tue, Jun 18, 2013 at 3:51 AM, Oliver-Rainer Wittmann >> wrote: >>> Hi, >>> >>> >>> On 18.06.2013 09:26, Andrea Pescetti wrote: On 17/06/2013 Oliver-Rainer Wittmann wrote: > > I want to let you know that I am currently working on the migration of > AOO 3.4.x/OOo 3.x user profiles to AOO 4.0. I am also including the > migration of extensions. > I am currently not planning to adjust any of the mentioned strings > as I > think it is too late for its translation. Is this safe? In a typical scenario, then, a user would have some extensions installed and he would see them imported in 4.0 without being warned about possible compatibility problems. Most of the extensions do not have a maxversion indication, so OpenOffice 4.0 will try and install them anyway, but some might be broken. And then the user is left alone in updating his extensions (which in theory he should be prompted to do after installation, assuming this mechanism is restored), but he wouldn't have a way to go back before it's too late. >>> >>> I had a close look at the functionality to 'migrate the extensions >>> from a >>> former user profile' and from my point of view we should give it a try. >>> >>> The function did the following: >>> It looks for the extensions which are installed for the user. These are >>> found in the former user profile. No shared-installed, bundled or >>> pre-registered extensions are considered. The found user-installed >>> extensions which are not on the blacklist are installed with the same >>> mechanism which is used when the users triggers in the installation. >>> I am activating an user interaction in case that an extension is already >>> installed - the same user interaction which is used when the user >>> triggers >>> the installation of an already installed extension. >>> >>> On the blacklist will be the Presenter Screen and the Presentation >>> Minimizer >>> as they are now integrated into OpenOffice. >>> >> >> Is the blacklist a static list? Or is it something that can be >> retried/updated from the website? >> > > The blacklist is part of our source code. These are corresponding > entries in a XCU file - namely > main/officecfg/registry/data/org/openoffice/Setup.xcu > Have a look at my commit - revision 1494066 [1]. Search for > 'ExcludedExtensions' > > [1] http://svn.apache.org/r1494066 > >> If we can make the blacklist be "live" in a document that we can >> update, this is like maintaining our own max version field for the >> cases where the extension author neglected to do so. >> > > Such a feature is possible. > It could be corresponding XML feed which OpenOffice could be accessed > via the Internet - like the XML feed for the update service. before we implement further features in the context of the extension manager I would like to propose a complete review of the current design. That means analyze what we have today and we want to provide reliable tomorrow and rework the code according the new requirements. This means mainly a simplification of the current implementation to make it more better maintainable, more robust and easier to understand. The first feature that I would drop is the live deployment that is a nice feature but not worth the complexity that it brings in the code. A clean office restart after the installation should be no problem. We need also a better and cleaner way to handle and deploy bundled extensions like dictionaries etc. I would like to avoid the installation in the user home directory... Many more things come into my mind. The blacklist was of course not intended to be used to manage a big list of extensions. Juergen > > Best regards, Oliver. > >> -Rob >> >> >>> >>> > If my tests work fine, I will check-in the changes this week. If we > will > include these changes into our AOO 4.0 release, I will help to update > the above wiki page. Let's keep them documented and see. Remember that we learned so far that a random user will manage to reinstall but not to do anything more elaborated, so if uninstallation/installation does not bring up a "Do you want to reset your profile?" dialog we still have a usability problem (which of course is not a regression, it's been there forever). >>> >>> Agreed. >>> >>> >>> Best regards, Oliver. >>> >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >>> For additional commands, e-mail: dev-h...@openoffice.apache.org >>> >> >> >> >> -- >> Opinions expressed in this communication reflect the author's >> individual personal view, not necessarily that of an amorphous >> collective. The above statements do not reflect an official position >> of any organization, corporation, religion
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - help needed
Hi, On 18.06.2013 13:36, Rob Weir wrote: On Tue, Jun 18, 2013 at 3:51 AM, Oliver-Rainer Wittmann wrote: Hi, On 18.06.2013 09:26, Andrea Pescetti wrote: On 17/06/2013 Oliver-Rainer Wittmann wrote: I want to let you know that I am currently working on the migration of AOO 3.4.x/OOo 3.x user profiles to AOO 4.0. I am also including the migration of extensions. I am currently not planning to adjust any of the mentioned strings as I think it is too late for its translation. Is this safe? In a typical scenario, then, a user would have some extensions installed and he would see them imported in 4.0 without being warned about possible compatibility problems. Most of the extensions do not have a maxversion indication, so OpenOffice 4.0 will try and install them anyway, but some might be broken. And then the user is left alone in updating his extensions (which in theory he should be prompted to do after installation, assuming this mechanism is restored), but he wouldn't have a way to go back before it's too late. I had a close look at the functionality to 'migrate the extensions from a former user profile' and from my point of view we should give it a try. The function did the following: It looks for the extensions which are installed for the user. These are found in the former user profile. No shared-installed, bundled or pre-registered extensions are considered. The found user-installed extensions which are not on the blacklist are installed with the same mechanism which is used when the users triggers in the installation. I am activating an user interaction in case that an extension is already installed - the same user interaction which is used when the user triggers the installation of an already installed extension. On the blacklist will be the Presenter Screen and the Presentation Minimizer as they are now integrated into OpenOffice. Is the blacklist a static list? Or is it something that can be retried/updated from the website? The blacklist is part of our source code. These are corresponding entries in a XCU file - namely main/officecfg/registry/data/org/openoffice/Setup.xcu Have a look at my commit - revision 1494066 [1]. Search for 'ExcludedExtensions' [1] http://svn.apache.org/r1494066 If we can make the blacklist be "live" in a document that we can update, this is like maintaining our own max version field for the cases where the extension author neglected to do so. Such a feature is possible. It could be corresponding XML feed which OpenOffice could be accessed via the Internet - like the XML feed for the update service. Best regards, Oliver. -Rob If my tests work fine, I will check-in the changes this week. If we will include these changes into our AOO 4.0 release, I will help to update the above wiki page. Let's keep them documented and see. Remember that we learned so far that a random user will manage to reinstall but not to do anything more elaborated, so if uninstallation/installation does not bring up a "Do you want to reset your profile?" dialog we still have a usability problem (which of course is not a regression, it's been there forever). Agreed. Best regards, Oliver. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- Opinions expressed in this communication reflect the author's individual personal view, not necessarily that of an amorphous collective. The above statements do not reflect an official position of any organization, corporation, religion (organized or disorganized) or national football association. The contents of said note are not guaranteed to have been spell checked, grammar checked or reviewed for metrical infelicities. The contents of this post may not be suitable for those whose native language is not logic. Caution should be exercised when operating heavy machinery when reading this note, or even when not reading it. Seriously, heavy machinery is dangerous. Be careful. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - help needed
On Tue, Jun 18, 2013 at 3:51 AM, Oliver-Rainer Wittmann wrote: > Hi, > > > On 18.06.2013 09:26, Andrea Pescetti wrote: >> >> On 17/06/2013 Oliver-Rainer Wittmann wrote: >>> >>> I want to let you know that I am currently working on the migration of >>> AOO 3.4.x/OOo 3.x user profiles to AOO 4.0. I am also including the >>> migration of extensions. >>> I am currently not planning to adjust any of the mentioned strings as I >>> think it is too late for its translation. >> >> >> Is this safe? In a typical scenario, then, a user would have some >> extensions installed and he would see them imported in 4.0 without being >> warned about possible compatibility problems. Most of the extensions do >> not have a maxversion indication, so OpenOffice 4.0 will try and install >> them anyway, but some might be broken. And then the user is left alone >> in updating his extensions (which in theory he should be prompted to do >> after installation, assuming this mechanism is restored), but he >> wouldn't have a way to go back before it's too late. >> > > I had a close look at the functionality to 'migrate the extensions from a > former user profile' and from my point of view we should give it a try. > > The function did the following: > It looks for the extensions which are installed for the user. These are > found in the former user profile. No shared-installed, bundled or > pre-registered extensions are considered. The found user-installed > extensions which are not on the blacklist are installed with the same > mechanism which is used when the users triggers in the installation. > I am activating an user interaction in case that an extension is already > installed - the same user interaction which is used when the user triggers > the installation of an already installed extension. > > On the blacklist will be the Presenter Screen and the Presentation Minimizer > as they are now integrated into OpenOffice. > Is the blacklist a static list? Or is it something that can be retried/updated from the website? If we can make the blacklist be "live" in a document that we can update, this is like maintaining our own max version field for the cases where the extension author neglected to do so. -Rob > > >>> If my tests work fine, I will check-in the changes this week. If we will >>> include these changes into our AOO 4.0 release, I will help to update >>> the above wiki page. >> >> >> Let's keep them documented and see. Remember that we learned so far that >> a random user will manage to reinstall but not to do anything more >> elaborated, so if uninstallation/installation does not bring up a "Do >> you want to reset your profile?" dialog we still have a usability >> problem (which of course is not a regression, it's been there forever). >> > > Agreed. > > > Best regards, Oliver. > > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > -- Opinions expressed in this communication reflect the author's individual personal view, not necessarily that of an amorphous collective. The above statements do not reflect an official position of any organization, corporation, religion (organized or disorganized) or national football association. The contents of said note are not guaranteed to have been spell checked, grammar checked or reviewed for metrical infelicities. The contents of this post may not be suitable for those whose native language is not logic. Caution should be exercised when operating heavy machinery when reading this note, or even when not reading it. Seriously, heavy machinery is dangerous. Be careful. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - help needed
On 6/15/13 10:21 AM, Andrea Pescetti wrote: > On 14/06/2013 Hans Zybura wrote: >> Therefore I'd like to recommend some additions > > Thank you, integrated in > > http://wiki.openoffice.org/wiki/Extensions/Extensions_and_Apache_OpenOffice_4.0 > > >> One last time I want to comment on Jürgen Schmidt's recommendation to >> define >> a Maxversion. > > Indicating a "max" version will ensure that the extension is only run on > OpenOffice version it has been tested on. But I've changed (back) the > wording to "Typical" and "Recommended", which is quite accurate, since > I've never seen the "max" version being used in practice. If one prefers > to do like Hagar and not set a "max" version, this can probably be > addressed (but I cannot check now) by editing the Release page on the > extensions.openoffice.org site and simply adding that it is compatible > with version 4.0. Extension developers can do of course whatever they want. My recommendation is to test an extension against the next coming version (whatever it is, major or minor) and release a new micro update of the extension with an updated max version. This can be done as part of a QA process and it will ensure that the extensions will work and it will avoid problems. If you sell your extension it is up to you to distribute it, you can give micro extensions for free. Many extension will work without a max version dependency but we have seen problems here in the past and that is the reason why I recommend the max version now. Juergen > > Regards, > Andrea. > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - help needed
Hi On 28.05.2013 17:10, Oliver-Rainer Wittmann wrote: Hi, I would like to activate/introduce code which migrates certain user profile data from AOO 3.4.x and OOo 3.x installations during the reactivated FirstStartWizard when the user starts the first time an installed AOO 4.0. I have submitted two issues for this task: - 122398 for the reactivation of the FirstStartWizard [1] - 122397 for the code and configuration changes to migrate an AOO 3.4.x/OOo 3.x user profile [2] I have solved both tasks inclusive the migration of user-installed extensions. As the translation deadline has passed I have made no string changes. Please provide feedback from your tests once a snapshot build or a buildbot build including these changes is available. Best regards, Oliver. In the last days I had a look at the user profile migration code and its configuration. I figured out how it works in general. Further investigation is needed to figure out, if and how the existing service to 'migrate' installed extensions works. I am currently not sure, if the automatic user profile migration should try to install extensions from a former version. My current preference is not to migrate extension from a former version. I need support and help with the migration of the user profile: (A) To figure out and test the user profile migration 'real-life' user profiles or 'early-alpha-testers' would be welcome. Thus, send my your AOO 3.4.x or OOo 3.x user profile in a compressed form (.zip file or .tar.gz file or ...) or let me know, if you want to try my builds. (B) The first page of the FirstStartWizard is a general welcome containing the following en-US strings. String "This wizard will guide you through the license agreement, the transfer of user data from %OLD_VERSION and the registration of %PRODUCTNAME.", if a user profile for a migration is found, and string "This wizard will guide you through the registration of %PRODUCTNAME." otherwise. Since at least OOo 3.2 no license agreement was shown --> no text for a license agreement is needed on the welcome page. Since AOO 3.4 we do not have a registration --> no text for a registration has to be shown. Thus, I am asking for new string proposals for the welcome page of the FirstStartWizard. I have attached screenshots of the currently deactivated FirstStartWizard. [1] https://issues.apache.org/ooo/show_bug.cgi?id=122398 [2] https://issues.apache.org/ooo/show_bug.cgi?id=122397 Thanks in advance, Oliver. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - help needed
On Tue, Jun 18, 2013 at 5:21 AM, Oliver-Rainer Wittmann wrote: >>> On the blacklist will be the Presenter Screen and the Presentation >>> Minimizer as they are now integrated into OpenOffice. >> >> >> These wouldn't work anyway; after the STLport change, former C++ >> extensions do not work on Windows and Linux 32 bit (I guess also in >> MacOS, as this affects 32 bit archs, where stlport was used). If there >> is a way to tell the migration service not to migrate C++ (excepting Linux >> 64 bit), it might be good to turn this option on. >> >> > > I do not know of such an option. > Do you know how this can be found out by observing the extension? > > Do you have one or two C++ extension at hand (except former Presenter Screen > and former Presenation Minizer) for testing? The PDF Import extension: http://extensions.openoffice.org/en/project/pdfimport MySQL Connector: http://extensions.openoffice.org/en/project/mysql_connector My version of this last one: http://code.google.com/a/apache-extras.org/p/aoo-my-sdbc/ Regards - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - help needed
Hi, On 18.06.2013 10:05, Ariel Constenla-Haile wrote: On Tue, Jun 18, 2013 at 09:51:46AM +0200, Oliver-Rainer Wittmann wrote: On the blacklist will be the Presenter Screen and the Presentation Minimizer as they are now integrated into OpenOffice. These wouldn't work anyway; after the STLport change, former C++ extensions do not work on Windows and Linux 32 bit (I guess also in MacOS, as this affects 32 bit archs, where stlport was used). If there is a way to tell the migration service not to migrate C++ (excepting Linux 64 bit), it might be good to turn this option on. I do not know of such an option. Do you know how this can be found out by observing the extension? Do you have one or two C++ extension at hand (except former Presenter Screen and former Presenation Minizer) for testing? Thanks in advance, Oliver. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - help needed
On Tue, Jun 18, 2013 at 09:51:46AM +0200, Oliver-Rainer Wittmann wrote: > On the blacklist will be the Presenter Screen and the Presentation > Minimizer as they are now integrated into OpenOffice. These wouldn't work anyway; after the STLport change, former C++ extensions do not work on Windows and Linux 32 bit (I guess also in MacOS, as this affects 32 bit archs, where stlport was used). If there is a way to tell the migration service not to migrate C++ (excepting Linux 64 bit), it might be good to turn this option on. Regards -- Ariel Constenla-Haile La Plata, Argentina pgppfSt_h2C2t.pgp Description: PGP signature
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - help needed
Hi, On 18.06.2013 09:26, Andrea Pescetti wrote: On 17/06/2013 Oliver-Rainer Wittmann wrote: I want to let you know that I am currently working on the migration of AOO 3.4.x/OOo 3.x user profiles to AOO 4.0. I am also including the migration of extensions. I am currently not planning to adjust any of the mentioned strings as I think it is too late for its translation. Is this safe? In a typical scenario, then, a user would have some extensions installed and he would see them imported in 4.0 without being warned about possible compatibility problems. Most of the extensions do not have a maxversion indication, so OpenOffice 4.0 will try and install them anyway, but some might be broken. And then the user is left alone in updating his extensions (which in theory he should be prompted to do after installation, assuming this mechanism is restored), but he wouldn't have a way to go back before it's too late. I had a close look at the functionality to 'migrate the extensions from a former user profile' and from my point of view we should give it a try. The function did the following: It looks for the extensions which are installed for the user. These are found in the former user profile. No shared-installed, bundled or pre-registered extensions are considered. The found user-installed extensions which are not on the blacklist are installed with the same mechanism which is used when the users triggers in the installation. I am activating an user interaction in case that an extension is already installed - the same user interaction which is used when the user triggers the installation of an already installed extension. On the blacklist will be the Presenter Screen and the Presentation Minimizer as they are now integrated into OpenOffice. If my tests work fine, I will check-in the changes this week. If we will include these changes into our AOO 4.0 release, I will help to update the above wiki page. Let's keep them documented and see. Remember that we learned so far that a random user will manage to reinstall but not to do anything more elaborated, so if uninstallation/installation does not bring up a "Do you want to reset your profile?" dialog we still have a usability problem (which of course is not a regression, it's been there forever). Agreed. Best regards, Oliver. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - help needed
On 17/06/2013 Oliver-Rainer Wittmann wrote: I want to let you know that I am currently working on the migration of AOO 3.4.x/OOo 3.x user profiles to AOO 4.0. I am also including the migration of extensions. I am currently not planning to adjust any of the mentioned strings as I think it is too late for its translation. Is this safe? In a typical scenario, then, a user would have some extensions installed and he would see them imported in 4.0 without being warned about possible compatibility problems. Most of the extensions do not have a maxversion indication, so OpenOffice 4.0 will try and install them anyway, but some might be broken. And then the user is left alone in updating his extensions (which in theory he should be prompted to do after installation, assuming this mechanism is restored), but he wouldn't have a way to go back before it's too late. If my tests work fine, I will check-in the changes this week. If we will include these changes into our AOO 4.0 release, I will help to update the above wiki page. Let's keep them documented and see. Remember that we learned so far that a random user will manage to reinstall but not to do anything more elaborated, so if uninstallation/installation does not bring up a "Do you want to reset your profile?" dialog we still have a usability problem (which of course is not a regression, it's been there forever). Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - help needed
Hi, On 13.06.2013 23:44, Andrea Pescetti wrote: On 05/06/2013 Hagar Delest wrote: There has been a lot of posts in that discussion, even some proposals but we are approaching the 4.0 release and I've not seen a single warning for the extensions authors about the changes needed or any proposal to warn users. I've started a wiki page at http://wiki.openoffice.org/wiki/Extensions/Extensions_and_Apache_OpenOffice_4.0 It's still incomplete, and I hope that developers with knowledge may step in and fill in the gaps. It is meant to be a resource that we will want to advertise in the release notes and make available to users when they seek support, so please have a look, and feel free to improve and complete it. I want to let you know that I am currently working on the migration of AOO 3.4.x/OOo 3.x user profiles to AOO 4.0. I am also including the migration of extensions. I am currently not planning to adjust any of the mentioned strings as I think it is too late for its translation. If my tests work fine, I will check-in the changes this week. If we will include these changes into our AOO 4.0 release, I will help to update the above wiki page. Best regards, Oliver. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - help needed
On 14/06/2013 Hans Zybura wrote: Therefore I'd like to recommend some additions Thank you, integrated in http://wiki.openoffice.org/wiki/Extensions/Extensions_and_Apache_OpenOffice_4.0 One last time I want to comment on Jürgen Schmidt's recommendation to define a Maxversion. Indicating a "max" version will ensure that the extension is only run on OpenOffice version it has been tested on. But I've changed (back) the wording to "Typical" and "Recommended", which is quite accurate, since I've never seen the "max" version being used in practice. If one prefers to do like Hagar and not set a "max" version, this can probably be addressed (but I cannot check now) by editing the Release page on the extensions.openoffice.org site and simply adding that it is compatible with version 4.0. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - help needed
Le 14/06/2013 12:14, Hans Zybura a écrit : Or see it this way: For an extension author like me, AOO is functioning similar to another layer of an operating system. So please ask yourself in analogy: Would any of the AOO developers want to define for AOO 4.0 a Maxversion like ? I don't think so. And whatever the reasons may be, the same reasons apply in the reasoning of an extension developers. Good analogy indeed! With Firefox extensions, I had to set the max version to 99 to avoid having them deactivated at each upgrade (required the tweaking of the configuration files of each extension). I think that they changed the behavior so that they are by default re-used at upgrade now, they have listened to their users. A max version is too much troubles. What version to set? The current one? The next major one? We don't know what will be the changes in the future so how to determine the max version? Hagar - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - help needed
Andrea, first I'd like to thank you for starting this web-page! OO Developers tend to have a somewhat limited view of the large variety of scenarios, how , why, and by whom extensions are created and maintained. Please note that the extension repository, although it is certainly a great source of extensions, is by far not the only one, even not the most important one. E.g. commercial extensions are mostly not downloadable via the extension repository, but the publishers may be advertising their solution there. But the vast amount of extensions existing will not even be publicly visible/available, because they are created for companies small and large, or privately for a friend/oneself. Therefore I'd like to recommend some additions (sorry for my limited English): For commercial extensions, please contact the publisher for support. In case an extension is not publicly available, but only used privately or in your company/institution, please ask either the author of your extension or a person responsible in your company/institution for help. Please note: If a certain extension is crucial for your personal or professional workflow, you should not install AOO 4.0 before having made sure that this extension will work on AOO 4.0 or that an update of the extension is available. One last time I want to comment on Jürgen Schmidt's recommendation to define a Maxversion. Maybe there are special cases, where this is feasible, e.g. in a (not to small) company where you are able to guarantee availability of support at any time. In some very special cases (from my POV) it may even be vital to do that. So defining a Maxversion may be seen as an important option at hand. That does not say that it has to be recommended as best practice or even mandatory. The word "deprecated" seems to imply the latter. A commercial solution simply cannot afford to define a Maxversion, because users would understand this to be a predetermined breaking point for making more money only. Customers are very suspicious in this regard because of the ever shortening life cycle of technical hardware products nowadays. Or see it this way: For an extension author like me, AOO is functioning similar to another layer of an operating system. So please ask yourself in analogy: Would any of the AOO developers want to define for AOO 4.0 a Maxversion like ? I don't think so. And whatever the reasons may be, the same reasons apply in the reasoning of an extension developers. Kind regards, Hans > -Original Message- > From: Andrea Pescetti [mailto:pesce...@apache.org] > Sent: Thursday, June 13, 2013 11:45 PM > To: dev@openoffice.apache.org > Subject: Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - > help needed > > On 05/06/2013 Hagar Delest wrote: > > There has been a lot of posts in that discussion, even some proposals > > but we are approaching the 4.0 release and I've not seen a single > > warning for the extensions authors about the changes needed or any > > proposal to warn users. > > I've started a wiki page at > > http://wiki.openoffice.org/wiki/Extensions/Extensions_and_Apache_Open > Office_4.0 > > It's still incomplete, and I hope that developers with knowledge may step in > and fill in the gaps. > > It is meant to be a resource that we will want to advertise in the release > notes and make available to users when they seek support, so please have a > look, and feel free to improve and complete it. > > Regards, >Andrea. > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - help needed
On 05/06/2013 Hagar Delest wrote: There has been a lot of posts in that discussion, even some proposals but we are approaching the 4.0 release and I've not seen a single warning for the extensions authors about the changes needed or any proposal to warn users. I've started a wiki page at http://wiki.openoffice.org/wiki/Extensions/Extensions_and_Apache_OpenOffice_4.0 It's still incomplete, and I hope that developers with knowledge may step in and fill in the gaps. It is meant to be a resource that we will want to advertise in the release notes and make available to users when they seek support, so please have a look, and feel free to improve and complete it. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - help needed
Le 05/06/2013 15:25, Andre Fischer a écrit : I think that you are mixing up your arguments. You may be right. - This thread seems to be a 'discussion' between developers---extensions developers and core developers---not between users and developers. I know. I stepped in because of a reply that I see very often and that should be used rather carefully IMHO. - You imply that there are only two options: complain and then program an improvement or just shut up. But there are others. For example if you don't like the background color of a button then you don't have to be a programmer to propose another color. Constructive criticism can have many forms. Writing source code is just one of them. There was a thread about the problem some time ago. I even was the one who launched it (after being criticized because I'd raised the problem in another topic, which was however related). There has been a lot of posts in that discussion, even some proposals but we are approaching the 4.0 release and I've not seen a single warning for the extensions authors about the changes needed or any proposal to warn users. I used "shut up" because the discussion went into limbos, nobody really cared. That's a way to dismiss one's comments and the underlying message is: "just do it or stop bothering us". And about this problem (extensions), I don't see what else can be done except coding, we are not talking about buttons color. And again in this very discussion, the message is clear: don't complain, join the development team. Perhaps you think it's just criticism but I think it's constructive criticism. That's more than 7 years that I visit the forums everyday and I know the users. I can easily guess what the level of frustration will be when users will notice that some of their extensions have been deactivated. So, if an extension developer criticizes a technical decision it seems reasonable to ask that developer to propose a better alternative. It does not have to be fully implemented but something a little more constructive than just a complaint would be nice. That, as far as I understand it, is one aspect of the Apache Way. As said above, the topic has been raised 4 months ago. Alternative were proposed. See: http://www.mail-archive.com/dev@openoffice.apache.org/msg04066.html Hagar - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - help needed
Hi, I'm sorry, I don't have the time to follow every post on the dev and api mailings lists. Being an add-in and extension developer for Microsoft Office and OpenOffice and having a well working add-in/extension for both in place, I normally only need to scan the lists once a week or so for relevant topics. The whole of my AOO extension activities, including support for users of our extension based product, is planned to take about 3% of my working time, in accordance to how much said extension contributes to my sales numbers and income. That's how my working life is organized. When I happen to read this: > >> small wrap-up at the top: - nobody prefers to migrate extensions from > >> AOO 3.4.x resp. OOo 3.x in conjunction with the obviously outdated and rather crude information about release planning here: https://cwiki.apache.org/OOOUSERS/aoo-40-release-planning.html it seems totally clear to me that nothing can change your "nobody prefers to migrate extensions" in time. I will be delighted if I'm proved to be wrong, in which case I will gladly test the migration of our extension, and - if needed - open a bug report on bugzilla and help with resolving issues. You know, from my point of view, the whole thread, starting only 5 days *after* the proposed date of RC1, left me speechless for a while, when I detected it. It had never occurred to me that in a project of this dimension one could even think about a new major release without careful and timely consideration of migration processes. The way this is handled looks very much like chaos to me, and I tend to no longer trust in AOO to be a serious, long-term, and reliable project. If this really is the Apache way of project management, it is nothing I want to get used to. As a side note: my Windows and MacOS users don't "migrate", they wouldn't understand this geeky word. They are able to install a new software version, which is sort of a nuisance in itself for most of them. Afterwards, they expect to see everything in place like before. For most of the programs I use, I'm just such an end user myself. I expect those programs to install/update and then look and feel mostly like before or maybe a bit better, if I'm lucky. The last thing I want to be *told* is what I have to *do* for a proper "migration". I realize that my stern remarks go partly to the wrong person. For this I apologize. Regards, Hans > From: Oliver-Rainer Wittmann [mailto:orwittm...@googlemail.com] > Sent: Wednesday, June 05, 2013 12:05 PM > Hi Hans Zybura, > > On 04.06.2013 19:26, Hans Zybura wrote: > > Hi, comments inline... > > > > Crosspost to the api mailing list for a reason. > > > > Regards, Hans Zybura > > > >> -Original Message- From: Oliver-Rainer Wittmann > >> [mailto:orwittm...@googlemail.com] Sent: Monday, June 03, 2013 > >> 10:47 AM To: dev@openoffice.apache.org Subject: Re: [AOO 4.0]: > >> migration of AOO 3.4.x/OOo 3.x user profile data - help needed > >> > >> Hi, > >> > > > > A couple of month ago there was a heated dispute about introducing > > incompatible changes for extensions in the addons.xcu (for negligible > > benefit). One of the arguments meant to silence the critics was: > > Well, it's no problem because we have an update mechanism for > > extensions. I expressed doubts if the update mechanism would work. > > Now it turns out I was wrong. I shouldn't have worried about the > > update mechanism. Without migration, users will have to find and > > reinstall all of their extensions anyway "by hand". > > > > May be I should have said: > "Until now, nobody prefers to migrate extensions from AOO 3.4.x resp. > OOo 3.x". > > > The current update mechanism for extensions simply looks for a newer > > version of the extension by use of a link provided by the extension > > developer himself. We did that for our extension, but didn't have to > > make use of it until now. > > > > OO developers decided not to take into account compatibility issues > > caused by introducing incompatible changes in addons.xcu. OK, so we > > have to deal with it. To prevent any trouble for our customers, we > > could very likely have provided an automatic update, so that an end > > user wouldn't have noticed any problem at all after a successful > > migration. > > > > Now OO developers are about to make it impossible for extension > > developers to simply provide an automatic update before or after the > > migration to AOO 4.0. Without migrating extensions, there is no > > automatic update path anymore. > > > > Great use
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - help needed
On 04.06.2013 23:28, Hagar Delest wrote: Le 04/06/2013 22:47, Juergen Schmidt a écrit : Well I am getting tired to repeat this again and again. Nobody should expect that others do what's necessary, Just do it yourself -> it's a community project. That's the problem. It seems there are different levels of understanding for the "community". You tend to think that there is a huge community backing AOO and ready to jump into the code and other areas. I think that the reality is quite different: there is a huge base of users. But only users; wanting the application to work without having to put the hands inside. Let's face it: there are very few with dev skills; so you can't tell "just do it". What if we can't do it? Just shut up? If we shut up, nobody else will care about the users. Hagar, I think that you are mixing up your arguments. - This thread seems to be a 'discussion' between developers---extensions developers and core developers---not between users and developers. - You imply that there are only two options: complain and then program an improvement or just shut up. But there are others. For example if you don't like the background color of a button then you don't have to be a programmer to propose another color. Constructive criticism can have many forms. Writing source code is just one of them. So, if an extension developer criticizes a technical decision it seems reasonable to ask that developer to propose a better alternative. It does not have to be fully implemented but something a little more constructive than just a complaint would be nice. That, as far as I understand it, is one aspect of the Apache Way. -Andre - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - help needed
Hi Hans Zybura, On 04.06.2013 19:26, Hans Zybura wrote: Hi, comments inline... Crosspost to the api mailing list for a reason. Regards, Hans Zybura -Original Message- From: Oliver-Rainer Wittmann [mailto:orwittm...@googlemail.com] Sent: Monday, June 03, 2013 10:47 AM To: dev@openoffice.apache.org Subject: Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - help needed Hi, small wrap-up at the top: - nobody prefers to migrate extensions from AOO 3.4.x resp. OOo 3.x A couple of month ago there was a heated dispute about introducing incompatible changes for extensions in the addons.xcu (for negligible benefit). One of the arguments meant to silence the critics was: Well, it's no problem because we have an update mechanism for extensions. I expressed doubts if the update mechanism would work. Now it turns out I was wrong. I shouldn't have worried about the update mechanism. Without migration, users will have to find and reinstall all of their extensions anyway "by hand". May be I should have said: "Until now, nobody prefers to migrate extensions from AOO 3.4.x resp. OOo 3.x". The current update mechanism for extensions simply looks for a newer version of the extension by use of a link provided by the extension developer himself. We did that for our extension, but didn't have to make use of it until now. OO developers decided not to take into account compatibility issues caused by introducing incompatible changes in addons.xcu. OK, so we have to deal with it. To prevent any trouble for our customers, we could very likely have provided an automatic update, so that an end user wouldn't have noticed any problem at all after a successful migration. Now OO developers are about to make it impossible for extension developers to simply provide an automatic update before or after the migration to AOO 4.0. Without migrating extensions, there is no automatic update path anymore. Great user experience! Great experience for extension developers and support folks! I remember much talk about the "eco system of AOO" on this mailing list. Is this what the talk was about? I tried to get involved certain people on this topic. I had send my intial post to dev@o.a.o and users@o.a.o. Sorry, that I did not include api@o.a.o as I assumed that extension developers are looking at dev@o.a.o. The intention of this thread was not to present facts regarding the development. It is meant to show on what I would like to work on for AOO 4.0 regarding the migration of the user profile and to get feedback on it. (BTW, I had already started a discussion thread in January 2013 regarding the migration of the user profile - see thread "[IMPORTANT, DISCUSS]: no migration/use of former user profile with AOO 4.0".) I used terms like "I would like to ...", "My current preference is ..." and "I need support and help ..." - I am not presenting facts. I explicitly ask for help for these tasks. I got no response and no feedback from users@o.a.o. I was disappointed about it, because it means that nobody from users@o.a.o seems to be interested to help/support me. From dev@o.a.o I only got feedback about the risks of a user profile migration and that nobody prefers a migration of the extensions. I have taken your feedback as not constructive criticsm. Your feedback sounds like that I decided that extensions will not be migrated. That is not the case. Earlier in January I already started a similar discussion - see above mentioned thread. Here, no strong preferences regarding the migration of extensions were given. In this thread I expressed my willingness to work on the migration of the user profile (which also contains the user installed extensions), otherwise nothing will be migrated as stated in January. As this is not a one-person show I asked for help and support. The only feedback I got was that a migration might be risky and no one has preference to migrate extensions. Then I got your feedback which more or less killed my motivation to work on the migration of the user profile. May be you are volunteering to support me as you seem to be interested in a working migration of the user profile? Best regards, (a disappointed) Oliver. more comments inline. On 02.06.2013 13:17, Andrea Pescetti wrote: On 29/05/2013 Oliver-Rainer Wittmann wrote: On 28.05.2013 18:23, Rob Weir wrote: Do we need to worry about the "messy" profiles that occurred from OOo 3.3.0 upgrades to AOO 3.4.0? That was when we saw spell checking breaking, missing dictionaries, and crashes. One of the nice things about a "clean start" with AOO 4.0 was that we avoid these kinds of problems. From my point of view AOO 3.4.x users which had problems due to a "messy" profile and had solved these problems, can migrate their profile to AOO 4.0. AOO 3.4.x users which does not had solved their pro
RE: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - help needed
> From: Juergen Schmidt [mailto:jogischm...@gmail.com] > Sent: Tuesday, June 04, 2013 8:27 PM > Am Dienstag, 4. Juni 2013 um 19:26 schrieb Hans Zybura: > > Hi, comments inline... > > > > Crosspost to the api mailing list for a reason. > > > > Regards, Hans Zybura > > > > > From: Oliver-Rainer Wittmann [mailto:orwittm...@googlemail.com] > > > Sent: Monday, June 03, 2013 10:47 AM > > > > > > Hi, > > > > > > small wrap-up at the top: > > > - nobody prefers to migrate extensions from AOO 3.4.x resp. OOo 3.x > > > > > > > > > A couple of month ago there was a heated dispute about introducing > incompatible changes for extensions in the addons.xcu (for negligible > benefit). One of the arguments meant to silence the critics was: Well, it's no > problem because we have an update mechanism for extensions. I expressed > doubts if the update mechanism would work. Now it turns out I was wrong. I > shouldn't have worried about the update mechanism. Without migration, > users will have to find and reinstall all of their extensions anyway "by > hand". > > > > The current update mechanism for extensions simply looks for a newer > version of the extension by use of a link provided by the extension > developer himself. We did that for our extension, but didn't have to make > use of it until now. > it is of course an open issue that the update mechanism for extensions from > the repo doesn't work. We have to address this with our friends from > sourgeforge. I didn't speak about the repository. We don't rely on the repository, we are using our own server. > > > > OO developers decided not to take into account compatibility issues caused > by introducing incompatible changes in addons.xcu. OK, so we have to deal > with it. To prevent any trouble for our customers, we could very likely have > provided an automatic update, so that an end user wouldn't have noticed > any problem at all after a successful migration. > the decision to do no migration of extension is based on the fact that we had > problems with the user profile for AOO 3.4.x. We simply take this root to get > a clean new profile for the future. > > > > Now OO developers are about to make it impossible for extension > developers to simply provide an automatic update before or after the > migration to AOO 4.0. Without migrating extensions, there is no automatic > update path anymore. > this is not optimal but a one time shot only > > > > Great user experience! Great experience for extension developers and > support folks! > no it isn't but sometimes unpopular decision are useful to move forward. > And a major release is the chance for such changes. > > > > > > I remember much talk about the "eco system of AOO" on this mailing list. Is > this what the talk was about? > instead of complaining and requesting you could have joined the > development and could have worked on one or more of your addressed > issues. This is the way how open source works. The code is available and you > can help to improve it. In my professional role as an extension developer I am perfectly able to deal with the consequences of your decisions, only that this doesn't make them any better. I'm not complaining, I'm not requesting "that things get be done". Please stop using such a lame line of defense for your lack of leadership with respect to endorsing user friendliness. I'm just pointing out consequences for user experience and extension development. All I ever really did request was: Don't break things that work Open source project or not, any kind of project needs leadership. Your position makes you a leader, but with respect to user friendliness you are not up to it. Hans Zybura > > Juergen > > > > > > > > more comments inline. > > > > > > On 02.06.2013 13:17, Andrea Pescetti wrote: > > > > On 29/05/2013 Oliver-Rainer Wittmann wrote: > > > > > On 28.05.2013 18:23, Rob Weir wrote: > > > > > > Do we need to worry about the "messy" profiles that occurred > > > > > > from OOo > > > > > > 3.3.0 upgrades to AOO 3.4.0? That was when we saw spell > > > > > > checking breaking, missing dictionaries, and crashes. One of > > > > > > the nice things about a "clean start" with AOO 4.0 was that we > > > > > > avoid these kinds of problems. > > > > > > > > > > > > > > > > From my point of view AOO 3.4.x users which had problems due to > > > > > a "messy" profile and had solved these problems, can migrate > > > > > their profile to AOO 4.0. AOO 3.4.x users which does not had > > > > > solved their problems are able to suppress the migration of > > > > > their existing profile > > > > > - see the corresponding FirstStartWizard page for the user > > > > > profile > > > > > > > > > > > > > > > > > > > migration. > > > > > > > > I agree with Rob here that, since we had only a few widely > > > > reported bugs in OpenOffice 3.4.1 and one of them depended on the > > > > profile migration, we should be rather conservative. > > > > > > > > I agree it's better not to migrate extensions, sinc
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - help needed
2013/6/4 Hans Zybura : > Hi, comments inline... > > Crosspost to the api mailing list for a reason. > > Regards, Hans Zybura > >> -Original Message- >> From: Oliver-Rainer Wittmann [mailto:orwittm...@googlemail.com] >> Sent: Monday, June 03, 2013 10:47 AM >> To: dev@openoffice.apache.org >> Subject: Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - >> help needed >> >> Hi, >> >> small wrap-up at the top: >> - nobody prefers to migrate extensions from AOO 3.4.x resp. OOo 3.x > > A couple of month ago there was a heated dispute about introducing > incompatible changes for extensions in the addons.xcu (for negligible > benefit). One of the arguments meant to silence the critics was: Well, it's > no problem because we have an update mechanism for extensions. I expressed > doubts if the update mechanism would work. Now it turns out I was wrong. I > shouldn't have worried about the update mechanism. Without migration, users > will have to find and reinstall all of their extensions anyway "by hand". > > The current update mechanism for extensions simply looks for a newer version > of the extension by use of a link provided by the extension developer > himself. We did that for our extension, but didn't have to make use of it > until now. > > OO developers decided not to take into account compatibility issues caused by > introducing incompatible changes in addons.xcu. OK, so we have to deal with > it. To prevent any trouble for our customers, we could very likely have > provided an automatic update, so that an end user wouldn't have noticed any > problem at all after a successful migration. > > Now OO developers are about to make it impossible for extension developers to > simply provide an automatic update before or after the migration to AOO 4.0. > Without migrating extensions, there is no automatic update path anymore. AOOE beta-test site has already the update feature in place, we plan to go live with the beta test sometimes next week, so that we'll have a couple of weeks to test it extensively before AOO 4.0. Hope this helps. Roberto > Great user experience! Great experience for extension developers and support > folks! > > I remember much talk about the "eco system of AOO" on this mailing list. Is > this what the talk was about? > >> >> more comments inline. >> >> On 02.06.2013 13:17, Andrea Pescetti wrote: >> > On 29/05/2013 Oliver-Rainer Wittmann wrote: >> >> On 28.05.2013 18:23, Rob Weir wrote: >> >>> Do we need to worry about the "messy" profiles that occurred from >> >>> OOo >> >>> 3.3.0 upgrades to AOO 3.4.0? That was when we saw spell checking >> >>> breaking, missing dictionaries, and crashes. One of the nice things >> >>> about a "clean start" with AOO 4.0 was that we avoid these kinds of >> >>> problems. >> >> From my point of view AOO 3.4.x users which had problems due to a >> >> "messy" profile and had solved these problems, can migrate their >> >> profile to AOO 4.0. AOO 3.4.x users which does not had solved their >> >> problems are able to suppress the migration of their existing profile >> >> - see the corresponding FirstStartWizard page for the user profile >> migration. >> > >> > I agree with Rob here that, since we had only a few widely reported >> > bugs in OpenOffice 3.4.1 and one of them depended on the profile >> > migration, we should be rather conservative. >> > >> > I agree it's better not to migrate extensions, since some of them >> > might not work in OpenOffice 4 and their description.xml file in most >> > cases will only state that they need "OpenOffice 3.0 or later". >> > >> >> Yes, an easy reset of the user profile would be great. >> > >> > This would be a very welcome improvement. Maybe technically this could >> > invalidate the current profile and ask the user to restart OpenOffice, >> > which would start on a clean profile. This would offer a good user >> > experience (not optimal, since the optimal one would be triggered by a >> > reinstallation too), and the right moment for the cleanup would be >> > just after the code that checks if FirstStartWizard must be run and >> > just before the profile is loaded and locked (which means that the >> > "invalidate" bit must be set in a way that does not require profile >> > access but probably a simple filesystem access... OK, I'll stop
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - help needed
On 6/4/13 11:28 PM, Hagar Delest wrote: > Le 04/06/2013 22:47, Juergen Schmidt a écrit : >> Well I am getting tired to repeat this again and again. Nobody should >> expect that others do what's necessary, Just do it yourself -> it's a >> community project. > That's the problem. It seems there are different levels of understanding > for the "community". > > You tend to think that there is a huge community backing AOO and ready > to jump into the code and other areas. don't think that I am so stupid but we have enough things to do where people without development skills can help and can do something. And please don't generalize this, we talked with extension developers. There are of course different groups of extension developers, with different skill levels. For me it's a difference if somebody who don't have the skills but shows interest and ask the right questions or if somebody complain and request that things get be done. > I think that the reality is quite different: there is a huge base of > users. But only users; wanting the application to work without having to > put the hands inside. I hope we always have a bigger user base than active community members. Otherwise it would be a bad ratio but I agree that we could benefit fro more volunteers in all areas. > > > Let's face it: there are very few with dev skills; so you can't tell > "just do it". What if we can't do it? Just shut up? > If we shut up, nobody else will care about the users. Nobody say that anybody should shut up. We talk here about one specific case and not in general. Really anybody interested could have started on the communication part. Juergen > > Hagar > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - help needed
Hagar Delest wrote: NB: has a communication been made to the extension authors asking them to update their extension with the detailed changes to be made? What is the idea for the moment? Hope that they will do that by themselves because they certainly monitor the dev mailing list? This is very important and it shows that indeed there are tasks that can only be done through cooperation. Only a few people have clear ideas on what exactly is changing in OpenOffice 4 regarding extensions: so, those with this knowledge, please start a wiki page named "Upgrading your extensions for OpenOffice 4" or something like that. Then, once that page is started, other community members can take over, point extensions authors to that page, we can ask to e-mail authors, we can refer users to that page, some extension authors will comment and improve the resource... but we need this to be started with something that is more descriptive than a list of Bugzilla issues. Developers needn't do everything, but the project needs them to start a documentation effort that can then be managed by others. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - help needed
Le 04/06/2013 22:47, Juergen Schmidt a écrit : Well I am getting tired to repeat this again and again. Nobody should expect that others do what's necessary, Just do it yourself -> it's a community project. That's the problem. It seems there are different levels of understanding for the "community". You tend to think that there is a huge community backing AOO and ready to jump into the code and other areas. I think that the reality is quite different: there is a huge base of users. But only users; wanting the application to work without having to put the hands inside. Let's face it: there are very few with dev skills; so you can't tell "just do it". What if we can't do it? Just shut up? If we shut up, nobody else will care about the users. Hagar - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - help needed
Am Dienstag, 4. Juni 2013 um 22:00 schrieb Hagar Delest: > Le 04/06/2013 20:27, Juergen Schmidt a écrit : > > instead of complaining and requesting you could have joined the development > > and could have worked on one or more of your addressed issues. This is the > > way how open source works. The code is available and you can help to > > improve it. > > > This is the standard reply of the devs community very often. a reply to an extension developer > Please remember that OpenOffice is a rather specific project with a user base > made of basic users, not developers. This is not a toy for geeks who want to > implement cool things. So if the users are really disappointed because they > are not taken care of, they will just leave and go to LibreOffice for example. > > you don't have to repeat this, I know it and we normally take all kind of feedback serious. It's simply that we have many things to do... > > Whatever the technical reason is, not taking into account the basic user > aspect is dangerous. There were ideas about having a transition phase but > nothing has really been made about that AFAIK. some pro active collaboration of extension developers would be welcome. We don't simple ignore but we can't do everything. > > > > > If voices like ours dare say so against the dev community, it's because we > think that the users deserve a minimal care to keep them interested in the > product. I doubt they would ever engage in such a discussion. So please don't > forget about them, even if you don't hear their voices apart ours. I agree and I expect the necessary collaboration from the extension developers. If they collaborate our users will be less affected. > > NB: has a communication been made to the extension authors asking them to > update their extension with the detailed changes to be made? > What is the idea for the moment? Hope that they will do that by themselves > because they certainly monitor the dev mailing list? > > I hope it will be addressed appropriately. I am not responsible for everything ;-) The facts are known and if somebody things it is not addressed yet just start working on it and don't wait that somebody else does it. Well I am getting tired to repeat this again and again. Nobody should expect that others do what's necessary, Just do it yourself -> it's a community project. Juergen > > Hagar > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > >
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - help needed
Le 04/06/2013 20:27, Juergen Schmidt a écrit : instead of complaining and requesting you could have joined the development and could have worked on one or more of your addressed issues. This is the way how open source works. The code is available and you can help to improve it. This is the standard reply of the devs community very often. Please remember that OpenOffice is a rather specific project with a user base made of basic users, not developers. This is not a toy for geeks who want to implement cool things. So if the users are really disappointed because they are not taken care of, they will just leave and go to LibreOffice for example. Whatever the technical reason is, not taking into account the basic user aspect is dangerous. There were ideas about having a transition phase but nothing has really been made about that AFAIK. If voices like ours dare say so against the dev community, it's because we think that the users deserve a minimal care to keep them interested in the product. I doubt they would ever engage in such a discussion. So please don't forget about them, even if you don't hear their voices apart ours. NB: has a communication been made to the extension authors asking them to update their extension with the detailed changes to be made? What is the idea for the moment? Hope that they will do that by themselves because they certainly monitor the dev mailing list? Hagar - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - help needed
Am Dienstag, 4. Juni 2013 um 19:26 schrieb Hans Zybura: > Hi, comments inline... > > Crosspost to the api mailing list for a reason. > > Regards, Hans Zybura > > > -Original Message- > > From: Oliver-Rainer Wittmann [mailto:orwittm...@googlemail.com] > > Sent: Monday, June 03, 2013 10:47 AM > > To: dev@openoffice.apache.org > > Subject: Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - > > help needed > > > > Hi, > > > > small wrap-up at the top: > > - nobody prefers to migrate extensions from AOO 3.4.x resp. OOo 3.x > > > > > A couple of month ago there was a heated dispute about introducing > incompatible changes for extensions in the addons.xcu (for negligible > benefit). One of the arguments meant to silence the critics was: Well, it's > no problem because we have an update mechanism for extensions. I expressed > doubts if the update mechanism would work. Now it turns out I was wrong. I > shouldn't have worried about the update mechanism. Without migration, users > will have to find and reinstall all of their extensions anyway "by hand". > > The current update mechanism for extensions simply looks for a newer version > of the extension by use of a link provided by the extension developer > himself. We did that for our extension, but didn't have to make use of it > until now. it is of course an open issue that the update mechanism for extensions from the repo doesn't work. We have to address this with our friends from sourgeforge. > > OO developers decided not to take into account compatibility issues caused by > introducing incompatible changes in addons.xcu. OK, so we have to deal with > it. To prevent any trouble for our customers, we could very likely have > provided an automatic update, so that an end user wouldn't have noticed any > problem at all after a successful migration. the decision to do no migration of extension is based on the fact that we had problems with the user profile for AOO 3.4.x. We simply take this root to get a clean new profile for the future. > > Now OO developers are about to make it impossible for extension developers to > simply provide an automatic update before or after the migration to AOO 4.0. > Without migrating extensions, there is no automatic update path anymore. this is not optimal but a one time shot only > > Great user experience! Great experience for extension developers and support > folks! no it isn't but sometimes unpopular decision are useful to move forward. And a major release is the chance for such changes. > > > I remember much talk about the "eco system of AOO" on this mailing list. Is > this what the talk was about? instead of complaining and requesting you could have joined the development and could have worked on one or more of your addressed issues. This is the way how open source works. The code is available and you can help to improve it. Juergen > > > > > more comments inline. > > > > On 02.06.2013 13:17, Andrea Pescetti wrote: > > > On 29/05/2013 Oliver-Rainer Wittmann wrote: > > > > On 28.05.2013 18:23, Rob Weir wrote: > > > > > Do we need to worry about the "messy" profiles that occurred from > > > > > OOo > > > > > 3.3.0 upgrades to AOO 3.4.0? That was when we saw spell checking > > > > > breaking, missing dictionaries, and crashes. One of the nice things > > > > > about a "clean start" with AOO 4.0 was that we avoid these kinds of > > > > > problems. > > > > > > > > > > > > > From my point of view AOO 3.4.x users which had problems due to a > > > > "messy" profile and had solved these problems, can migrate their > > > > profile to AOO 4.0. AOO 3.4.x users which does not had solved their > > > > problems are able to suppress the migration of their existing profile > > > > - see the corresponding FirstStartWizard page for the user profile > > > > > > > > > > > > > > migration. > > > > > > I agree with Rob here that, since we had only a few widely reported > > > bugs in OpenOffice 3.4.1 and one of them depended on the profile > > > migration, we should be rather conservative. > > > > > > I agree it's better not to migrate extensions, since some of them > > > might not work in OpenOffice 4 and their description.xml file in most > > > cases will only state that they need "OpenOffice 3.0 or later". > > > > > > > Yes, an easy reset of
RE: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - help needed
Hi, comments inline... Crosspost to the api mailing list for a reason. Regards, Hans Zybura > -Original Message- > From: Oliver-Rainer Wittmann [mailto:orwittm...@googlemail.com] > Sent: Monday, June 03, 2013 10:47 AM > To: dev@openoffice.apache.org > Subject: Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - > help needed > > Hi, > > small wrap-up at the top: > - nobody prefers to migrate extensions from AOO 3.4.x resp. OOo 3.x A couple of month ago there was a heated dispute about introducing incompatible changes for extensions in the addons.xcu (for negligible benefit). One of the arguments meant to silence the critics was: Well, it's no problem because we have an update mechanism for extensions. I expressed doubts if the update mechanism would work. Now it turns out I was wrong. I shouldn't have worried about the update mechanism. Without migration, users will have to find and reinstall all of their extensions anyway "by hand". The current update mechanism for extensions simply looks for a newer version of the extension by use of a link provided by the extension developer himself. We did that for our extension, but didn't have to make use of it until now. OO developers decided not to take into account compatibility issues caused by introducing incompatible changes in addons.xcu. OK, so we have to deal with it. To prevent any trouble for our customers, we could very likely have provided an automatic update, so that an end user wouldn't have noticed any problem at all after a successful migration. Now OO developers are about to make it impossible for extension developers to simply provide an automatic update before or after the migration to AOO 4.0. Without migrating extensions, there is no automatic update path anymore. Great user experience! Great experience for extension developers and support folks! I remember much talk about the "eco system of AOO" on this mailing list. Is this what the talk was about? > > more comments inline. > > On 02.06.2013 13:17, Andrea Pescetti wrote: > > On 29/05/2013 Oliver-Rainer Wittmann wrote: > >> On 28.05.2013 18:23, Rob Weir wrote: > >>> Do we need to worry about the "messy" profiles that occurred from > >>> OOo > >>> 3.3.0 upgrades to AOO 3.4.0? That was when we saw spell checking > >>> breaking, missing dictionaries, and crashes. One of the nice things > >>> about a "clean start" with AOO 4.0 was that we avoid these kinds of > >>> problems. > >> From my point of view AOO 3.4.x users which had problems due to a > >> "messy" profile and had solved these problems, can migrate their > >> profile to AOO 4.0. AOO 3.4.x users which does not had solved their > >> problems are able to suppress the migration of their existing profile > >> - see the corresponding FirstStartWizard page for the user profile > migration. > > > > I agree with Rob here that, since we had only a few widely reported > > bugs in OpenOffice 3.4.1 and one of them depended on the profile > > migration, we should be rather conservative. > > > > I agree it's better not to migrate extensions, since some of them > > might not work in OpenOffice 4 and their description.xml file in most > > cases will only state that they need "OpenOffice 3.0 or later". > > > >> Yes, an easy reset of the user profile would be great. > > > > This would be a very welcome improvement. Maybe technically this could > > invalidate the current profile and ask the user to restart OpenOffice, > > which would start on a clean profile. This would offer a good user > > experience (not optimal, since the optimal one would be triggered by a > > reinstallation too), and the right moment for the cleanup would be > > just after the code that checks if FirstStartWizard must be run and > > just before the profile is loaded and locked (which means that the > > "invalidate" bit must be set in a way that does not require profile > > access but probably a simple filesystem access... OK, I'll stop here!). > > > >> Thus, I assume that the risk of a defect or a regression is low when > >> solving issue 122398 and 122397 for AOO 4.0, except the issue which > >> would be "copied" from a "messy" user profile. > > > > This is a case to consider. So I would suggest to set the default > > answer to "Don't migrate" for extra safety, especially if we don't > > have an easy profile reset mechanism in place. > > I agree. > But it will cause translation effort - see screenshot of FirstStartWizard &g
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - help needed
Hi, small wrap-up at the top: - nobody prefers to migrate extensions from AOO 3.4.x resp. OOo 3.x more comments inline. On 02.06.2013 13:17, Andrea Pescetti wrote: On 29/05/2013 Oliver-Rainer Wittmann wrote: On 28.05.2013 18:23, Rob Weir wrote: Do we need to worry about the "messy" profiles that occurred from OOo 3.3.0 upgrades to AOO 3.4.0? That was when we saw spell checking breaking, missing dictionaries, and crashes. One of the nice things about a "clean start" with AOO 4.0 was that we avoid these kinds of problems. From my point of view AOO 3.4.x users which had problems due to a "messy" profile and had solved these problems, can migrate their profile to AOO 4.0. AOO 3.4.x users which does not had solved their problems are able to suppress the migration of their existing profile - see the corresponding FirstStartWizard page for the user profile migration. I agree with Rob here that, since we had only a few widely reported bugs in OpenOffice 3.4.1 and one of them depended on the profile migration, we should be rather conservative. I agree it's better not to migrate extensions, since some of them might not work in OpenOffice 4 and their description.xml file in most cases will only state that they need "OpenOffice 3.0 or later". Yes, an easy reset of the user profile would be great. This would be a very welcome improvement. Maybe technically this could invalidate the current profile and ask the user to restart OpenOffice, which would start on a clean profile. This would offer a good user experience (not optimal, since the optimal one would be triggered by a reinstallation too), and the right moment for the cleanup would be just after the code that checks if FirstStartWizard must be run and just before the profile is loaded and locked (which means that the "invalidate" bit must be set in a way that does not require profile access but probably a simple filesystem access... OK, I'll stop here!). Thus, I assume that the risk of a defect or a regression is low when solving issue 122398 and 122397 for AOO 4.0, except the issue which would be "copied" from a "messy" user profile. This is a case to consider. So I would suggest to set the default answer to "Don't migrate" for extra safety, especially if we don't have an easy profile reset mechanism in place. I agree. But it will cause translation effort - see screenshot of FirstStartWizard migration page [1] String "...If you do not want to reuse any settings in %PRODUCTNAME %PRODUCTVERSION, unmark the check box." will be change to "...If you do want to reuse settings in %PRODUCTNAME %PRODUCTVERSION, mark the check box." Thus, send my your AOO 3.4.x or OOo 3.x user profile in a compressed form (.zip file or .tar.gz file or ...) or let me know, if you want to try my builds. If you had a build available, it would be easier for the QA volunteers to test. Yes, that would be the best. I will make the changes on trunk. Then the buildbot builds and the snapshot builds can be tested. As all changes will contain the ID of the corresponding issue in the submit summary, it will be easy to revert these changes. [1] https://issues.apache.org/ooo/attachment.cgi?id=80738 Best regards, Oliver. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - help needed
On 29/05/2013 Oliver-Rainer Wittmann wrote: On 28.05.2013 18:23, Rob Weir wrote: Do we need to worry about the "messy" profiles that occurred from OOo 3.3.0 upgrades to AOO 3.4.0? That was when we saw spell checking breaking, missing dictionaries, and crashes. One of the nice things about a "clean start" with AOO 4.0 was that we avoid these kinds of problems. From my point of view AOO 3.4.x users which had problems due to a "messy" profile and had solved these problems, can migrate their profile to AOO 4.0. AOO 3.4.x users which does not had solved their problems are able to suppress the migration of their existing profile - see the corresponding FirstStartWizard page for the user profile migration. I agree with Rob here that, since we had only a few widely reported bugs in OpenOffice 3.4.1 and one of them depended on the profile migration, we should be rather conservative. I agree it's better not to migrate extensions, since some of them might not work in OpenOffice 4 and their description.xml file in most cases will only state that they need "OpenOffice 3.0 or later". Yes, an easy reset of the user profile would be great. This would be a very welcome improvement. Maybe technically this could invalidate the current profile and ask the user to restart OpenOffice, which would start on a clean profile. This would offer a good user experience (not optimal, since the optimal one would be triggered by a reinstallation too), and the right moment for the cleanup would be just after the code that checks if FirstStartWizard must be run and just before the profile is loaded and locked (which means that the "invalidate" bit must be set in a way that does not require profile access but probably a simple filesystem access... OK, I'll stop here!). Thus, I assume that the risk of a defect or a regression is low when solving issue 122398 and 122397 for AOO 4.0, except the issue which would be "copied" from a "messy" user profile. This is a case to consider. So I would suggest to set the default answer to "Don't migrate" for extra safety, especially if we don't have an easy profile reset mechanism in place. Thus, send my your AOO 3.4.x or OOo 3.x user profile in a compressed form (.zip file or .tar.gz file or ...) or let me know, if you want to try my builds. If you had a build available, it would be easier for the QA volunteers to test. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - help needed
Hi, On 28.05.2013 18:23, Rob Weir wrote: On Tue, May 28, 2013 at 11:10 AM, Oliver-Rainer Wittmann wrote: Hi, I would like to activate/introduce code which migrates certain user profile data from AOO 3.4.x and OOo 3.x installations during the reactivated FirstStartWizard when the user starts the first time an installed AOO 4.0. I have submitted two issues for this task: - 122398 for the reactivation of the FirstStartWizard [1] - 122397 for the code and configuration changes to migrate an AOO 3.4.x/OOo 3.x user profile [2] In the last days I had a look at the user profile migration code and its configuration. I figured out how it works in general. Further investigation is needed to figure out, if and how the existing service to 'migrate' installed extensions works. I am currently not sure, if the automatic user profile migration should try to install extensions from a former version. My current preference is not to migrate extension from a former version. I need support and help with the migration of the user profile: (A) To figure out and test the user profile migration 'real-life' user profiles or 'early-alpha-testers' would be welcome. Thus, send my your AOO 3.4.x or OOo 3.x user profile in a compressed form (.zip file or .tar.gz file or ...) or let me know, if you want to try my builds. Do we need to worry about the "messy" profiles that occurred from OOo 3.3.0 upgrades to AOO 3.4.0? That was when we saw spell checking breaking, missing dictionaries, and crashes. One of the nice things about a "clean start" with AOO 4.0 was that we avoid these kinds of problems. From my point of view AOO 3.4.x users which had problems due to a "messy" profile and had solved these problems, can migrate their profile to AOO 4.0. AOO 3.4.x users which does not had solved their problems are able to suppress the migration of their existing profile - see the corresponding FirstStartWizard page for the user profile migration. But maybe there is some good as well? Since we're unlikely to totally eliminate all profile errors forever, maybe as part of your changes you can an easy way for the user to reset their profile? Today it is quite complicated for the average user. It would be great if a user with profile problems could reinstall AOO and when they hit the wizard be prompted to either preserve their profile or initialize a fresh profile. Yes, an easy reset of the user profile would be great. I do not think that reinstallation of AOO will help to reset the user profile. The information that the FirstStartWizard had been run is stored inside the user profile data. Thus, a reinstallation will not bring the FirstStartWizard into life. I also do not think that the user profile can be reset during the FirstStartWizard as the application is already accessing (and locking) the user profile during this time. So there are really three scenarios on an install: 0) Fresh install, no previous version: start with new profile Works already. 1) Installing over an older version: migrate profile or not. This currently depends on the involved versions. (A) If new version does use the same user profile folder. --> The user profile from the former version is just used for the new version. No FirstStartWizard will popup. (B) If new version does use another user profile folder. --> the new version starts with a new profile. If a migration of the former user profile has been configured in the new version an activated FirstStartWizard would provide choice 'migrate or not'. 2) Installing over a current version: preserve current profile or not. Here the same applies as in scenario 1).(A) Of course, the same caution I raise with all last-minute features: let's make sure we have volunteers willing/able to test. I agree. The user profile migration functionality is available at least since OOo 3.0. It works for the migration of a OOo 2.x user profile. What is needed to activate it for the migration of a AOO 3.4.x/OOo 3.x user profile are the corresponding configuration entries which specify which part of the user profile data is migrated. The FirstStartWizard functionality is also available since a couple of OOo versions. Thus, I assume that the risk of a defect or a regression is low when solving issue 122398 and 122397 for AOO 4.0, except the issue which would be "copied" from a "messy" user profile. Best regards, Oliver. Regards, -Rob (B) The first page of the FirstStartWizard is a general welcome containing the following en-US strings. String "This wizard will guide you through the license agreement, the transfer of user data from %OLD_VERSION and the registration of %PRODUCTNAME.", if a user profile for a migration is found, and string "This wizard will guide you through the registration of %PRODUCTNAME." otherwise. Since at least OOo 3.2 no license agreement was shown --> no text for a license agreement is needed on the welcome page. Since AOO 3.4 we do not have a regis
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - help needed
On Tue, May 28, 2013 at 11:10 AM, Oliver-Rainer Wittmann wrote: > Hi, > > I would like to activate/introduce code which migrates certain user profile > data from AOO 3.4.x and OOo 3.x installations during the reactivated > FirstStartWizard when the user starts the first time an installed AOO 4.0. > I have submitted two issues for this task: > - 122398 for the reactivation of the FirstStartWizard [1] > - 122397 for the code and configuration changes to migrate an AOO 3.4.x/OOo > 3.x user profile [2] > > In the last days I had a look at the user profile migration code and its > configuration. I figured out how it works in general. > > Further investigation is needed to figure out, if and how the existing > service to 'migrate' installed extensions works. I am currently not sure, if > the automatic user profile migration should try to install extensions from a > former version. My current preference is not to migrate extension from a > former version. > > > I need support and help with the migration of the user profile: > > (A) To figure out and test the user profile migration 'real-life' user > profiles or 'early-alpha-testers' would be welcome. > Thus, send my your AOO 3.4.x or OOo 3.x user profile in a compressed form > (.zip file or .tar.gz file or ...) or let me know, if you want to try my > builds. > Do we need to worry about the "messy" profiles that occurred from OOo 3.3.0 upgrades to AOO 3.4.0? That was when we saw spell checking breaking, missing dictionaries, and crashes. One of the nice things about a "clean start" with AOO 4.0 was that we avoid these kinds of problems. But maybe there is some good as well? Since we're unlikely to totally eliminate all profile errors forever, maybe as part of your changes you can an easy way for the user to reset their profile? Today it is quite complicated for the average user. It would be great if a user with profile problems could reinstall AOO and when they hit the wizard be prompted to either preserve their profile or initialize a fresh profile. So there are really three scenarios on an install: 0) Fresh install, no previous version: start with new profile 1) Installing over an older version: migrate profile or not. 2) Installing over a current version: preserve current profile or not. Of course, the same caution I raise with all last-minute features: let's make sure we have volunteers willing/able to test. Regards, -Rob > (B) The first page of the FirstStartWizard is a general welcome containing > the following en-US strings. > String "This wizard will guide you through the license agreement, the > transfer of user data from %OLD_VERSION and the registration of > %PRODUCTNAME.", if a user profile for a migration is found, and string "This > wizard will guide you through the registration of %PRODUCTNAME." otherwise. > Since at least OOo 3.2 no license agreement was shown --> no text for a > license agreement is needed on the welcome page. > Since AOO 3.4 we do not have a registration --> no text for a registration > has to be shown. > Thus, I am asking for new string proposals for the welcome page of the > FirstStartWizard. > I have attached screenshots of the currently deactivated FirstStartWizard. > > [1] https://issues.apache.org/ooo/show_bug.cgi?id=122398 > [2] https://issues.apache.org/ooo/show_bug.cgi?id=122397 > > > Thanks in advance, > Oliver. > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - help needed
Hi Oliver, Hi all, 2013/5/28 Oliver-Rainer Wittmann [...] I am currently not sure, if the automatic user profile migration should try > to install extensions from a former version. My current preference is not > to migrate extension from a former version. > I think it's better so. A+ -- gw > > >
[AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - help needed
Hi, I would like to activate/introduce code which migrates certain user profile data from AOO 3.4.x and OOo 3.x installations during the reactivated FirstStartWizard when the user starts the first time an installed AOO 4.0. I have submitted two issues for this task: - 122398 for the reactivation of the FirstStartWizard [1] - 122397 for the code and configuration changes to migrate an AOO 3.4.x/OOo 3.x user profile [2] In the last days I had a look at the user profile migration code and its configuration. I figured out how it works in general. Further investigation is needed to figure out, if and how the existing service to 'migrate' installed extensions works. I am currently not sure, if the automatic user profile migration should try to install extensions from a former version. My current preference is not to migrate extension from a former version. I need support and help with the migration of the user profile: (A) To figure out and test the user profile migration 'real-life' user profiles or 'early-alpha-testers' would be welcome. Thus, send my your AOO 3.4.x or OOo 3.x user profile in a compressed form (.zip file or .tar.gz file or ...) or let me know, if you want to try my builds. (B) The first page of the FirstStartWizard is a general welcome containing the following en-US strings. String "This wizard will guide you through the license agreement, the transfer of user data from %OLD_VERSION and the registration of %PRODUCTNAME.", if a user profile for a migration is found, and string "This wizard will guide you through the registration of %PRODUCTNAME." otherwise. Since at least OOo 3.2 no license agreement was shown --> no text for a license agreement is needed on the welcome page. Since AOO 3.4 we do not have a registration --> no text for a registration has to be shown. Thus, I am asking for new string proposals for the welcome page of the FirstStartWizard. I have attached screenshots of the currently deactivated FirstStartWizard. [1] https://issues.apache.org/ooo/show_bug.cgi?id=122398 [2] https://issues.apache.org/ooo/show_bug.cgi?id=122397 Thanks in advance, Oliver. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
