Re: [PATCH] Fix for #118485#, #108221#, #67705#
Hi Pedro, On 12.10.2011 03:43, Pedro Giffuni wrote: Hi; I committed it as revision 1182166, and noted it in the bug report, but I admit the patch was too big to do a review on it. Thanks for comitting. I think - as i wrote - for someone knowing the core it would have been possible to read the diffs. This is not too big from my POV, I have bigger changes in the pipeline. At least I'm here to fix tasks regarding this change if there should be some. I was very careful (similar to the big Geometry/AntiAliasing change I made), but You never know :-) It was evidently a lot of work that I would hate to see ignored and, if I understand well, this was like *really* broken (3 issues) but in the future I will try to avoid committing these big patches without someone else reviewing it first. Pedro. --- On Tue, 10/11/11, Armin Le Grand wrote: ... Hi *, I took some days to fix that long missing OLE-Attribute feature/bug. It is on one hand a missing feature (no reason to not apply attributes and transformations to OLE which contains the same as graphical object, a MetaFile) and on the other a compatibility issue with a big competitor which is able to add attributes to OLEs for a long time. This fix was already prepared in #67705# but could not be activated due to a missing part of #108221#. Thanks to ORW (aka Oliver-Rainer) which helped to solve that. The patch adds LineStyle, FillStyle, Text, Shadow, Shear and Rotate to OLE objects in Draw/Impress and Calc. It adds Shear to graphic objects. It also fixes some long existing not detected bugs to make all this work. It leaves OLEs and graphical objects for Writer (SW) untouched due to the fact that SW uses it's own implementations for those (one more argument for the long missing consolidation in SW to use DrawingLayer objects for this). Details are documented in https://issues.apache.org/ooo/show_bug.cgi?id=118485, but here is a list: - Added LineStyle, FillStyle, Text, Shadow, Shear, Rotate to OLE - Added Shear to GraphicObjects - Adapted context menus in Draw/Impress, Calc - Adapted UNO API to allow these attribute families for those object types - Adapted interactors to show a correct preview for interactions - Adapted ConvertTo to take set attributes into account (was completely missing for GraphicObjects, a bug on it's own). - Adapted Text edit activation (press any key to start typing), activation on Return stays untouched - Adapted OLE activation to be centered to the now eventually rotated/sheared object bounds - Adapted MetaFile-ToSdrObject converter, transformations are now applied to the created SdrObjects. Deactivated one erroneous Item in text attribute creation which leads to bad errors in text generation, wrote f'up #118498# for it (HDU) - Adapted Import/Export to take care of added text - Added correction for earlier written OOo ODF files at load time - Activated the prepared attribute visualization in the OLE Primitive - Corrected attribute generation for newly created OLEs I checked all changes again and added the patch to #118485#. Now I'm looking for someone volunteering to add the patch, build AOOo and play around with OLEs a little bit, reading the patch will also help in this case, it's not too big to do so. The change looks big, but it touches no too critical parts. It is also necessary to bring it in AOOo3.4, this change relies on a version change (here: 3.3 to 3.4) to be able to correct files written by OOo up to 3.3 (and only those). Some background: The root problem here was that older versions straight ignored attributes set at OLE objects by just not painting them. This means that in files generated the attributes are written and in plain ODF OLEs are filled default (blue8) and have line on default (black hairline). Questions/Comments are welcome, Armin -- ALG Sincerely, Armin -- ALG
Re: Solve SVG visualization without cairo and librsvg
Hi Pedro, On 06.10.2011 17:13, Pedro Giffuni wrote: Hello Armin; --- On Thu, 10/6/11, Armin Le Grand wrote: Hi Pedro, On 06.10.2011 06:30, Pedro Giffuni wrote: Hi; Perhaps someone can explain what the agg_module does? It's rather interesting, and apparently it has some relationship with SVG: http://www.antigrain.com/ Not with SVG, but with canvas as it looks. It's used in canvas/source/tools for canvastools, see ENABLE_AGG and SYSTEM_AGG vars. I cannot tell if this is actively used, there are (dependent on ENABLE_AGG) two files in canvas/source/tools (bitmap.cxx and image.cxx) which implement canvas classes by using agg stuff. OK, please note that they have some nice SVG examples there. I looked at the history and this module was not modified by SUN (barely some innocuous warnings on Solaris) so it would be very easy to update. If you don't have/find any use for it then, as Thorsten suggests, it will go. +1 Let's let it go for now. Pedro. Sincerely, Armin -- ALG
[PATCH] Fix for #118485#, #108221#, #67705#
Hi *, I took some days to fix that long missing OLE-Attribute feature/bug. It is on one hand a missing feature (no reason to not apply attributes and transformations to OLE which contains the same as graphical object, a MetaFile) and on the other a compatibility issue with a big competitor which is able to add attributes to OLEs for a long time. This fix was already prepared in #67705# but could not be activated due to a missing part of #108221#. Thanks to ORW (aka Oliver-Rainer) which helped to solve that. The patch adds LineStyle, FillStyle, Text, Shadow, Shear and Rotate to OLE objects in Draw/Impress and Calc. It adds Shear to graphic objects. It also fixes some long existing not detected bugs to make all this work. It leaves OLEs and graphical objects for Writer (SW) untouched due to the fact that SW uses it's own implementations for those (one more argument for the long missing consolidation in SW to use DrawingLayer objects for this). Details are documented in https://issues.apache.org/ooo/show_bug.cgi?id=118485, but here is a list: - Added LineStyle, FillStyle, Text, Shadow, Shear, Rotate to OLE - Added Shear to GraphicObjects - Adapted context menus in Draw/Impress, Calc - Adapted UNO API to allow these attribute families for those object types - Adapted interactors to show a correct preview for interactions - Adapted ConvertTo to take set attributes into account (was completely missing for GraphicObjects, a bug on it's own). - Adapted Text edit activation (press any key to start typing), activation on Return stays untouched - Adapted OLE activation to be centered to the now eventually rotated/sheared object bounds - Adapted MetaFile-ToSdrObject converter, transformations are now applied to the created SdrObjects. Deactivated one erroneous Item in text attribute creation which leads to bad errors in text generation, wrote f'up #118498# for it (HDU) - Adapted Import/Export to take care of added text - Added correction for earlier written OOo ODF files at load time - Activated the prepared attribute visualization in the OLE Primitive - Corrected attribute generation for newly created OLEs I checked all changes again and added the patch to #118485#. Now I'm looking for someone volunteering to add the patch, build AOOo and play around with OLEs a little bit, reading the patch will also help in this case, it's not too big to do so. The change looks big, but it touches no too critical parts. It is also necessary to bring it in AOOo3.4, this change relies on a version change (here: 3.3 to 3.4) to be able to correct files written by OOo up to 3.3 (and only those). Some background: The root problem here was that older versions straight ignored attributes set at OLE objects by just not painting them. This means that in files generated the attributes are written and in plain ODF OLEs are filled default (blue8) and have line on default (black hairline). Questions/Comments are welcome, Armin -- ALG
[patch] Fix for #i118484#
Hi *, I submitted and fixed task #118484# and added a patch to that task (see https://issues.apache.org/ooo/show_bug.cgi?id=118484). Please may someone review and apply it. Thanks in advance, Armin -- ALG
Re: Solve SVG visualization without cairo and librsvg
Hi Pedro, On 06.10.2011 06:30, Pedro Giffuni wrote: Hi; Perhaps someone can explain what the agg_module does? It's rather interesting, and apparently it has some relationship with SVG: http://www.antigrain.com/ Not with SVG, but with canvas as it looks. It's used in canvas/source/tools for canvastools, see ENABLE_AGG and SYSTEM_AGG vars. I cannot tell if this is actively used, there are (dependent on ENABLE_AGG) two files in canvas/source/tools (bitmap.cxx and image.cxx) which implement canvas classes by using agg stuff. I was considering updating it to version 2.4 (still BSDL) but it appears the code is there only for "internal [Sun] reasons". Cheers, Pedro. Sincerely, Armin -- ALG
Re: Solve SVG visualization without cairo and librsvg
Hi Dave, On 05.10.2011 18:05, Dave Fisher wrote: On Oct 4, 2011, at 2:57 AM, Armin Le Grand wrote: On 27.09.2011 10:18, Armin Le Grand wrote: ... - still an external renderer, screen and all outputs would use a bitmap visualization Yes, it is still external, but it seems to support SVG-> EPS and PDF. ...by using the bitmap from the external renderer as Bitmap action, unfortunately (AFAIK). ... I will spend another week and see how I can progress. If I will not be able to advance with the necessary speed, I will probably fallback to (b). In Apache POI we've had success writing Java2D engines that output PPT, PPTX, and Microsoft's "Escher" drawing layers. I looked but could not find something about SVG. Since I'm pretty interested, could you please give some more data? Maybe a link into the repository where SVG gets involved? Thanks in advance, Armin Regards, Dave Sincerely, Armin -- ALG
Re: Solve SVG visualization without cairo and librsvg
On 27.09.2011 10:18, Armin Le Grand wrote: Hi *, I wanted to keep you up to date that I started looking for a replacement of SVG embedding functionality in the trunk version. This is needed since cairo and librsvg are gpl/lgpl and thus need to be avoided for an Apache release. Hi *, I just wanted to keep you all updated on what is going on SVG replacement. I have now invested one week and there are three basic possibilities: (a) Deactivate building the SVG rendering component vcl/source/components/rasterizer_rsvg.cxx. This would be the minimal solution for solving the copyright problems. Advantages: - Quick and easy to do Disadvantages: - Losing some SVG functionality again - Inserting SVG would be possible, would not be interpreted (shown/printed/exported). It would be saved and loaded - Loading files where SVG was inserted is possible, the alternate visualisation in the metafile data would be used - Other office version loading a AOO 3.4 file and having SVG support would work (b) Replacing the SVG renderer component to use something else (Batik would be the best candidate with Apache licence compatibility as it seems) Advantages: - SVG would stay supported, as bitmap graphic as currently Disadvantages: - mem/speed concerns with java - still an external renderer, screen and all outputs would use a bitmap visualization (c) Write an own SVG importer for AOO Advantages: - vector graphic stays vector graphic, esp. in all outputs. No pixel blocks when zooming in - future migration way to not only integrate, but also break up in SdrObjects and edit content - Needs to interpreted only once (to primitives), not each time an external renderer needs to create a new bitmap replacement - future usage of included animations possible (smil) Disadvantages: - Huge task, but not rocket science, well documented - Timeframe is not clear I experimented with (a) and (c) up to now. I invested ca. one week in (c) to estimate the do-ability. I can already import the tiger and other examples quite well, but still a lot has to be done. The abstract SVG importer I started needs to be extended, but has shown the last days to be a good base to do so. Representing SVG as primitives is also pretty well doable, showing that this goes in the right direction. I will spend another week and see how I can progress. If I will not be able to advance with the necessary speed, I will probably fallback to (b). Sincerely, Armin -- ALG
Re: Solve SVG visualisation without cairo and librsvg
Hi Pedro, On 27.09.2011 13:25, Pedro Giffuni wrote: Hi Armin; You may want to check Kai Ahrens' Batik idea/proposal: http://mail-archives.apache.org/mod_mbox/incubator-ooo-dev/201106.mbox/%3c4dfbca7d.1090...@ahrens-netz.de%3e Yes, thanks for that. I am already in contact with him. I am still thinking about alternatives, one point is java per se, another one is that SVG is handled as bitmap graphic when using an external renderer. This is a bit sad since it is vector graphic. cheets, Pedro. On Tue, 27 Sep 2011 10:18:46 +0200, Armin Le Grand wrote: Hi *, I wanted to keep you up to date that I started looking for a replacement of SVG embedding functionality in the trunk version. This is needed since cairo and librsvg are gpl/lgpl and thus need to be avoided for an Apache release. To track this I created task 118466 (see https://issues.apache.org/ooo/show_bug.cgi?id=118466) Sincerely, Armin -- ALG Sincerely, Armin -- ALG
introduction - some updates
Hi *, I wrote my introduction some time ago (see http://mail-archives.apache.org/mod_mbox/incubator-ooo-dev/201106.mbox/%3Ciufajg$339$1...@dough.gmane.org%3E), just wanted to give an update. I have now entered a new job position which will allow me to work on AOO full time, as an IBM employee. I'm looking forward to take this chance to move the DrawingLayer to where it needs to go, it's not finished yet... But first, need to concentrate on ApacheMigration and associated issues. So, for DrawingLayer questions feel free to ask for background information. For tasks concerning DrawingLayer, use BugZilla IssueTracker (https://issues.apache.org/ooo/) and file tasks to me. Sincerely, Armin -- ALG
Solve SVG visualisation without cairo and librsvg
Hi *, I wanted to keep you up to date that I started looking for a replacement of SVG embedding functionality in the trunk version. This is needed since cairo and librsvg are gpl/lgpl and thus need to be avoided for an Apache release. To track this I created task 118466 (see https://issues.apache.org/ooo/show_bug.cgi?id=118466) Sincerely, Armin -- ALG
[patch] Missing text in SlideShow (see #118456# in Bugzilla)
Hi List, commited, solved and added patch to task #118456# (see https://issues.apache.org/ooo/show_bug.cgi?id=118456). Could someone with commit rights add it, please (after checking and testing, of course :-)) ? sincerely, Armin -- ALG
Re: handling of ext_sources - Juergen's suggestion [was: Re: A systematic approach to IP review?]
On 22.09.2011 13:19, Jürgen Schmidt wrote: On Thu, Sep 22, 2011 at 12:40 AM, Jens-Heiner Rechtienwrote: On 09/20/2011 05:26 PM, Rob Weir wrote: ... Placing all the external tarballs in the VCS is a real killer if using a distributed SCM like git or Mercurial, thats why we had moved them out. As Pavel said, it worked quite nice. As for the audit possibility, we referenced the external tar balls in the source tree by file name and a md5 check sum, which works just as reliantly as putting them directly into the repository. Nowadays the DSCM have some alternative methods which deal with such blobs but in essence they also keep them separate. If AOOo ever plans to go back to a DSCM I would keep the source tree and the external blobs strictly separated. All in all the general SCM tooling community opinion trend seems to be that a S(ource)CM system is for, well, source and external dependencies are better handled with other mechanism, like Maven or so. With SVN all this is less of a concern, naturally. ok, we have several arguments for and against but no decision how we want to move forward. Let us take again a look on it 1. we have a working mechanism to get the externals from somewhere, check md5 sum, unpack, patch, build 1.1 "somewhere" is configurable during the configure step, initially the externals are downloaded from http://hg.services.openoffice.org/binaries 2. having the externals in the repository (SVN) won't be a big issue because in case of a checkout always the tip version is downloaded 2.1 the SCM can be used to track the used version of the externals for a specific OO version -> simply checkout the version tag and everything is in place ... 3. in a DSCM it would be a real problem over time because of the increasing space of all versions 4. we need a replacement http://hg.services.openoffice.org/binaries asap (who knows how long the server will be available) 5. many developers probably work with a local clone of the repository using for example git svn or something else -> disadvantage of the increasing space but probably acceptable if a clean local trunk will be kept and updated Proposed way to move forward 1. put the externals under .../trunk/ext_sources .../trunk/ext_sources .../trunk/main .../trunk/extras 2. adapt configure to use this as default, disable the download (maybe reactivate it later if we move to a DSCM) 3. keep the process with checking the md5 sum as it is (for potential later use) Any opinions or suggestions? +1 Best current solution: Added to SVN where it does not really matter, and a way to get back when we may change to a DSCM in the future. Juergen sincerely, Armin -- ALG
Re: [AOOo 4.0] dev wishlist (Re: Starting a conversation on AOOo 4.0)
Hi all, in the whole discussion some nice ideas came up already. Please could someone open a Wiki and collect them there (as Rob suggested, maybe he can do that)? I would love to have a collection somewhere to look at when the initial changes and a 3.4 are done. On 22.09.2011 03:11, Dave Fisher wrote: I am intrigued by both Ricardo and Dennis's ideas. Ricardo makes me think of a combination of Word Perfect and other 80s word processors non wysiwyg view with markup. What if the tree view is of the ODF structure? A thought now back to vacation! Regards, Dave Sent from my iPhone On Sep 21, 2011, at 2:29 PM, "Dennis E. Hamilton" wrote: It appears that brainstorming has ended and judgment/evaluation begins? Ah well ... I guess it is time to wait and see how Rob intends to avoid this. - Dennis [PS: Regina - thanks for the tip. I never knew that was there.] -Original Message- From: RGB ES [mailto:rgb.m...@gmail.com] Sent: Wednesday, September 21, 2011 15:52 To: ooo-dev@incubator.apache.org; dennis.hamil...@acm.org Subject: Re: [AOOo 4.0] dev wishlist (Re: Starting a conversation on AOOo 4.0) 2011/9/22 Dennis E. Hamilton If I have to navigate around documents, such as the ODF specifications themselves, I save as PDF so I can use the forward and back browser-style navigation. It would be terrific if that worked in OO.o directly, so that one could go somewhere, then come back with a click of a button. That might help some of the copy and paste rearranging too, although it might be desirable to have a one-button remember-this-place in some go-to list pull-down too, having nothing to do with planting a bookmark in the document. There are a large number of navigational accelerators that would be useful in a Writer document, and having some sort of expandable tree-map sidebar for quick navigation wouldn't be bad either. Please, do not do it like LibO: their tree view is a nuisance, almost a show-stopper when you work on long and complex documents. See this issue: https://bugs.freedesktop.org/show_bug.cgi?id=36308 OK, and it would also be nice, for power-users at any rate, if it is possible to collapse and expand the text structures. That's a major UI hit though? It seems, in fact. The main problem I can see with "collapsing headings" is that displaying a "page" on such conditions is completely wrong, so this would need a different approach of how info is presented during edition. If we let our fantasy run wild, we can think of a WYSIWYM (not WYSIWYG) mode on which page constrains are not considered and images, objects and footnotes shows were they are dropped, not were they should be once the document is "compiled". The best example of such behaviour is LyX, a really good front-end for LaTeX: http://www.lyx.org/ But a good question to answer here is: Is this feature so important that AOO needs to face such huge changes in the near (or even not-so-near) future? I don't think so: for me, the Navigator is good enough (even if it is possible to make it even better...) BTW, if asked about nice to have features, why not full support for opentype tables? https://issues.apache.org/ooo/show_bug.cgi?id=16032 There are also long standing issues related with TOC, like this one: https://issues.apache.org/ooo/show_bug.cgi?id=27377 and many others... Cheers Ricardo
Re: handling of ext_sources - Juergen's suggestion [was: Re: A systematic approach to IP review?]
On 20.09.2011 15:58, Rob Weir wrote: On Tue, Sep 20, 2011 at 9:48 AM, Armin Le Grand wrote: On 20.09.2011 15:33, Oliver-Rainer Wittmann wrote: Hi, On 20.09.2011 14:37, Jürgen Schmidt wrote: ... What do others think about a structure where we have "ext_sources" besides "trunk". incubator/ooo/trunk incubator/ooo/ext_source ... So are we saying we would never need to branch or tag these files? For example, suppose we release AOOo 3.4.0, and then later we release AOOo 4.0. Then someone finds a serious security flaw in AOOo 3.4.0, and we decide to release an AOOo 3.4.1 as well as a AOOo 4.0.1. Would we be able to do this? What if the flaw was related to code in ext_sources? And if not us, in the project, what if some "downstream consumer" of AOOo 3.4.0 wants to rebuild 3.4.0 later, for a patch or whatever. But we've already updated ext_sources for AOOo 4.0? In other words, how do we track, in SVN, a compatible set of matching trunk/ and ext_source/ revisions, so we (or someone else) can recreate any released version of AOOo? Good point. Thus, it should be part of incubator/ooo/trunk, something like: incubator/ooo/trunk/main incubator/ooo/trunk/extras incubator/ooo/trunk/ext_sources It could be in an own repro, but this would just bring up the risk to not use the same tags in both (by purpose or by error). Indeed, looks as if it has to be a part of trunk somehow. Not very nice for binaries. Maybe we could find a intermediate place for them as long as we will need to do changes pretty often. Currently we will have to do some add/remove/changes to it. It could be good to add them to trunk after it has stabilized a little more. -Rob I like this idea. From a developer point of view I only have to checkout "ext_sources" once and reference it from all my "trunks" using the already existing configure-switch 'with-external-tar=""' +1 Also, hopefully ext_sources will not change too much (after a consolidation phase) and it's mostly binaries, thus not too well suited for a repository. Let's not extend our main repository with those binaries, please. Best regards, Oliver. Regards, Armin -- ALG
Re: handling of ext_sources - Juergen's suggestion [was: Re: A systematic approach to IP review?]
On 20.09.2011 15:33, Oliver-Rainer Wittmann wrote: Hi, On 20.09.2011 14:37, Jürgen Schmidt wrote: ... What do others think about a structure where we have "ext_sources" besides "trunk". incubator/ooo/trunk incubator/ooo/ext_source ... I like this idea. From a developer point of view I only have to checkout "ext_sources" once and reference it from all my "trunks" using the already existing configure-switch 'with-external-tar=""' +1 Also, hopefully ext_sources will not change too much (after a consolidation phase) and it's mostly binaries, thus not too well suited for a repository. Let's not extend our main repository with those binaries, please. Best regards, Oliver. Regards, Armin -- ALG
Re: Freeze on Impress
On 20.09.2011 15:22, Raphael Bircher wrote: Hello I have found a freeze in Impress. Steps to reproduce: - Start impress, and create a new doc - Type samething on the first slide - Add a slide - Type samething on the second slide - Open Print Dialog, and go to the tab OpenOffice.org Impress - Try to check "Distribute on multiple sheets on paper" OpenOffice.org Freeze. Tested on WIN7 with freshly build AOO version from (pretty) current trunc, no crash here. Tested with a self backed AOOo (with --disable-copyleft) an a Mac OS X 10.5. Are there other Systems affected? Is this bug still in a older Version of OOo? Greetings Raphael Sincerely Armin -- ALG
Re: [Repo][Proposal]After the code is checked in to SVN
Am 23.08.2011 13:07, schrieb Stephan Bergmann: On Aug 21, 2011, at 6:48 PM, Rob Weir wrote: ... Two more steps that we might want to phase in somewhere are: (a) Replace the Oracle/LGPLv3 license headers in all the relevant files with Apache/AL2 ones. Is this maybe legally important to do as early as possible, or can it wait until end-of-incubation? Probably makes no sense to do before phase 5, anyway. +1, will not affect big CWSes like aw080 (b) Optionally, do some automated cleanup. For example, LibreOffice recently did some automated whitespace and tab cleanup when merging their spread git repos into a single big one. Such cleanup is probably a good idea (if only to follow LOs example and not let the two code bases diverge more than necessary), but generally it of course complicates merging of existing changesets, so a time of "starting fresh" can be a good time for such a change (which implies that it would probably best be done after integrating the changesets from existing CWS in phase 6). -1, will be a nightmare for resynching aw080 during continued development. Please let's wait with something like this which does not really change the code until no really big cws is under way. -Stephan
Re: binfilter (was RE: OOO340 to svn)
Am 09.08.2011 22:20, schrieb Mathias Bauer: On 09.08.2011 20:49, Armin Le Grand wrote: ... Forgot one point: We are not talking about stopping support for something like PDF/A where readability is guaranteed for years/decades. We are talking about wildly, unplanned grown old binary filter formats in the old days of the office where the model was simply streamed out and in, patched and repaired many times, never documented (for good reason). And moreover, we are talking about a format that does not support a huge number of OOo feature, UniCode support being only one of them. Right, also forgot but didn't want to write a 3rd part just 5min later :-) Not only UniCode, all features since Binfilter was isolated, get lost in an old write/read cycle with this old filters. Using them for write may just have two reasons: - You have an old machine with StarOffice5.2 or something which cannot read ODF - You don't know about losing content when using the old formats BTW: the reservation that legal requirements can force people to keep documents in the old binary StarOffice format is a red herring. I have serious doubts that any organization with such requirements has ever used this format. Remember, it's *not* an OOo format, it's the format of the pre-OOo StarOffice application that was replaced by the UniCode supporting XML format before OOo got its first release. For those with concerns that there might be some documents in the old format that "suddenly" needs to be opened, perhaps a standalone converter tool from "binfilter" to ODF could be provided. Wait a moment, that tools already exists: all existing OOo version can be used that way. Exactly. Let the next AOO release be the last one to offer this. BTW: For the concerned ones how long it might be installable: I'm still using StarOffice5.2 sometimes for various things, still works well today :-) Regards, Mathias Regards, Armin -- ALG
Re: binfilter (was RE: OOO340 to svn)
Am 06.08.2011 19:45, schrieb Dennis E. Hamilton: " What does this show? Others behave much worse as we would do. If the first AOO release will be the last with binfilters and we assume a runnalble/installable state of 5-10 years (depending on OS, unforseeable progress, etc...) this will be fine from my POV." My concern about this rationale is that those of us who see no problem are making a likely irreversible decision that impacts those who do and may not even be aware of what we are doing. With regard to consumption versus production, I agree that it is easy to stop supporting production when no native consumers are likely to be available any longer and the OpenOffice.org document model evolves to support expanded functionality of further ODF specifications. So if we propose to retire binfilters, we need some way to make it clear that is happening and what the workarounds are for someone who finds themselves in need. And we definitely need to keep it in a form where someone could revive it at a later time, even if only part of some sort of document-forensics and -recovery/conversion effort rather than integrated into future releases. Forgot one point: We are not talking about stopping support for something like PDF/A where readability is guaranteed for years/decades. We are talking about wildly, unplanned grown old binary filter formats in the old days of the office where the model was simply streamed out and in, patched and repaired many times, never documented (for good reason). This is not the last time we will need to deal with this (and the same fate could eventually befall the native format currently supported by OpenOffice.org.) Also, if there are available specifications, whatever their quality, we probably need to see to their preservation as well. - Dennis -- ALG
Re: binfilter (was RE: OOO340 to svn)
Am 06.08.2011 19:45, schrieb Dennis E. Hamilton: " What does this show? Others behave much worse as we would do. If the first AOO release will be the last with binfilters and we assume a runnalble/installable state of 5-10 years (depending on OS, unforseeable progress, etc...) this will be fine from my POV." My concern about this rationale is that those of us who see no problem are making a likely irreversible decision that impacts those who do and may not even be aware of what we are doing. Can never be excluded, we simply have no numbers. Remember, this means we also have no numbers about how many people use it. No complains when not installing it by default hints to no users. OTOH we have numbers about time, space, bandwidth, buildtime consumptions of binfilter. We know that it needs to be looked after. Michael Stahl pointed to probable security relevant stuff in the old binfilter parts (I guess he's right). We know that it builds with a lot of warnings. Trying to remove those is ambitious, but OTOH dangerous, may add errors to binfilters. Errors may be added by changes to underlying modules with nearly no chance to find them. Even changing the compiler may add unnoted errors. In short: It does not come for free to simply keep it. All in all: Binfilter has done it's duty. It has allowed to do changes to the internal core class hierarchy and more. It has allowed to have a transition phase. Let's let it go... With regard to consumption versus production, I agree that it is easy to stop supporting production when no native consumers are likely to be available any longer and the OpenOffice.org document model evolves to support expanded functionality of further ODF specifications. So if we propose to retire binfilters, we need some way to make it clear that is happening and what the workarounds are for someone who finds themselves in need. And we definitely need to keep it in a form where someone could revive it at a later time, even if only part of some sort of document-forensics and -recovery/conversion effort rather than integrated into future releases. Sure, agreed. This is not the last time we will need to deal with this (and the same fate could eventually befall the native format currently supported by OpenOffice.org.) Also, if there are available specifications, whatever their quality, we probably need to see to their preservation as well. - Dennis
Re: binfilter (was RE: OOO340 to svn)
Am 05.08.2011 22:22, schrieb Eric Hoch: Hi Armin, Am Fri, 05 Aug 2011 19:01:52 +0200 schrieb Armin Le Grand: Am 05.08.2011 18:47, schrieb Dennis E. Hamilton: The only problem with [2] is that it assumes conversion is possible/permissible. That is not always the case. Now, I do not know there is anyone who has that problem and is (or will soon be) unable to run older software that accesses those formats, but we do need to be careful in considering this. The current 3.2 version would be the last one to have both, how ling will it be installable and runnable on evolving systems? Can only be guessed, but usually it's another 7-8 years. I have no numbers, but how many people still have files in old formats? With introduction ODF years ago it was preselected as the standard. I don't know how it is in the country you live in but here in Germany documents, especially tax relevant ones from companies, must be archived for 10 years or even longer. 2011 minus 10 years makes it 2001 and in 2001 there was no ODF. Germany, too :-) At another place I worked before I had a request to open a Works 2.0 file which hadn't been used for ages but contained informations that years later were needed. At the time of creation of those files nobody thought that there would be a time where there would be no MS Works that will read old 2.0 formats or that you would have even trouble to find a Computer old enough to run MS-DOS or Win 95 not to mention the actions it took to get a version of MS Works that would read Works 2.0 formats and convert them into a format that todays MS Office version would read without totally messing up the layout to a point were the file unusable. What does this show? Others behave much worse as we would do. If the first AOO release will be the last with binfilters and we assume a runnalble/installable state of 5-10 years (depending on OS, unforseeable progress, etc...) this will be fine from my POV. When you load old files, change and safe them you are invited to use ODF for the file save. That's true but in some cases, see above, you must preserve not only the content of the document but also how it looked and the digital signature because otherwise there is no proof that you didn't edit it. Worst case would be that you convert the document with a batch run into ODF, it reads 1000 instead of 100, which you don't notice, and convert this in a signed PDF/A. This of course can happen also when you use the original StarOffice format but you would have eliminated one possible source of errors in the first conversion into ODF. One more reason not to use the most current AOO in five years, but an older one which is installable and capable of doing the job. I agree that this would be safer for conversion anyways. Noone tests binfilter nowadays when during version progress the underlying libraries (tools, vcl, etc) get changed. This does have influence on binfilter, but as long as noone using the old formats stumbles over one (and reports it), it will just stay hidden. Thats what I meant with that it's even dangerous to keep these last, low-level dependencies. The office was not even as widely spread as it is now before ODF was added as default format, thus potentially much less documents in the old formats were created, compared to ODF. I think something like old file formats have to be deprecated one day, and in my opinion there was a quite long conversion/transition period now. As others already mentioned, binfilter is not even installed by default for 3.2 (if I remember correctly), and I have not seen any complaints about that yet. To All: Does anyone use one of the old binary formats or knows anyone who does actively nowdays? Please answer if you know about something like that, this would be valuable input in this discussion. Not used actively but needed in order to open old documents which cannot be converted into ODF because of the above reason that you cannot rule out that you make 100 out of 1000 or the other way round. Use the last version doing both, the first AOO release as it looks. It's not even released, so there will be some time where it will be installable. One concrete question: DO you have documents in the old formats or is this just hypothetical..? Eric Hoch Sincerely, Armin -- ALG
Re: binfilter (was RE: OOO340 to svn)
Am 05.08.2011 19:44, schrieb Marcus (OOo): I hope that we still agree to keep the binfilters with our first Apache release. Otherwise we would deplay it more than IMHO necessary. Correct, full agreement. Sorry to have not mentioned that, but of course for the first release it should stay added. Not sure about the current state, seems as if it is installed optional with default to false. I'll need to check that ASASAA (As Soon As Sources Are Available :-)) After the first is done we can remove them for the 2nd official Apache version. While we do many dev builds on the way (hopefully, like it was with OOo) we can see if there are more problems that we have to take into account. Agreed. In parallel we can make an announcement that the next version has a) only support for importing the old binary file formats - or - b) no support for import and export. Depends on what we want. Agreed. I would just announce that it's the last version with binary filters, not really a neccesary to forbid writing from my POV. Regards, Armin Marcus Am 08/05/2011 07:01 PM, schrieb Armin Le Grand: Am 05.08.2011 18:47, schrieb Dennis E. Hamilton: The only problem with [2] is that it assumes conversion is possible/permissible. That is not always the case. Now, I do not know there is anyone who has that problem and is (or will soon be) unable to run older software that accesses those formats, but we do need to be careful in considering this. The current 3.2 version would be the last one to have both, how ling will it be installable and runnable on evolving systems? Can only be guessed, but usually it's another 7-8 years. I have no numbers, but how many people still have files in old formats? With introduction ODF years ago it was preselected as the standard. When you load old files, change and safe them you are invited to use ODF for the file save. The office was not even as widely spread as it is now before ODF was added as default format, thus potentially much less documents in the old formats were created, compared to ODF. I think something like old file formats have to be deprecated one day, and in my opinion there was a quite long conversion/transition period now. As others already mentioned, binfilter is not even installed by default for 3.2 (if I remember correctly), and I have not seen any complaints about that yet. To All: Does anyone use one of the old binary formats or knows anyone who does actively nowdays? Please answer if you know about something like that, this would be valuable input in this discussion. Regards, Armin In the future, this problem will become more likely because conversion is prevented by technical means, not just an usage case (e.g., when a document is digitally-signed and the signature must be preserved). - Dennis -Original Message----- From: Armin Le Grand [mailto:armin.le.gr...@me.com] Sent: Friday, August 05, 2011 04:34 To: ooo-dev@incubator.apache.org Subject: Re: binfilter (was RE: OOO340 to svn) Hi *, Binfilter can pretty simply be linked statically against the remaining dependencies (tools and below) and just stay there as a binary module. It already is a UNO API based module, so having binfilter or not is just a matter of copying the binaries or not during installation, plus maybe some finetuning. My initial suggestion was anyways to not add it as a module, but keep it static on the version it was added in the past; being indirectly changed by changing the below modules for other purposes is theoretically even dangerous and may introduce errors. Seen from today I see no reason at all to keep it; there are about 20 versions of OOo/other derivates out there which support it and thus support converting documents. Everyone who still has old docs (few after 7-8 years I guess) is able to get a version before removal, install it and convert those docs. As discussed above, there are two possibilities (well, three, if we keep it as it is): [1] Do the not too difficult step of making binfilter independent from the rest by statically linking, keep it on the current version. Use the resulting binary module for future versions. [2] Completely remove it and refer any complaints from people which were not able to move to the new file formtats in the last 7-8 years to the countless versions which are capable to do the conversion Thus I clearly suggest to do [2] now, enough ressources (memory, bandwidth, built time, ...) spent on it. Let's use the chance to cut some old burdens. BTW: Fo the interested I already mentioned some facts about it's history here [news://news.gmane.org:119/iufajg$339$1...@dough.gmane.org] Am 03.08.2011 21:17, schrieb Mathias Bauer: On 03.08.2011 20:25, Dennis E. Hamilton wrote: What I managed to glean from the LibreOffice discussion lists is that binfilter will be separately installable but probably not taken to end-of-life. (As platforms change, it may be necessary to make new builds of it
Re: binfilter (was RE: OOO340 to svn)
Am 05.08.2011 18:47, schrieb Dennis E. Hamilton: The only problem with [2] is that it assumes conversion is possible/permissible. That is not always the case. Now, I do not know there is anyone who has that problem and is (or will soon be) unable to run older software that accesses those formats, but we do need to be careful in considering this. The current 3.2 version would be the last one to have both, how ling will it be installable and runnable on evolving systems? Can only be guessed, but usually it's another 7-8 years. I have no numbers, but how many people still have files in old formats? With introduction ODF years ago it was preselected as the standard. When you load old files, change and safe them you are invited to use ODF for the file save. The office was not even as widely spread as it is now before ODF was added as default format, thus potentially much less documents in the old formats were created, compared to ODF. I think something like old file formats have to be deprecated one day, and in my opinion there was a quite long conversion/transition period now. As others already mentioned, binfilter is not even installed by default for 3.2 (if I remember correctly), and I have not seen any complaints about that yet. To All: Does anyone use one of the old binary formats or knows anyone who does actively nowdays? Please answer if you know about something like that, this would be valuable input in this discussion. Regards, Armin In the future, this problem will become more likely because conversion is prevented by technical means, not just an usage case (e.g., when a document is digitally-signed and the signature must be preserved). - Dennis -Original Message- From: Armin Le Grand [mailto:armin.le.gr...@me.com] Sent: Friday, August 05, 2011 04:34 To: ooo-dev@incubator.apache.org Subject: Re: binfilter (was RE: OOO340 to svn) Hi *, Binfilter can pretty simply be linked statically against the remaining dependencies (tools and below) and just stay there as a binary module. It already is a UNO API based module, so having binfilter or not is just a matter of copying the binaries or not during installation, plus maybe some finetuning. My initial suggestion was anyways to not add it as a module, but keep it static on the version it was added in the past; being indirectly changed by changing the below modules for other purposes is theoretically even dangerous and may introduce errors. Seen from today I see no reason at all to keep it; there are about 20 versions of OOo/other derivates out there which support it and thus support converting documents. Everyone who still has old docs (few after 7-8 years I guess) is able to get a version before removal, install it and convert those docs. As discussed above, there are two possibilities (well, three, if we keep it as it is): [1] Do the not too difficult step of making binfilter independent from the rest by statically linking, keep it on the current version. Use the resulting binary module for future versions. [2] Completely remove it and refer any complaints from people which were not able to move to the new file formtats in the last 7-8 years to the countless versions which are capable to do the conversion Thus I clearly suggest to do [2] now, enough ressources (memory, bandwidth, built time, ...) spent on it. Let's use the chance to cut some old burdens. BTW: Fo the interested I already mentioned some facts about it's history here [news://news.gmane.org:119/iufajg$339$1...@dough.gmane.org] Am 03.08.2011 21:17, schrieb Mathias Bauer: On 03.08.2011 20:25, Dennis E. Hamilton wrote: What I managed to glean from the LibreOffice discussion lists is that binfilter will be separately installable but probably not taken to end-of-life. (As platforms change, it may be necessary to make new builds of it.) Binfilter already is installable separately - on Windows it's an option in the setup that you can disable (and AFAIK it is disabled by default). What you probably mean is that they are discussing to make binfilter a component that is compatible cross versions and so does not need to be installed each time when a new version of the office program is installed. As this currently fails due to some dependencies between binfilter and "the rest of the office" that are not stable enough and might change in every release, this ends up in the discussion you mentioned: There is also discussion about moving some annoying dependencies into the binfilter (and other converter) branches in some case, so they don't have to be maintained in sync with the main distro. That's nothing new and this has happened in the past already in several cases. I did that by myself on several occasions. But this approach is doomed to fail in at least two cases: GraphicObjects and vcl. At least it would require to refactor large parts of the binfilter code to be able to remove
Re: binfilter (was RE: OOO340 to svn)
Am 05.08.2011 18:15, schrieb Mathias Bauer: On 05.08.2011 17:21, Armin Le Grand wrote: Hi Mathias, Am 05.08.2011 16:25, schrieb Mathias Bauer: On 05.08.2011 13:33, Armin Le Grand wrote: [1] Do the not too difficult step of making binfilter independent from the rest by statically linking, keep it on the current version. Use the resulting binary module for future versions. As long as binfilter runs in the same process, you can't link it statically against vcl. Yes, right. Thanks for the hint. Thus, the remaining missing stuff has to be stripped and added in the binfilter way. Worth a try... When will we have code...? Adding a copy of vcl to binfilter won't help as you can't have two instances of the vcl Application class (including its pseudo-static data). ...whereby the binfilter version would be in the binfilter namespace. Maybe there is a creative way to have a vcl Application class in the binfilter namespace. The only way to solve the problem would be reimplementing the vcl based part of binfilter so that is only uses a stable API to vcl code. I had more in mind to implement the still needed parts. Should be (hopefully) not too much, painting and other stuff is completely removed, thus the static data should be not needed in most cases or being replacable. The second depends on a try I guess. We will never be able to guess all needed stuff by discussing. This could be achieved by using UNO APIs where possible and defining the remaining used C++ APIs as "stable". "stable API" means: defining a time period where they are guaranteed to remain compatible so that binfilter does not need an update even if the office version is changed. Too dangerous, I would not try that. Of course that would be quite some work to do as binfilter surely uses a lot of vcl code here and there. Hopefully not :-) Regards, Mathias Regards, Armin -- ALG
Re: binfilter (was RE: OOO340 to svn)
Hi Mathias, Am 05.08.2011 16:25, schrieb Mathias Bauer: On 05.08.2011 13:33, Armin Le Grand wrote: [1] Do the not too difficult step of making binfilter independent from the rest by statically linking, keep it on the current version. Use the resulting binary module for future versions. As long as binfilter runs in the same process, you can't link it statically against vcl. Yes, right. Thanks for the hint. Thus, the remaining missing stuff has to be stripped and added in the binfilter way. Worth a try... When will we have code...? Regards, Mathias Regards, Armin -- ALG
Re: binfilter (was RE: OOO340 to svn)
Hi *, Binfilter can pretty simply be linked statically against the remaining dependencies (tools and below) and just stay there as a binary module. It already is a UNO API based module, so having binfilter or not is just a matter of copying the binaries or not during installation, plus maybe some finetuning. My initial suggestion was anyways to not add it as a module, but keep it static on the version it was added in the past; being indirectly changed by changing the below modules for other purposes is theoretically even dangerous and may introduce errors. Seen from today I see no reason at all to keep it; there are about 20 versions of OOo/other derivates out there which support it and thus support converting documents. Everyone who still has old docs (few after 7-8 years I guess) is able to get a version before removal, install it and convert those docs. As discussed above, there are two possibilities (well, three, if we keep it as it is): [1] Do the not too difficult step of making binfilter independent from the rest by statically linking, keep it on the current version. Use the resulting binary module for future versions. [2] Completely remove it and refer any complaints from people which were not able to move to the new file formtats in the last 7-8 years to the countless versions which are capable to do the conversion Thus I clearly suggest to do [2] now, enough ressources (memory, bandwidth, built time, ...) spent on it. Let's use the chance to cut some old burdens. BTW: Fo the interested I already mentioned some facts about it's history here [news://news.gmane.org:119/iufajg$339$1...@dough.gmane.org] Am 03.08.2011 21:17, schrieb Mathias Bauer: On 03.08.2011 20:25, Dennis E. Hamilton wrote: What I managed to glean from the LibreOffice discussion lists is that binfilter will be separately installable but probably not taken to end-of-life. (As platforms change, it may be necessary to make new builds of it.) Binfilter already is installable separately - on Windows it's an option in the setup that you can disable (and AFAIK it is disabled by default). What you probably mean is that they are discussing to make binfilter a component that is compatible cross versions and so does not need to be installed each time when a new version of the office program is installed. As this currently fails due to some dependencies between binfilter and "the rest of the office" that are not stable enough and might change in every release, this ends up in the discussion you mentioned: There is also discussion about moving some annoying dependencies into the binfilter (and other converter) branches in some case, so they don't have to be maintained in sync with the main distro. That's nothing new and this has happened in the past already in several cases. I did that by myself on several occasions. But this approach is doomed to fail in at least two cases: GraphicObjects and vcl. At least it would require to refactor large parts of the binfilter code to be able to remove these dependencies. There are much more better places where time could be invested better. [Remark: IMHO the GraphicObject problem should be solvable with moderate effort, I doubt that this is the case for vcl.] But maybe this is just a problem because people want to see a problem in it. Though in theory binfilter creates some maintenance effort due to its remaining dependencies on other code, I can't remember a lot of necessary work on binfilter caused by these dependencies in the last years. In the past we already went the "remove annoying dependencies" road for binfilter: each time when a developer made huge changes in a module that would require larger code adjustments in binfilter, the module that was going to be changed was copied before the change and the unmodified copy was moved into binfilter (and hopefully ;-) stripped from all code not used in binfilter later). As I wrote, this doesn't work for the GraphicObject and vcl, but we already used it for most of the bigger modules with a lot of code changes, so I don't expect a lot of room for improvement here. It should be mentioned that this approach only optimized the work from a maintencance cost POV, but it made things worse in other areas: binfilter becomes bigger each time when a copied module was added, increasing both build time and size of the installation set. And even the optimization for maintenance cost is incomplete as the resulting code duplication will require duplicated work in the future at least in case security leaks are found (been there, done that ...). There is also a thrust to make converters more cleanly-separated and having the plugin APIs work successfully for them. Again, this is the gist of it. It doesn't seem too far from ideas that have been floated around here, though. I'm afraid that talking about stuff like this without actually knowing the code will at best create confusion. So all I will say about that he
Re: OpenOffice.org (was Re: Ooo blog)
Am 10.07.2011 20:19, schrieb Donald Harbison: No need to drag the .org into the future, if Apache is prefixed. If no prefix, yes, we lead with the trademark of record: OpenOffice.org. IMHO. Let's simply use Apache OpenOffice. +1 Keep it as simple as possible. For the non-IT centric rest of mankind (the majority, please remember) '.org' is just something artificial, IMHO. Regards, Armin Le Grand
Re: OOO and LibreOffice.
Am 07.07.2011 19:29, schrieb Mathias Bauer: On 07.07.2011 18:06, Ian Lynch wrote: <-stuff removed that can be read one news back -> Just to prevent that a false impression comes up (and the "2 meg" you named gets a meaning that it doesn't have in fact): the "code cleanup" in LO we are talking about comprises several things: (1) removing code that was not compiled at all (2) removing code that was compiled, but not used (3) removing superfluous comment lines (4) translating comments from German to English (5) "real" code work: removing duplicated classes, simplifying code etc. <-stuff removed that can be read one news back -> I just want to mention that with the variable cleanup in OOo I had 1010 conflicting files on aw080 on the next resync, in average with 4-5 conflicts due to the fact that I already had changed the variables in the refactored code to something useful. This took me nealry 1 1/2 weeks where not really something productive could happen, just resynching and getting all compiled an running again. So, please, when You do such changes, keep in mind that this will produce a lot of work for people which You may not have on Your radar... Regards, Mathias best regards, Armin Le Grand -- ALG
Re: fetch-all-cws.sh (was: Building a single Hg repository)
Am 01.07.2011 18:47, schrieb Herbert Duerr: On 01.07.2011 13:42, Greg Stein wrote: [...] Please look at tools/dev/fetch-all-cws.sh. Each of these CWS repositories (on Mac OS) are consuming 600 Mb *minimum*. I've fetched a dozen, and a couple are over 2 Gb each, and another over 1 Gb. And this is with the clone/pull technique. Because of the disk space demands I think an approach with one repository with one branch per CWS would be better for the initial import. In hg there are more opportunities for this approach (using NamedBranched, UnnamedBranches, MultipleHeads, LocalBranches or Bookmarks) than I as git-fan would care to know. Please see the attached file where I hacked together a script that imports the CWSs into one repository with multiple bookmarks. I don't have enough space on my laptop to do a complete trial run. I'm hoping that somebody can figure out how to reduce the disk footprint, or determine that we just have to suck it up. And it would be nice to understand what that target size will be, for all 250 CWS repositories. As Michael mentioned it's much less than the 250, as only about 15 CWSses (see http://goo.gl/gczAH for details) are marked as fully tested and but not-yet integrated. From these the ones targeted at the stabilization branch (calc67, calc68, ooo34gsl01, ooo34gsl02, writerfilter10, native373, jl167) are more important than the ones targeted for trunk (sb140, sb143, hsqldb19, hr77, ause131, sd2gbuild). There are a few more very good CWSses which were not yet officially approved in the old OOo system. E.g. CWS aw080 Armin mentioned. If Armin can confirm that this CWS is ready we should pull it in too. Well, it will need some more work, but it is ready in the sense that it is on DEV300 m106 and that I am pushing to the old locations all the time. Main point is to get over to this dev line so that I can resync to the trunc here locally ASAP instead of continuing work with what will be an outdated rep soon. 2nd point is to get into the transition from the licenses ASAP, too. I can continue (and I do) to work on DEV300 codeline, but as soon as we have a running build here I opt for migrating. Once we have a better picture of what is ready or not cws-list.txt needs to be updated. We have a script. It is time to make it work. Please see the attached file. I'm afraid to check it in as the related single-hg.sh is not yet updated accordingly and also because I'm more of a HG victim than a HG power-user ;-) Please note that you either have to use HG>=1.8 or enable its bookmark extension before you run the attached script. Best regards, Herbert Duerr
Re: An svn question
Am 27.06.2011 10:47, schrieb Michael Stahl: On 27.06.2011 10:14, Mathias Bauer wrote: On 26.06.2011 23:15, Michael Stahl wrote: On 23.06.2011 19:15, Mathias Bauer wrote: Another option would be to commit the initial source code (the code that is directly retrieved from the software grant from Oracle) into a local Mercurial repository, add all the patches and then convert this into an svn repository. hmm... perhaps we could first merge all CWSes that are nominated/finished anyway into the HG OOO340 repo, then import the result into SVN... We can't look at this only from a technical POV. We also should try to avoid more legal work as this will slow down the integration. As I wrote, patches are easy as they are owned by those who made them, on whatever files. And as long as the base where you apply the patches to is "clean", you can't get into legal trouble. actually i don't see a difference between the two approaches (but as you know IANAL). consider that the original SGA only lists _part_ of the repository. so, in order to get anything useful that can actually build we need to ask for additional stuff anyway. if we have all the rights to the Oracle owned files in OOO340 + all outstanding CWSes, does it really make a difference if we first merge the CWSes in HG and then import the result, or whether we do it the other way around? the result should be the same, but with merging first the history will be much more useful, plus it's less work. the stuff that we need to remove from the repo can be removed either before merging the CWSes (if a CWS changes a removed file there will be a conflict on merge), or after; can't see much of a difference here. However it will be done, I want to suggest aw080 as test case. It is probably the biggest CWS with lots of changes to lots of modules. If it works with aw080, it should work with others. Also a good test for history stuff, aw080 was resynced to several DEV300 milestones already, so contains a mix of local change comments and the ones coming in from those big resyncs. For conflict removal, other mergings and to get back to a running state I would prefer to do that when we have a buildable, running version of the main trunc here. Until then it might be best that I continue with the changes on the CWS itself. Still, I want to change over to Apac he as work base ASAP. Of course - if someone describes in detail what to do to merge and get back to SVN - I'll try to do the move myself. For conflict solving I'll have to step in anyways, I guess :-) This brings me to the next point: If this CWS is wanted (for content, please refer to my Introduction) I'll need commit rights due to the sheer size of the changes and the probably unavoidable number of conflicts. I'm new here, so I've read a lot of news already, but currently not really sure how to get there... regards, michael
Introduction
Hi all, nice to see a vital discussion around OOo code at Apache - so I want to join and introduce myself. Let me first mention that I am here privately and all statements/opinions in this environment will be just my own (IANAL, but should be sufficient :-)). I live in Hamburg, Germany, which is a nice place in summer time when the weather is good. If we have the good known 'sub-optimal' weather, there is always some time to spend on things You can do inside, e.g. programming :-) I am working on StarOffice/OpenOffice.org full time since I joined StarDivision in July 1996. I started one year with StarMoney, but quickly moved over to the graphics stuff which is my passion. I worked on Impress for some years and became quickly responsible for the DrawingLayer. I did the first 3D engine (3rd generation of it now active), UI and interaction stuff, dialogs, functional extensions and so on. I'm also responsible for binfilter which removed the binary streaming from the graphics core and allowed to make bigger changes to the cores at all. (Maybe this is a good place to mention that my plan always was to do binfilter as binary independent module with UNO API once and in only one revision so that it could be added to any later office as binary; the decision to add it to the repository and have to build it all the time is form my POV a waste of time and space with nearly no advantages, but even risks...) Besides features/bugfixes I did a lot of cleanups, bigger and smaller ones. Examples are the first transition step/refactoring of the DrawingLayer to some more modern state (Primitives, see http://blogs.oracle.com/GullFOSS/entry/finally_anti_aliasing_is_done) which enabled AntiAliasing, better interactions (all with preview), enhanced text cursors, flicker-free visualisations in all apps and opened more possibilities for the future of the code/project. I want to join since I'm in the middle for the next big refactoring for DrawingLayer, the change of the core to double precision and transformations. This includes model, view and controller changes, adaptions of all DrawingLayer users (11 currently) and more common cleanups, removals and simplifications. This is currently in CWS aw080 based on DEV300_m106 (most here will know what that means :-)). We are talking about work in progress for a year already, a diff with 340.000 lines and over 3.300 files changed (see hg infos for the CWS yourself if interested in details). It will take some more time to finish that, but it would be too sad to lose the option for more speed, better precision and easier handling for the graphic objects. This is also the reason I want to demand that current CWSes *should* be migrated to Apache, too, not only head to not lose man-years of effort. I've seen (correct me if I'm wrong) that this is planned. It is also clear that for something like those changes a CWS mechanism is absolutely necessary. You want work like that to happen inside a branch, with frequent merges from trunk. Another thing which gives me some headache in this case: Those big refactoring CWSes most often contain renames/moves/deletes of files, so I would prefer a 100% bullet-proof way of retaining that information inside the used CVS (e.g. subversion or git would do). Enough said about that. I also like SF literature, playing games, my old car, vacations in France, Florida or (if possible) Australia, red wine and good food (who doesn't). BTW: What will happen to the bug datatbase? Are there plans already or do all tasks have to be found again...? kind regards Armin Le Grand -- ALG
