Web pages 404
On this page: https://www.openoffice.org/porting/index.html there is a reference to "a port to OpenSolaris (Sparc) by Adfinis SyGroup AG (Nicolas Christener)": http://adfinis-sygroup.ch/aoo-solaris-sparc/ But that page is 404 and should probably be removed (unless anyone knows where it went). Same for this link directly below that one: http://www.opensolaris.org/ I think I'm going to try building 4.1.7 in Solaris 11.4 SPARC myself. - Michele
Re: need some feedback on source code page changes on project site...
Hi Kay, Am 09.02.20 um 21:02 schrieb Kay Schenk: > All done ( I think). Some former aspects of the CMS seem to be missing > but my changes got published. The staging area isn't working anymore. This is related to the permanent HTTPS redirection. But I can see everything online now. Thanks! Regards, Matthias > > HTH > > -- Kay > > > On 2/8/20 12:54 AM, Marcus wrote: >> Am 08.02.20 um 00:13 schrieb Andrea Pescetti: >>> On 06/02/2020 Kay Schenk wrote: http://home.apache.org/~kschenk/AOO_project_site/source.html >>> >>> Please go ahead and commit it. This is already better than the >>> current one. Then we may want to go through it (and especially >>> remove any references such as "as of August 2019": all we need to >>> say is that this is the current version). >>> >>> But we can definitely refine it in iterations once it is online. >> >> yes, just commit your changes and we will see what needs to be adjusted. >> >> Marcus >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >> For additional commands, e-mail: dev-h...@openoffice.apache.org >> > smime.p7s Description: S/MIME Cryptographic Signature
Re: need some feedback on source code page changes on project site...
All done ( I think). Some former aspects of the CMS seem to be missing but my changes got published. HTH -- Kay On 2/8/20 12:54 AM, Marcus wrote: Am 08.02.20 um 00:13 schrieb Andrea Pescetti: On 06/02/2020 Kay Schenk wrote: http://home.apache.org/~kschenk/AOO_project_site/source.html Please go ahead and commit it. This is already better than the current one. Then we may want to go through it (and especially remove any references such as "as of August 2019": all we need to say is that this is the current version). But we can definitely refine it in iterations once it is online. yes, just commit your changes and we will see what needs to be adjusted. Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: New Challange ODF 1.3 is out
On Sun, 9 Feb 2020 19:54:56 +0100 Regina Henschel wrote: > Hi Rory, > > Rory O'Farrell schrieb am 09-Feb-20 um 17:29: > > Is there a document from Oasis giving a synopsis of the changes from 1.2 to > > 1.3? This would give an idea of how much work was involved in the > > transition from 1.2. > > No, such synopsis does not exist. The committee candidate has an > appendix which lists the issues, which were incorporated, and the relax > schema has comments at the element/attributes by which issue they are > effected. > > Besides a lot of errata and clearing precedency of attributes and > clearing corner cases, I see these new things in ODF 1.3 for example: > several changes and additions in number formats > several additions to charts, e.g new kind of interpolation and of > regression curve > additional print option in Calc > PGP encryption > > Example of things implemented in AOO and now in ODF 1.3: > attribute table:tab-color (Calc) > element chart:coordinate-region > > You can compare the namespaces actually written by AOO with the > namespaces listed in the ODF 1.3 specification candidate. Then you look > in the core to which elements and attributes such own namespace is > written. Then you take that element or attribute and look in the > appendix of the ODF 1.3 specification, whether it is affected. > > Kind regards > Regina Thank you, Regina - a helpful summary. -- Rory O'Farrell - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: New Challange ODF 1.3 is out
Hi Rory, Rory O'Farrell schrieb am 09-Feb-20 um 17:29: Is there a document from Oasis giving a synopsis of the changes from 1.2 to 1.3? This would give an idea of how much work was involved in the transition from 1.2. No, such synopsis does not exist. The committee candidate has an appendix which lists the issues, which were incorporated, and the relax schema has comments at the element/attributes by which issue they are effected. Besides a lot of errata and clearing precedency of attributes and clearing corner cases, I see these new things in ODF 1.3 for example: several changes and additions in number formats several additions to charts, e.g new kind of interpolation and of regression curve additional print option in Calc PGP encryption Example of things implemented in AOO and now in ODF 1.3: attribute table:tab-color (Calc) element chart:coordinate-region You can compare the namespaces actually written by AOO with the namespaces listed in the ODF 1.3 specification candidate. Then you look in the core to which elements and attributes such own namespace is written. Then you take that element or attribute and look in the appendix of the ODF 1.3 specification, whether it is affected. Kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: New Challange ODF 1.3 is out
Hi Yuri, all > There ought to be some checking of how unified is the handling of the 1.2 > plain or extended between the LO and AOO. If I understand correctly only ODF 1.2 is a standard (OASIS and ISO), so creating a document with the same content on any software should result in identical files (only differing in the name of the software where it was produced) I believe ODF 1.2 Extended means each editor can extend as appropriate which can lead to inconsistencies (a bit like Microsoft's XML files only work perfectly if you are using exactly the same version as it was saved) > I remember seeing some differences already. I have found the same even in very simple documents. Again, if Extended means what I described, that is expected... So the only logic thing for AOO to do is to jump from 1.2 to 1.3 and forget about Extended? Or are there any Extended bits in AOO's format that need to be preserved (and are not included in 1.3)? Regards, Pedro - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: New Challange ODF 1.3 is out
Peter Kovacs-3 wrote > So I would like to focus on the Todos what we need to do in order to get > this done. > ... > Any more Ideas? There ought to be some checking of how unified is the handling of the 1.2 plain or extended between the LO and AOO. I remember seeing some differences already. Is there a testsuite for the file formats? -- Sent from: http://openoffice.2283327.n4.nabble.com/Development-f2916443.html - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: New Challange ODF 1.3 is out
Hello Regina, > -Original Message- > From: Regina Henschel [mailto:rb.hensc...@t-online.de] > Sent: Sunday, February 09, 2020 5:07 PM > To: dev@openoffice.apache.org > Subject: Re: New Challange ODF 1.3 is out > > Hi Jörg, > > Jörg Schmidt schrieb am 09-Feb-20 um 12:28: > > Hello, > [..] > > > > > I myself have been following the development of ODF from > the very beginning and I have to underline what you write, or > rather I have to take a critical look at the approach of the > TDF, because: > > > > In terms of a free, uniform format for office documents and > the declared intention to formulate this standard as an ISO > standard, it is regularly counterproductive for LO to deviate > from this and implement OASIS standard. so what? What is the problem _with going exactly the way you mentioned here_, but only updating the filters in the software when the ISO standard is published? > Without the help of TDF we would not have got the COSM > project and ODF > 1.3 would be far away from becoming a standard. > https://publicsoftware.eu/members/cosm-project/ ODF existed long before the TDF. Publication ODF 1.0: 1 May 2005 (OASIS), 3 May 2006 (ISO) Foundation of TDF: 28 September 2010 (announced), 17 February 2012 (officially established) By the way, I have no intention whatsoever of belittling the TFD's services to ODF, I am only criticising its actions in some details. greetings, Jörg - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: New Challange ODF 1.3 is out
On Sun, 9 Feb 2020 17:22:12 +0100 Peter Kovacs wrote: > My personal opinion in this matter is that it does not matter what > others do. All that counts is that ODF 1.3 is out. > > If others want to join the party everyone is welcome. If they do not > want to that is fine, too. > > I am personal very happy that the TDF has managed to organize this. And > I am excited to work on this. > > > So I would like to focus on the Todos what we need to do in order to get > this done. > > My fist Ideas would be: > > # compare 1.3with 1.2 or see if we get any other compares of changes. > > # Then we need to check what is covered by the 1.2 extended implementation. > > # 3 We need to make a plan what is to implement for 1.3 and make a > tracking list of features and tests to implement. > > > Any more Ideas? > > > All the Best > > Peter Is there a document from Oasis giving a synopsis of the changes from 1.2 to 1.3? This would give an idea of how much work was involved in the transition from 1.2. Rory > > On 09.02.20 12:28, Jörg Schmidt wrote: > > Hello, > > > >> -Original Message- > >> From: Pedro Lino [mailto:pedro.l...@mailbox.org] > >> Sent: Sunday, February 09, 2020 11:51 AM > >> To: dev@openoffice.apache.org > >> Subject: Re: New Challange ODF 1.3 is out > >> > >> Hi Peter, all > >> > >>> Just a heads up. On FOSDEM I learned that TDF managed to > >> raise money and > >>> do the work for ODF v 1.3. > >> I believe this is a quite relevant announcement! > >> > >> If ODF 1.3 is only used by a single Office suite then it will > >> no longer be "software independent" which IMHO defeats the > >> purpose of an Open Document format... > >> On the other hand given that ODF 1.3 is currently not an ISO > >> standard, Microsoft will not care about it until it is (in > >> fact they are making sure that ODF is not used at all) > >> > >> This will also isolate AOO since Open Documents will only > >> travel in one direction without feature loss (much like what > >> happens now with Microsoft's XML formats) > > You described it very well. > > > > I myself have been following the development of ODF from the very beginning > > and I have to underline what you write, or rather I have to take a critical > > look at the approach of the TDF, because: > > > > In terms of a free, uniform format for office documents and the declared > > intention to formulate this standard as an ISO standard, it is regularly > > counterproductive for LO to deviate from this and implement OASIS standard. > > > > We all know what to think about MS in general ... but ... the approach of > > MS to ODF to implement the ISO standard is an understandable and reasonable > > decision. > > > > I make this assessment for the following reason: > > if it wasn't important that ODF was defined as an ISO standard, you could > > have stuck with the OASIS standard from the beginning. > > > > > >> Maybe it is in OASIS' interest (and even TDF's?) that other > >> software adopts ODF 1.3 and that they could/should provide > >> some support/developer time? > > Probably this is a pragmatically correct question and we have no real > > possibility to behave better. > > > > However, we should keep in mind that the behaviour of the TDF is not > > optimal as far as the interests of the sum of all users are concerned. > > It is likely that MS is playing a similar game with OOXML, but the FOSS > > community should not see this as an example or excuse for their own actions. > > > > > > > > greetings, > > Jörg > > > > > > - > > 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 > -- Rory O'Farrell - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: New Challange ODF 1.3 is out
Small correction: I am greatfull to all involved for ODF 1.3. I do not want to exclude anyone. I think this is really Awesome! And I whish someday, AOO will have also people somehow helping to develop ODF format further. I am sure there is still lot of work to do. All the Best Peter On 09.02.20 17:22, Peter Kovacs wrote: > My personal opinion in this matter is that it does not matter what > others do. All that counts is that ODF 1.3 is out. > > If others want to join the party everyone is welcome. If they do not > want to that is fine, too. > > I am personal very happy that the TDF has managed to organize this. And > I am excited to work on this. > > > So I would like to focus on the Todos what we need to do in order to get > this done. > > My fist Ideas would be: > > # compare 1.3with 1.2 or see if we get any other compares of changes. > > # Then we need to check what is covered by the 1.2 extended implementation. > > # 3 We need to make a plan what is to implement for 1.3 and make a > tracking list of features and tests to implement. > > > Any more Ideas? > > > All the Best > > Peter > > > On 09.02.20 12:28, Jörg Schmidt wrote: >> Hello, >> >>> -Original Message- >>> From: Pedro Lino [mailto:pedro.l...@mailbox.org] >>> Sent: Sunday, February 09, 2020 11:51 AM >>> To: dev@openoffice.apache.org >>> Subject: Re: New Challange ODF 1.3 is out >>> >>> Hi Peter, all >>> Just a heads up. On FOSDEM I learned that TDF managed to >>> raise money and do the work for ODF v 1.3. >>> I believe this is a quite relevant announcement! >>> >>> If ODF 1.3 is only used by a single Office suite then it will >>> no longer be "software independent" which IMHO defeats the >>> purpose of an Open Document format... >>> On the other hand given that ODF 1.3 is currently not an ISO >>> standard, Microsoft will not care about it until it is (in >>> fact they are making sure that ODF is not used at all) >>> >>> This will also isolate AOO since Open Documents will only >>> travel in one direction without feature loss (much like what >>> happens now with Microsoft's XML formats) >> You described it very well. >> >> I myself have been following the development of ODF from the very beginning >> and I have to underline what you write, or rather I have to take a critical >> look at the approach of the TDF, because: >> >> In terms of a free, uniform format for office documents and the declared >> intention to formulate this standard as an ISO standard, it is regularly >> counterproductive for LO to deviate from this and implement OASIS standard. >> >> We all know what to think about MS in general ... but ... the approach of MS >> to ODF to implement the ISO standard is an understandable and reasonable >> decision. >> >> I make this assessment for the following reason: >> if it wasn't important that ODF was defined as an ISO standard, you could >> have stuck with the OASIS standard from the beginning. >> >> >>> Maybe it is in OASIS' interest (and even TDF's?) that other >>> software adopts ODF 1.3 and that they could/should provide >>> some support/developer time? >> Probably this is a pragmatically correct question and we have no real >> possibility to behave better. >> >> However, we should keep in mind that the behaviour of the TDF is not optimal >> as far as the interests of the sum of all users are concerned. >> It is likely that MS is playing a similar game with OOXML, but the FOSS >> community should not see this as an example or excuse for their own actions. >> >> >> >> greetings, >> Jörg >> >> >> - >> 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 > - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: New Challange ODF 1.3 is out
My personal opinion in this matter is that it does not matter what others do. All that counts is that ODF 1.3 is out. If others want to join the party everyone is welcome. If they do not want to that is fine, too. I am personal very happy that the TDF has managed to organize this. And I am excited to work on this. So I would like to focus on the Todos what we need to do in order to get this done. My fist Ideas would be: # compare 1.3with 1.2 or see if we get any other compares of changes. # Then we need to check what is covered by the 1.2 extended implementation. # 3 We need to make a plan what is to implement for 1.3 and make a tracking list of features and tests to implement. Any more Ideas? All the Best Peter On 09.02.20 12:28, Jörg Schmidt wrote: > Hello, > >> -Original Message- >> From: Pedro Lino [mailto:pedro.l...@mailbox.org] >> Sent: Sunday, February 09, 2020 11:51 AM >> To: dev@openoffice.apache.org >> Subject: Re: New Challange ODF 1.3 is out >> >> Hi Peter, all >> >>> Just a heads up. On FOSDEM I learned that TDF managed to >> raise money and >>> do the work for ODF v 1.3. >> I believe this is a quite relevant announcement! >> >> If ODF 1.3 is only used by a single Office suite then it will >> no longer be "software independent" which IMHO defeats the >> purpose of an Open Document format... >> On the other hand given that ODF 1.3 is currently not an ISO >> standard, Microsoft will not care about it until it is (in >> fact they are making sure that ODF is not used at all) >> >> This will also isolate AOO since Open Documents will only >> travel in one direction without feature loss (much like what >> happens now with Microsoft's XML formats) > You described it very well. > > I myself have been following the development of ODF from the very beginning > and I have to underline what you write, or rather I have to take a critical > look at the approach of the TDF, because: > > In terms of a free, uniform format for office documents and the declared > intention to formulate this standard as an ISO standard, it is regularly > counterproductive for LO to deviate from this and implement OASIS standard. > > We all know what to think about MS in general ... but ... the approach of MS > to ODF to implement the ISO standard is an understandable and reasonable > decision. > > I make this assessment for the following reason: > if it wasn't important that ODF was defined as an ISO standard, you could > have stuck with the OASIS standard from the beginning. > > >> Maybe it is in OASIS' interest (and even TDF's?) that other >> software adopts ODF 1.3 and that they could/should provide >> some support/developer time? > Probably this is a pragmatically correct question and we have no real > possibility to behave better. > > However, we should keep in mind that the behaviour of the TDF is not optimal > as far as the interests of the sum of all users are concerned. > It is likely that MS is playing a similar game with OOXML, but the FOSS > community should not see this as an example or excuse for their own actions. > > > > greetings, > Jörg > > > - > 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: New Challange ODF 1.3 is out
Hi Jörg, Jörg Schmidt schrieb am 09-Feb-20 um 12:28: Hello, [..] I myself have been following the development of ODF from the very beginning and I have to underline what you write, or rather I have to take a critical look at the approach of the TDF, because: In terms of a free, uniform format for office documents and the declared intention to formulate this standard as an ISO standard, it is regularly counterproductive for LO to deviate from this and implement OASIS standard. No, it is the only way to go. ISO itself does not develop standards by itself. The standards are developed somewhere else and then they are submitted to ISO. Only after ODF 1.3 is an approved OASIS standard, we can go the next step to ISO. However, we should keep in mind that the behaviour of the TDF is not optimal as far as the interests of the sum of all users are concerned. Without the help of TDF we would not have got the COSM project and ODF 1.3 would be far away from becoming a standard. https://publicsoftware.eu/members/cosm-project/ Kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: Wie unser Projekt derzeit funktioniert
Hallo Peter, > -Original Message- > From: Peter Kovacs [mailto:pe...@apache.org] > Sent: Sunday, February 09, 2020 10:59 AM > To: dev-de@openoffice.apache.org > Subject: RE: Wie unser Projekt derzeit funktioniert > Ich finde auch das Attribut frostig falsch. Es gab hier in den letzten Tagen Streit auf der Liste, inzwischen sind die 'Wellen' bereits wieder am sich-Glätten, deswegen möchte ich klarstellen: Ich lege wirklich keinen Wert auf diese Formulierung - zuerst wollte ich "unhöflich" schreiben das schien mir nur noch ungeeigneter. Gruß Jörg - To unsubscribe, e-mail: dev-de-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-de-h...@openoffice.apache.org
RE: New Challange ODF 1.3 is out
Hello, > -Original Message- > From: Pedro Lino [mailto:pedro.l...@mailbox.org] > Sent: Sunday, February 09, 2020 11:51 AM > To: dev@openoffice.apache.org > Subject: Re: New Challange ODF 1.3 is out > > Hi Peter, all > > > Just a heads up. On FOSDEM I learned that TDF managed to > raise money and > > do the work for ODF v 1.3. > > I believe this is a quite relevant announcement! > > If ODF 1.3 is only used by a single Office suite then it will > no longer be "software independent" which IMHO defeats the > purpose of an Open Document format... > On the other hand given that ODF 1.3 is currently not an ISO > standard, Microsoft will not care about it until it is (in > fact they are making sure that ODF is not used at all) > > This will also isolate AOO since Open Documents will only > travel in one direction without feature loss (much like what > happens now with Microsoft's XML formats) You described it very well. I myself have been following the development of ODF from the very beginning and I have to underline what you write, or rather I have to take a critical look at the approach of the TDF, because: In terms of a free, uniform format for office documents and the declared intention to formulate this standard as an ISO standard, it is regularly counterproductive for LO to deviate from this and implement OASIS standard. We all know what to think about MS in general ... but ... the approach of MS to ODF to implement the ISO standard is an understandable and reasonable decision. I make this assessment for the following reason: if it wasn't important that ODF was defined as an ISO standard, you could have stuck with the OASIS standard from the beginning. > Maybe it is in OASIS' interest (and even TDF's?) that other > software adopts ODF 1.3 and that they could/should provide > some support/developer time? Probably this is a pragmatically correct question and we have no real possibility to behave better. However, we should keep in mind that the behaviour of the TDF is not optimal as far as the interests of the sum of all users are concerned. It is likely that MS is playing a similar game with OOXML, but the FOSS community should not see this as an example or excuse for their own actions. greetings, Jörg - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: New Challange ODF 1.3 is out
Hi Peter, all > Just a heads up. On FOSDEM I learned that TDF managed to raise money and > do the work for ODF v 1.3. I believe this is a quite relevant announcement! If ODF 1.3 is only used by a single Office suite then it will no longer be "software independent" which IMHO defeats the purpose of an Open Document format... On the other hand given that ODF 1.3 is currently not an ISO standard, Microsoft will not care about it until it is (in fact they are making sure that ODF is not used at all) This will also isolate AOO since Open Documents will only travel in one direction without feature loss (much like what happens now with Microsoft's XML formats) Maybe it is in OASIS' interest (and even TDF's?) that other software adopts ODF 1.3 and that they could/should provide some support/developer time? Regards, Pedro - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: gotoSCons: automated gbuild to SCons conversion
On Sun, Feb 9, 2020 at 11:47 AM Peter Kovacs wrote: > Sounds nice. > > Thank you. It would be great to have a debug output that can be checked to check which > dependencies have been pulled. For me a declarative output would be cool to > understand some code. > > You can see within-module dependencies with "scons -u --tree=all" run in a module: +-fileaccess +-fileaccess/SConscript +-fileaccess/inc | +-fileaccess/inc/fileaccess | +-fileaccess/inc/fileaccess/dllapi.h +-fileaccess/source | +-fileaccess/source/FileAccess.cxx | +-fileaccess/source/fileacc.xml +-fileaccess/util +-fileaccess/util/fileacc.component Dependencies between modules can be seen in main/ with "scons --tree=prune", which autodetects tons of headers, libraries, xml, etc. in solver/, with transitive dependencies. There are others, see https://scons.org/doc/production/HTML/scons-user.html#chap-troubleshooting > > Also do you have an idea how to handle IDLs with scon? That would be > awesome. > > You mean the idlc + regmerge + cppmaker/javamaker toolchain? It should be fairly easy, given I already ported part of it to Ant before (main/solenv/ant/idl.xml), although that didn't do header dependencies in .idl files. > All the best > Peter > > Damjan
RE: Wie unser Projekt derzeit funktioniert
Top zusätzliche Info. Ich mag zwar die Excel Referenz nicht, aber das Video ist eine nice Ressource. Wir sollten an sich aufpassen wegen Gebrauchsmuster. Die sind überall geschützt. Ich finde auch das Attribut frostig falsch. Das ist deine Interpretation. Mit 20% Informations Volumen gegenüber einem Persönlichem Dialog gibt es leider extrem viel Spielraum. Wir dürfen auch nicht Kulturelle und andere umgangsforms Unterschiede die zum Tragen können kommen vernachlässigen. Es ist unglaublich wichtig zu verstehen das es nicht persönlich gemeint ist. Beste Grüße Peter Am 9. Februar 2020 10:32:47 MEZ schrieb "Jörg Schmidt" : >Hallo Peter, > >> -Original Message- >> From: Peter Kovacs [mailto:pe...@apache.org] >> Sent: Saturday, February 08, 2020 11:18 AM >> To: dev-de@openoffice.apache.org >> Subject: Re: Wie unser Projekt derzeit funktioniert > >> Es wäre stressfreier würdest du einfach im Issue ergänzen was du >weißt >> und den Report verbessern. Es reicht schon wenn du Bidouilles Request >> Excel Beschreibung ist nicht genug aufnimmst. > >ich habe jetzt einen Kommentar an den Issue gehängt, von dem ich hoffe >er ist genügend erkärend. > >> Lass die Userin in Ruhe, die hat gemacht was sie konnte oder >> wollte. > >Ich hatte nicht vor die Userin in Unruhe zu versetzen, noch sie >derzeitig zu kontaktieren. Sollte ich sie kontaktieren weil ich eine >Extension erstellt bekommen habe, kann es doch wohl aber nicht schaden >ihr en passant mitzuteilen das die 'frostige' Reaktion auf ihren Issue >damit zu tun hatte das sie zu Teil den Issue falsch ausgefüllt hat. >Das wird an der entstandenen Lage nichts ändern aber es ist gut für das >Ansehen unseres Projektes, denn die Nutzerin wird sich denken 'schau >an, die AOO-Leute kümmern sich'. > >> Das >> hier ist keine Zwangsveranstaltung wie du das so siehst. > >?? > > > >Gruß >Jörg > > > >P.S. >ich habe verstanden das Probleme auch daraus resultierten das der Issue >falsch oder ungenau formuliert war, gleichzeitig (und weil wir darüber >ja derzeitig diskutiert haben) möchte ich auf Eines hinweisen: > >bei AOO-Calc sieht man leider deutlich wie es funktionell hinter >LO-Calc zurückgeblieben ist und eine Ursache dafür scheint mir das wir >unsere Arbeit schlecht koordinieren und uns nicht über notwendige >Priorisierungen unterhalten. >Dafür würde bei Calc schon das Wiederaufleben der 'Regel' von OOo-Calc >Einiges bringen, die da hieß: wir streben für Calc möglichst 100% >Kompatibilität der Tabellenfunktionen (gemeint sind 'Formeln') zu MS >Excel an, OBWOHL wir für OOo insgesamt _kein_ MSO-Clone sein wollen. > >Diese Frage der Tabellenfunktionen ist nämlich der maßgebliche Teil wo >AOO gegenüber LO zurückgefallen ist und ich sage das OBWOHL ist ein >grundsätzlicher Gegner all der Spezial-TabellenFunktionen bin, aber ich >muss zur Kenntnis nehmen das die meisten Anwender nicht gerne selbst >denken sondern fertige Dinge vor die Nase gesetzt haben wollen. > >Um bei, solchen Dingen, Einschätzungen richtig treffen zu können bedarf >es aber imho essentiell der Hinzuziehung von kompetenten Praktikern. >Ich weiß das dazu niemand die Programmierer zwingen kann, und deshalb >mache ich darauf nur viral aufmerksam, in der Hoffnung das zu einer >freiwilligen Berücksichtigung dieser Dinge führt. > > > > > > > >- >To unsubscribe, e-mail: dev-de-unsubscr...@openoffice.apache.org >For additional commands, e-mail: dev-de-h...@openoffice.apache.org
Re: gotoSCons: automated gbuild to SCons conversion
Sounds nice. It would be great to have a debug output that can be checked to check which dependencies have been pulled. For me a declarative output would be cool to understand some code. Also do you have an idea how to handle IDLs with scon? That would be awesome. All the best Peter Am 9. Februar 2020 09:51:06 MEZ schrieb Damjan Jovanovic : >I've implemented static libraries, added linker version scripts, and >made >some cleanups, and 22 modules can now be converted to SCons (up from 19 >a >week ago). > >AllLangResTarget is the next big target, and it seems exceptionally >complicated, with 3 layers of intermediate targets: .src >--(transex3)--> >.src --(rsc)--> .src --(cat)--> .srs --(rsc)--> .res per language in >AllLangResTarget, with transex3 being skipped when not building >translations. Since the .src can #include C headers, they will need a >custom dependency scanner, in addition to the custom builder that all >custom targets need, plus of course delivery rules. Fortunately, as >it's >Python, we have some flexibility as to how to implement it. > >On Sun, Feb 2, 2020 at 2:31 AM Damjan Jovanovic >wrote: > >> Hi >> >> I've just pushed a "scons-build" branch. >> >> The build infrastructure is in main/scons. Python and SCons have to >be >> installed system-wide and available in $PATH. Currently we require >Python >> 3, but that's easy to change. >> >> So far main/fileaccess has been converted to SCons as a test. Its >gbuild >> files are still there; prj/makefile.mk determines whether to use >gbuild >> or scons. SCons is only used at a module level, build.pl is still the >> launcher. You can build main/fileaccess in isolation by running >"scons" >> inside main/, or "scons -u" inside main/fileaccess, and clean by >adding >> "-c" (or "--clean") to those flags. It will correctly build the .cxx >file, >> link it into a library, install the library, run xsltproc on the >.component >> file, install the transformed .component file, and install the .xml >file. >> Everything can also be successfully cleaned. >> >> At present FreeBSD has been tested, and I will test Windows soon. >Other >> platforms don't exist, and still have to be added in >> main/site_scons/platform. >> >> The converter is in gotoGBuild/, at the same level as main/ and >test/. You >> build it with Maven by running "mvn package". Then: >> >> java -cp target/classes >org.apache.openoffice.gotoSCons.GBuildConverter >> parsingAnalysis ../main >> Attempts to parse each gbuild module, printing out errors for those >that >> couldn't be, and a summary of which could be parsed. >> What is also useful is: >> java -cp target/classes >org.apache.openoffice.gotoSCons.GBuildConverter >> parsingAnalysis ../main 2>&1 | grep java.lang.Exception > >> /tmp/errorsByModule.csv >> Then open /tmp/errorsByModule.csv in AOO, use # as the field >separator, >> and you get a table of modules that failed and a reason for each one. >Sort >> by column B, and you can see how often a reason occurs, for example >21 >> modules need AllLangResTarget implemented. That can inform further >> development. >> >> To actually convert a module to SCons, use one of the modules that >> previous results said could be parsed, eg. io, and run: >> java -cp target/classes >org.apache.openoffice.gotoSCons.GBuildConverter >> parseModule ../main/io/Module_io.mk >> It will print the converted SCons file to standard output. >> >> Converting library names is currently broken. In main/fileaccess and >> main/site_scons I've begun with dmake's way of naming libraries, like >in >> main/solenv/inc/libs.mk. GBuild re-did library naming by using 10 >> layer-specific rules, and then having tons of exceptions in >> main/RepositoryFixes.mk; I am not sure which is worse. Maybe we >should give >> up the pretense, and just have a table in a CSV file, with platforms >as >> column headers, and library names as row headers, with the >> platform-specific name in each field, and parse it with Python's >built-in >> CSV package on build startup? >> >> >> >> On Sat, Feb 1, 2020 at 8:10 PM Peter Kovacs wrote: >> >>> Hi Damjan, >>> >>> Let's try it. But I suggest to push to an own branch. There is no >worth >>> in trying and getting stuck in the same spot. >>> >>> Merge is done quickly. And it is great if others can have a look, >too. >>> >>> All the best >>> Peter >>> >>> >>> Am 1. Februar 2020 13:36:42 MEZ schrieb Damjan Jovanovic < >>> dam...@apache.org>: >>> >Hi >>> > >>> >gbuild has become an unmaintainable nightmare. While there are only >37 >>> >internal dmake modules left (+ another 37 external modules), I >cannot >>> >motivate myself to convert even 1 more. At my development speed of >>> >about 2 >>> >lines of code every 8 hours, gbuild is a disaster that wastes >>> >unbelievable >>> >amounts of time, and it's really not a development I can say I am >proud >>> >of. >>> >It has the ugliest syntax ever, it can only be debugged through >>> >experimentation, and nobody really understands it. Also, it doesn't
RE: Wie unser Projekt derzeit funktioniert
Hallo Peter, > -Original Message- > From: Peter Kovacs [mailto:pe...@apache.org] > Sent: Saturday, February 08, 2020 11:18 AM > To: dev-de@openoffice.apache.org > Subject: Re: Wie unser Projekt derzeit funktioniert > Es wäre stressfreier würdest du einfach im Issue ergänzen was du weißt > und den Report verbessern. Es reicht schon wenn du Bidouilles Request > Excel Beschreibung ist nicht genug aufnimmst. ich habe jetzt einen Kommentar an den Issue gehängt, von dem ich hoffe er ist genügend erkärend. > Lass die Userin in Ruhe, die hat gemacht was sie konnte oder > wollte. Ich hatte nicht vor die Userin in Unruhe zu versetzen, noch sie derzeitig zu kontaktieren. Sollte ich sie kontaktieren weil ich eine Extension erstellt bekommen habe, kann es doch wohl aber nicht schaden ihr en passant mitzuteilen das die 'frostige' Reaktion auf ihren Issue damit zu tun hatte das sie zu Teil den Issue falsch ausgefüllt hat. Das wird an der entstandenen Lage nichts ändern aber es ist gut für das Ansehen unseres Projektes, denn die Nutzerin wird sich denken 'schau an, die AOO-Leute kümmern sich'. > Das > hier ist keine Zwangsveranstaltung wie du das so siehst. ?? Gruß Jörg P.S. ich habe verstanden das Probleme auch daraus resultierten das der Issue falsch oder ungenau formuliert war, gleichzeitig (und weil wir darüber ja derzeitig diskutiert haben) möchte ich auf Eines hinweisen: bei AOO-Calc sieht man leider deutlich wie es funktionell hinter LO-Calc zurückgeblieben ist und eine Ursache dafür scheint mir das wir unsere Arbeit schlecht koordinieren und uns nicht über notwendige Priorisierungen unterhalten. Dafür würde bei Calc schon das Wiederaufleben der 'Regel' von OOo-Calc Einiges bringen, die da hieß: wir streben für Calc möglichst 100% Kompatibilität der Tabellenfunktionen (gemeint sind 'Formeln') zu MS Excel an, OBWOHL wir für OOo insgesamt _kein_ MSO-Clone sein wollen. Diese Frage der Tabellenfunktionen ist nämlich der maßgebliche Teil wo AOO gegenüber LO zurückgefallen ist und ich sage das OBWOHL ist ein grundsätzlicher Gegner all der Spezial-TabellenFunktionen bin, aber ich muss zur Kenntnis nehmen das die meisten Anwender nicht gerne selbst denken sondern fertige Dinge vor die Nase gesetzt haben wollen. Um bei, solchen Dingen, Einschätzungen richtig treffen zu können bedarf es aber imho essentiell der Hinzuziehung von kompetenten Praktikern. Ich weiß das dazu niemand die Programmierer zwingen kann, und deshalb mache ich darauf nur viral aufmerksam, in der Hoffnung das zu einer freiwilligen Berücksichtigung dieser Dinge führt. - To unsubscribe, e-mail: dev-de-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-de-h...@openoffice.apache.org
Re: gotoSCons: automated gbuild to SCons conversion
I've implemented static libraries, added linker version scripts, and made some cleanups, and 22 modules can now be converted to SCons (up from 19 a week ago). AllLangResTarget is the next big target, and it seems exceptionally complicated, with 3 layers of intermediate targets: .src --(transex3)--> .src --(rsc)--> .src --(cat)--> .srs --(rsc)--> .res per language in AllLangResTarget, with transex3 being skipped when not building translations. Since the .src can #include C headers, they will need a custom dependency scanner, in addition to the custom builder that all custom targets need, plus of course delivery rules. Fortunately, as it's Python, we have some flexibility as to how to implement it. On Sun, Feb 2, 2020 at 2:31 AM Damjan Jovanovic wrote: > Hi > > I've just pushed a "scons-build" branch. > > The build infrastructure is in main/scons. Python and SCons have to be > installed system-wide and available in $PATH. Currently we require Python > 3, but that's easy to change. > > So far main/fileaccess has been converted to SCons as a test. Its gbuild > files are still there; prj/makefile.mk determines whether to use gbuild > or scons. SCons is only used at a module level, build.pl is still the > launcher. You can build main/fileaccess in isolation by running "scons" > inside main/, or "scons -u" inside main/fileaccess, and clean by adding > "-c" (or "--clean") to those flags. It will correctly build the .cxx file, > link it into a library, install the library, run xsltproc on the .component > file, install the transformed .component file, and install the .xml file. > Everything can also be successfully cleaned. > > At present FreeBSD has been tested, and I will test Windows soon. Other > platforms don't exist, and still have to be added in > main/site_scons/platform. > > The converter is in gotoGBuild/, at the same level as main/ and test/. You > build it with Maven by running "mvn package". Then: > > java -cp target/classes org.apache.openoffice.gotoSCons.GBuildConverter > parsingAnalysis ../main > Attempts to parse each gbuild module, printing out errors for those that > couldn't be, and a summary of which could be parsed. > What is also useful is: > java -cp target/classes org.apache.openoffice.gotoSCons.GBuildConverter > parsingAnalysis ../main 2>&1 | grep java.lang.Exception > > /tmp/errorsByModule.csv > Then open /tmp/errorsByModule.csv in AOO, use # as the field separator, > and you get a table of modules that failed and a reason for each one. Sort > by column B, and you can see how often a reason occurs, for example 21 > modules need AllLangResTarget implemented. That can inform further > development. > > To actually convert a module to SCons, use one of the modules that > previous results said could be parsed, eg. io, and run: > java -cp target/classes org.apache.openoffice.gotoSCons.GBuildConverter > parseModule ../main/io/Module_io.mk > It will print the converted SCons file to standard output. > > Converting library names is currently broken. In main/fileaccess and > main/site_scons I've begun with dmake's way of naming libraries, like in > main/solenv/inc/libs.mk. GBuild re-did library naming by using 10 > layer-specific rules, and then having tons of exceptions in > main/RepositoryFixes.mk; I am not sure which is worse. Maybe we should give > up the pretense, and just have a table in a CSV file, with platforms as > column headers, and library names as row headers, with the > platform-specific name in each field, and parse it with Python's built-in > CSV package on build startup? > > > > On Sat, Feb 1, 2020 at 8:10 PM Peter Kovacs wrote: > >> Hi Damjan, >> >> Let's try it. But I suggest to push to an own branch. There is no worth >> in trying and getting stuck in the same spot. >> >> Merge is done quickly. And it is great if others can have a look, too. >> >> All the best >> Peter >> >> >> Am 1. Februar 2020 13:36:42 MEZ schrieb Damjan Jovanovic < >> dam...@apache.org>: >> >Hi >> > >> >gbuild has become an unmaintainable nightmare. While there are only 37 >> >internal dmake modules left (+ another 37 external modules), I cannot >> >motivate myself to convert even 1 more. At my development speed of >> >about 2 >> >lines of code every 8 hours, gbuild is a disaster that wastes >> >unbelievable >> >amounts of time, and it's really not a development I can say I am proud >> >of. >> >It has the ugliest syntax ever, it can only be debugged through >> >experimentation, and nobody really understands it. Also, it doesn't >> >fully >> >work, eg. a lot of the newer targets I've added don't get cleaned on >> >"make >> >clean", CustomTarget fails to deliver files sometimes, etc. >> > >> >To that end, I've restarting playing with an old idea: to switch to the >> >SCons build system, using a tool to automatically convert build files >> >from >> >gbuild to SCons. >> > >> >I got my previous scons build (of 1 module) up and running very >> >quickly, >> >and it still works. Then I continued development
New Challange ODF 1.3 is out
Hello all, Just a heads up. On FOSDEM I learned that TDF menaged to raise money and do the work for ODF v 1.3. https://www.oasis-open.org/news/announcements/open-document-format-for-office-applications-opendocument-v1-3-from-the-opendocum I have created Bug https://bz.apache.org/ooo/show_bug.cgi?id=128282 All the Best Peter - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
