Well one thing we could do is setup the package to work slightly
differently. That When downloading any part of OOo we set it up to
work on an installer basis. The first piece downloaded by the
installer app would be the API foundation, and then each of the UI's
for the applications would be downloaded and installed as the user saw
fit.
In this way, the API base would install ONCE. And then each UI module
would be loaded on-top.
Another option is that we allow the user to say "Only display these
applications". The start menu and quickstart menu's would be altered
accordingly keeping anything the user doesn't use off the list.
Any thoughts?
Rigel
On 1/12/06, Mathias Bauer <[EMAIL PROTECTED]> wrote:
> Rigel wrote:
>
> > Unfortunately at the present time OOo isn't engineered this way, but
> > if you want to head up a project to find your way out of this dilemma
> > you're welcome to. See the developers list for assistance.
>
> I don't think that this is a matter of engineering. It's true that OOo
> has a lot of parts that are not unique for a single application but are
> used by all of them. But it's not true that completely separating the
> applications in the code base would make each of them considerably
> smaller, just because the shared code indeed is used by each and every
> application (with some small exceptions) and so it will be a part of the
> application anyway. Sharing commonly used code instead of integrating
> them into each single app directly doesn't make the code of the single
> apps a lot bigger but it reduces the size of the combined package a lot!
>
> You should see it that way: a hypothetical "Writer only" version would
> be a little bit smaller if you engineer it in the "non-shared" way and
> the same is true for "Calc only" and "Impress only" versions. The reason
> for this that there is a technically based overhead of shared libraries,
> but it's only a small one. But as a result the combined OOo package
> would be considerably larger because now the common parts are put into
> the package three times!
>
> So why invest development resources into something that gives only a
> small benefit for a limited user base but is a large disadvantage for
> the majority?
>
> IMHO it's a packaging issue, not an engineering issue - you need an
> installation set that does not contain the parts of those apps you don't
> want to install (yes, there are some!). It will not be a lot smaller
> than the whole package, but as I said: that wouldn't be different if the
> OOo code was organized in a different way. It's not very hard to create
> such installation packages, it can be done without real code changes.
>
> The only way to reduce the size of a such a "single app Writer" package
> considerably would be to remove code and thus remove functionality. But
> how many people want to have a "crippled" writer that does not contains
> formulas, charts, drawing objects, pictures, OLE objects, database
> support, mail merge etc.? Besides that this indeed is currently not
> possible due to engineering reasons, we just don't have the necessary
> code separation to allow to remove e.g. the drawing object support from
> Writer.
>
> BTW: a full OOo installation set is a lot smaller than an MSOffice
> installation set. It would be interesting to compare the size of a Word
> and a "Writer only" installation set.
>
> Ciao,
> Mathias
>
> --
> Mathias Bauer - OpenOffice.org Application Framework Project Lead
> Please reply to the list only, [EMAIL PROTECTED] is a spam sink.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
