Amen to that! Plus:
1. Documentation is the suckiest thing about OpenOffice.org SDKs and APIs. If OOo has been modularized, then nobody ever noticed. Is there a module dependency diagram anywhere? (This was a rhetorical question, of course.) We need a central, comprehensive, well-organized and up-to-date documentation web-site (take a look at how Google documents their toolkits). The official documentation is so badly organized/out-of-date/incorrect/incomplete that even Google fails to find relevant information. My major source has been so far the mail archive where people report their questions and sometimes get their answers, yet nobody ever cares to update the documentation so that others could find it easily. 2. OOo file filters must become a standalone project that could be shared with KOffice, AbiWord and others. In general, having ability to use filters outside OOo is a major advantage. There are so many use-cases for filters other than opening Word files for editing in OOo. Content management systems (Alfresco), reporting software (JFreeReports), document intelligence (redaction), web-office suites (Zoho, GDocs), etc, all need multi-format support. Needless to say that this will tremendously increase the quality of the filters as you gain access to a much bigger developer community. Open-source is about avoiding reinventing the wheel and about enhancing the existing wheel. Cheers, Yegor 2008/9/26 Rene Engelhard <[EMAIL PROTECTED]>: > [ I can't resist to take the bait ] > > Hi, > > Bernd Eilers wrote: >> It´s all already 'modularized' and there do exists already ongoing > > Not in the source. You even can't build the extensions without an OOo > build env yet. You can't build them against the SDK. > > You can't build the URE separately and not build OOo against that URE. > > What you think is not always what the facts are. > >> efforts to split up the installation files into packages which depend of >> each other - been there done that! - so what? This is not something that > > Just that those packages you currently have suck great balls. And that when > you want to make it sane you get crashes because e.g. calc cannot find libdba. > (when you move libdba to -base and -base is not installed). So far for > a working component model. > >> is such a great new idea that we would not already working on since a >> long time. > > With no visible effects. > And if stuff is visible it's broken (see the package split example above > and the usles coreXY). Do a real "core" and do sane packages- > > Regards, > > Rene > > --------------------------------------------------------------------- > 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]
