On Fri, Mar 22, 2013 at 12:15 PM, Jürgen Schmidt <jogischm...@gmail.com> wrote: > Hi, > > the so called 3layer office is not really useful anymore (it was never) > and makes more problems than it helps. > > I thought that AOO 4.0 would be the best time to start at least with the > necessary rework. The main idea is to use a new simplified directory > layout and tweak the necessary config file (*rc, *.ini), rpath or > similar linker flags where necessary etc. Eliminate the URE completely > because we don't really want support it as a standalone product. > > I did some initial work so far and I am now able to build an office for > Windows, MacOS and Linux with a new simplified directory layout. > > Windows and MacOS have already one main directory whereas on Linux we > have "openoffice" (basis layer + URE) and "openoffice4" (brand layer). > > I removed all this base-link, ure-link, URE, urelib stuff and > reorganized the directories. > > Example layout on Linux: > openoffice4 > openoffice4/help > openoffice4/presets > openoffice4/program -> contains basis-link/program + URE/bin + URE/lib > openoffice4/program/misc -> former URE/share/misc -> will be removed > openoffice4/README > openoffice4/README.html > openoffice4/readmes > openoffice4/share > > In general the layout becomes more equal on all platforms. > > The good news is that the office work on all 3 platforms, I am able to > select Java, extensions seems to work as well. Python is not yet tested, > language packs are not yet tested and built but in general I am thinking > it will be no problem. > > Advantage of this move would be a simplified structure, long term a > simplified configuration when the *rc/*.ini files are consolidated. > Easier deployment on Linux, no conflicts with an URE from LO or the > distro at all. >
What is the advantage to the user? I don't think users care about the directory structure. This is an internal implementation detail. So if we wanted to explain this, say in a blog post, or on Facebook, what would we say? The one directory structure issue that we do get complaints about is our placement of dictionaries. We've heard from admins some concern about the size of our per-user profile, with the argument that immutable files like dictionaries should not be in the profile. For example, one admin was managing a training lab where he needed to reset the profiles for each training machine via a script. He did this by copying from a master profile over the network. But each profile directory was something like 40MB, due to inclusion of the dictionaries. Does your change help with things like this? -Rob > My idea is to continue this basic work, do further cleanup in the office > as well as the build system, do further testing including the SDK... > Still some work to do but from my point of view a useful move forward to > get rid of this complex and unnecessary 3layer stuff. > > What do you think? > > On demand I can provide test builds if there are people interested to > help with testing. > > Juergen > > > > > > > > > --------------------------------------------------------------------- > 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
