On Fri, 2012-02-10 at 23:11 +0100, Gert van Valkenhoef wrote: > The code that interfaces with Lucene to do the indexing and searching is > complete.
Great. > I've also looked into where the HelpIndexerTool is currently used, and > found these: > > - xmlhelp/source/cxxhelp/provider/databases.cxx: > > * In extension mode (enabled by HelpIndexer), through XInvocation > > * Does not ZIP the result > > - helpcontent2/util/target.pmk > > * Called as a command-line tool > > * ZIPs the result, but already has an alternative code path to do > it (the final .ELSE) The xmlhelp/source/com/sun/star/help/*.java route is the one that sets the "bExtensionMode". I think this one is which third party extensions can insert their help into our help system. The cxxhelp is the straightforward backend of the "search in help" dialogs. > Especially the "extension mode" seems to be a > relic of the convoluted code path (through XInvocation etc.) and doesn't > do much more than suppressing error messages. Yeah, all this started as masses of java code for a custom help format. Then it got converted to a c++ program, then parts of it basically got converted back to java and then chopped up to be turned into an extension. > couldn't the ZIP creation just always be replaced by this alternative > code path? hmph, indeed, seems that way on the face of it. Lets try that. > * This implementation is using the master branch of CLucene's git, > with clucene-contribs-lib enabled (for CJK support). The released > version of CLucene is compatible with Lucene 1.9.x, whereas LibreOffice > uses Lucene 2.3. I don't *think* compatibility between java and c++ file formats matters to us, if that's what you're getting at here. > * I'm not sure exactly how to make my code build as part of the LO > build, but could probably figure it out as long as the previous point is > addressed. Presumably just editing l10ntools/source/help/makefile.mk and adding another target or so in there will do the trick. I can hook this up and see if how it goes. > * CLucene (like Java) uses wide characters throughout, and defines > it's own TCHAR type for that. Can we make this play nice with how LO > handles strings? > > * I'm using some Unix headers, are these available on windows or > should I use some kind of LO equivalent of them? Should be basically cross-platform stuff in sal/inc/ to handle any of that stuff. > * I tried replacing the HelpIndexerTool in > helpcontent2/util/target.pmk, which seems to work fine, except that I'm > returning an error code when the content/caption directory doesn't exist > (unlike HelpIndexerTool), which breaks on "shared". I'll see if I can hook up what you got to our build system, ignoring the lack of clucene in our tree and assuming availablility of system clucene, and see how that goes. C. _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
