Date: prev next · Thread: first prev next last
2012 Archives by date, by thread · List index


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.


Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.