OpenOffice and go-oo

[Caolán McNamara]

On Mon, 2008-10-13 at 16:37 +0300, Muayyad AlSadi wrote:
> > There is no opportunity for voting here.
> I did not meant it literary
> 
> > As I said, we apply the gstreamer set of patches.
> I was talking about video functionality

Yeah, me too. Insert->movie & sound should "just work" on Fedora,
F-9 as well as F-10, and all that goes through the gstreamer stuff.It
was just a mention that some extra sound stuff also goes through
gstreamer (play button in the file dialog when browsing sound files,
etc)

> > Both go-ooo.org and vanilla can be configured using --without-java
> 
> there is a difference between disabling java completely
>  (--without-java) in vanilla ooo and not relying on it in ooo-core and
>  moving it away to less frequently needed parts

That may be so, but its unrelated to a go-ooo vs vanilla comparison.

> in the first case you will lost most of functionality and that
> functionality can't be installed later
> but in the second case (having java but no dependence on it for
> ooo-core) and extra package can introduce that functionality late

But rpm doesn't have any "Suggested" sort of feature, and I don't think
it makes sense to just chop Requires: and leave functional menus
dangling for need of user-intervention to install something else.
Leaving help-search non-functional and certain menus useless unless the
user has extra knowledge to install the missing requires manually to
make them work is too hacky.

I've no problem with doing things the right way though. For example in
F-9 we required bsh because there is a beanshell scripting engine in OOo
(got only knows why, but...). Here for F-10 that I re-packaged it as a
standalone openoffice.org-beanshell extension, did the right work to
only see the macros->beanshell entries when beanshell is installed, etc.
all of which removed the bsh require in core. That sort of thing is
fine, so for e.g. the lucene if someone wants to do the work to rewrite
(like I did for the an older help system to move it from some java
solution to libxml/libxslt) it to use some functioning non-java solution
they that'd be fine. And for the saxon one, if someone tweaked things so
that the menus that refer to xslt features are only enabled/appear when
saxon is available then that'd be acceptable too, especially for a
fairly power-user feature like "write your own xslt transforms".

C.