Hi, starting with the DEV300m72 build there is a new module called "editeng" that was split off from svx. This module has no dependencies on svx and also no dependencies on sfx2. OTOH, svx depends on editeng (as the editengine and outliner objects are used in shapes).
The moved code comprises the editeng and outliner directories, the rtf filter, many items and some other parts. Please have a look on the code and the issue cited below to see what was moved. There also have been some other code changes or movements that are explained in issue 107450: http://qa.openoffice.org/issues/show_bug.cgi?id=107450 Just to mention a few of these changes that might have some more visible influence: - class SvxLinkManager has been removed, all code now is in sfx2::LinkManager (the former base class) - svx/opengrf.hxx now is sfx2/opengrf.hxx (needed for removal of SvxLinkManager) - svx/impgrf.hxx has been removed, everything is found in svtools/filter.hxx - the function GetLanguageString now is a static method in class SvtLanguageTable - the ServiceInfoHelper class has been moved to comphelper - the function GetModuleFieldUnit has been split into two functions/methods: a function that retrieves the unit from the passed ItemSet and a new method in class SfxModule - CreateGraphicObjectFromURL now is a static method in class GraphicObject - SvxSearchItem now is in svl - HTML parser in EditEngine no longer derives from SfxHTMLParser - two static methods in SvxItemPropertySet got new boolean parameters; for convenience two functions have been added to unoshape.cxx that set them correctly for all ItemSets using the drawing pool Please keep the editeng module free from sfx2 code in future. There is absolutely no reason for that (as my experience showed me when I replaced the existing code bits by something else). This is the second step in the continuing effort to reduce the size of the svx module. Though a few unnecessary files could be removed, this will not reduce the code size of OOo, but it will create a better code separation and it helps people working on the different parts of the svx microcosmos as building the whole module will take less time. In m67 (before the work was started) we had 706 object files and 5 libraries in svx, in the cws svxsplit that just was integrated into DEV300 to become part of DEV300_m72, we will have 490 object files in 3 libraries. The code move to a new libediteng (together with moving some more code to libcui) reduced the size of the svx binaries from 7.1MB (svxcore) and 2.6MB (svx) to 5.8MB (svxcore) and 2.4MB (svx), while increasing the size of libcui from 2.9MB to 3.2MB and adding libediteng with 1.6MB. All numbers for Linux 32Bit including all other code changes made between m67 and m72. The svx resource files wa also split into svx, editeng and cui resource files. There's still room for further size reductions that could make working on svx code less time consuming. Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "nospamfor...@gmx.de". I use it for the OOo lists and only rarely read other mails sent to it. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
