FOSDEM 2021 - OpenOffice UNO Programming with Groovy
I have uploaded my talk to YouTube also. https://youtu.be/izgFWgo0low Best regards, Carl - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Testing Beta versions
Hi David Thank you for volunteering your time! > I have a Macbook Pro and a Windows 10 box I can use for beta testing of new > Open office versions and as I am retired, I do have time to test English > versions of this great product. There is a Release Candidate of the upcoming 4.1.9 version which fixes some issues with MS Office documents under the MacOS You can find the Mac version here https://dist.apache.org/repos/dist/dev/openoffice/4.1.9-RC1/binaries/en-US/ If you feel more adventurous, you can test Development builds for the Windows OS here https://home.apache.org/~mseidel/AOO-builds/AOO-420-Test/ Please report any bugs on the tracker https://bz.apache.org/ooo/ Thank you! Best regards, Pedro - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Testing Beta versions
I have a Macbook Pro and a Windows 10 box I can use for beta testing of new Open office versions and as I am retired, I do have time to test English versions of this great product.
Re: [Discussion] Would we enable volunteers that develop extensions
Hi Jörg Overall I like your suggestion. Steve On 2/6/21 1:50 AM, Jörg Schmidt wrote: Hello, -Original Message- From: Steve Lubbs [mailto:stevelu...@gmail.com] Sent: Friday, February 05, 2021 9:54 PM To: dev@openoffice.apache.org Subject: Re: [Discussion] Would we enable volunteers that develop extensions Just a thought. As part of an effort to enable volunteer extension authors would it make sense to selectively approve extension functionality for inclusion into AOO on a case by case basis? If it provides a level of new functionality that is considered important and compelling, say something that is on the wish list and that no one has the time to pursue? For instance a PDF importer that was mentioned earlier. This is an interesting idea, which I had already mentioned myself (elsewhere). However, there is the experience of the past to consider, so that it is prevented that extensions, objectively as well as from subjective view of users, are regarded as emergency nail. It should not be allowed (technically) that AOO is delivered with an inflationary high number of _individual_ extensions, but there should be (also in view of the named purpose to transfer extension code later into core code) a kind of main extension as a container for the individual extensions, so that especially in the extension manager only the one main extension is visible. Of course, this requires some organization, i.e. that the extension programmers adhere to certain technical conditions, but this effort will pay off in the long run. As an experience value I can refer to the LiMux project (https://de.wikipedia.org/wiki/LiMux), in which I was involved professionally over many years, and was occupied there with the conversion of specialized applications and VBA macros to OOo extensions. At that time, there were very detailed specifications (size around 50 DIN-A4 pages) for the creation of extensions, which made integration into the overall project and maintenance much easier. Of course, we should be open to any programming languages within the extensions (there can also be so-called non-code extensions), but again I would like to mention: turning our gaze more towards Python would be quite beneficial, especially for extensions to be ported into the core code later. A step in this direction might be the development of an integrated Python IDE, parallel to the StarBasic IDE, in AOO. (I would like to emphasize that my personal Python knowledge is limited, so the above is not a personal preference, but a strategic consideration). With the author's permission and effort the extension could be ported to be core code rather than an extension. The author, upon agreeing to these conditions could be given the right of first refusal to be the maintainer of the code. There should also be a proviso that the author will to do the port. This, or some permutation, could be one way to reward extension authors for their efforts, provide incentive, I think it would also be a motivation to award membership in the PMC according to objective performance and not depending on the subjective opinion of individuals. greetings, Jörg - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
[GitHub] [openoffice] ardovm commented on pull request #122: Address bug 128356 and similar ones (duplicated XML attributes)
ardovm commented on pull request #122: URL: https://github.com/apache/openoffice/pull/122#issuecomment-774489872 Ok, I am done. Reviews welcome! This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
[GitHub] [openoffice] ardovm commented on pull request #122: Address bug 128356 and similar ones (duplicated XML attributes)
ardovm commented on pull request #122: URL: https://github.com/apache/openoffice/pull/122#issuecomment-774448450 Ok, the exception details are shown in non-product builds. Product builds just show an error message "Error saving the document: write error. Error in writing sub-document content.xml". I think it is enough to warn the user that the attempt to save the document has failed. Moreover, if I try to close the document, I am warned that it has not been saved. Please note that the above was checked with a "hand-inserted" exception, as the documents attached to the reports do not seem to trigger the bug any more. The PR is IMHO production-ready, but I would like to spend some more time on documentation. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: [Discussion] Would we enable volunteers that develop extensions
Hello, > -Original Message- > From: Steve Lubbs [mailto:stevelu...@gmail.com] > Sent: Friday, February 05, 2021 9:54 PM > To: dev@openoffice.apache.org > Subject: Re: [Discussion] Would we enable volunteers that > develop extensions > > Just a thought. > > As part of an effort to enable volunteer extension authors > would it make > sense to selectively approve extension functionality for > inclusion into > AOO on a case by case basis? If it provides a level of new > functionality > that is considered important and compelling, say something that is on > the wish list and that no one has the time to pursue? For > instance a PDF > importer that was mentioned earlier. This is an interesting idea, which I had already mentioned myself (elsewhere). However, there is the experience of the past to consider, so that it is prevented that extensions, objectively as well as from subjective view of users, are regarded as emergency nail. It should not be allowed (technically) that AOO is delivered with an inflationary high number of _individual_ extensions, but there should be (also in view of the named purpose to transfer extension code later into core code) a kind of main extension as a container for the individual extensions, so that especially in the extension manager only the one main extension is visible. Of course, this requires some organization, i.e. that the extension programmers adhere to certain technical conditions, but this effort will pay off in the long run. As an experience value I can refer to the LiMux project (https://de.wikipedia.org/wiki/LiMux), in which I was involved professionally over many years, and was occupied there with the conversion of specialized applications and VBA macros to OOo extensions. At that time, there were very detailed specifications (size around 50 DIN-A4 pages) for the creation of extensions, which made integration into the overall project and maintenance much easier. Of course, we should be open to any programming languages within the extensions (there can also be so-called non-code extensions), but again I would like to mention: turning our gaze more towards Python would be quite beneficial, especially for extensions to be ported into the core code later. A step in this direction might be the development of an integrated Python IDE, parallel to the StarBasic IDE, in AOO. (I would like to emphasize that my personal Python knowledge is limited, so the above is not a personal preference, but a strategic consideration). > With the author's permission and effort the extension could > be ported to > be core code rather than an extension. The author, upon agreeing to > these conditions could be given the right of first refusal to be the > maintainer of the code. There should also be a proviso that > the author > will to do the port. > > This, or some permutation, could be one way to reward > extension authors > for their efforts, provide incentive, I think it would also be a motivation to award membership in the PMC according to objective performance and not depending on the subjective opinion of individuals. greetings, Jörg - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
