[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [docbook-apps] Help needed testing CJK search support in webhelp
>> exclude.search.from.webhelp. Setting this to true will drop the >> search tab. You're right, I changed that property -- not sure why. My mistake! >> Index is already there, as the last link in TOC tab. >> Did you mean that >> or adding a separate tab for index, along with 'contents' and >>'search' tabs? Yes, I meant in the TOC tab, not a separate tab. But since your TOC has the link (not sure why mine didn't) I doubt it's a WebSite issue. - Denis On 08/12/2010 02:37 AM, Kasun Gajasinghe wrote: > >> Hello Denis, >> Thanks for the feedback. Please see the comments inline. >> >> --Kasun >> >> Sent from my iPhone >> >> On 12 Aug 2010, at 07:48 AM, Denis Bradford >> <denis.bradford@verizon.net> wrote: >> >>> I've installed and built the new package. It's beautiful! I saw a few >>> issues: >>> >>> 1. Couldn't create Search tab: I assume the Search tab is supposed to >>> appear somehow when I build the indexer. However, after following >>> instructions and running both the webhelp build-indexer targets I got >>> the TOC tab only. >> >> The purpose 'build-indexer' target is to compile the java source that >> is used for indexing the content. For a end- user this target is of >> less use, unless s/he plans to change java source. >> Running only 'webhelp' target should create the search tab. But we did >> made creating the search tab optional. Ie if user doesn't need it, >> s/he can drop it. >> It is done by a property in build.properties file called >> exclude.search.from.webhelp. Setting this to true will drop the search >> tab. >> >> But, I couldn't figure out the reason For your case, assuming you >> didn't change that property. Can you please pastebin the ant webhelp >> output as well? Now, I'm not away from my computer I will look in >> further possible causes for your issue and will update list. >> >>> Here's the command output -- not sure if it's completely normal: >>> >>> $ ant build-indexer >>> Buildfile: build.xml >>> >>> build-indexer: >>> [mkdir] Created dir: ~/webhelp/indexer/lib/htmlsearch >>> [javac] Compiling 9 source files to ~/webhelp/indexer/lib/htmlsearch >>> [javac] Note: >>> ~/webhelp/indexer/src/com/nexwave/nquindexer/IndexerTask.java uses >>> unchecked or unsafe operations. >>> [javac] Note: Recompile with -Xlint:unchecked for details. >>> [jar] Building jar: ~/webhelp/indexer/lib/nw-cms.jar >>> [delete] Deleting directory ~/webhelp-db4/indexer/lib/htmlsearch >>> >>> BUILD SUCCESSFUL >> >> This is normal, and this has no connection with the issue above. >> >>> >>> >>> 2. I looked at the Search tab on the online package >>> (http://www.thingbag.net/docbook/gsoc2010/doc/content/). Verified >>> that search results are synced with the TOC. However, noticed this >>> glitch: >>> >>> When I enter a search query and click a link in the result, the >>> target topic has a big, light blue input button with the letter H in >>> it, just beside the top arrow nav button. The button appears on every >>> Search target that I open, but is hidden when I open topics from the >>> TOC instead of Search. >> >> It is removed now. That was a intermediatory thing. >> >>> >>> 3. The source has indexterm elements but no index. You might consider >>> adding an index element to the end of the book, just so the build >>> generates an index. After, this is one of the advantages of WebHelp >>> over DocBook Website! >> >> Index is already there, as the last link in TOC tab. Did you mean that >> or adding a separate tab for index, along with 'contents' and 'search' >> tabs? >> >>> >>> I did verify that the TOC stays synced when I navigate using the index. >>> (Exception: 'Web-based Help from DocBook XML Readme' has an index >>> entry but no TOC link. Since this is the bookinfo component, I think >>> WebHelp effectively syncs to the top of the TOC.) >> >> Ok. We missed that. I'll add an link to the bookinfo component. >> >>> >>> Thanks so much for this work, Kasun, I hope this feedback is a little >>> bit useful. >> >> Thanks to you as well for the great feedback! This will help us to >> make webhelp better. And special thanks should go to my mentor, David >> Cramer for his great support. >> >> Please point out further glitches you notice. >> >>> >>> Denis >>> >>> P.S. While looking at WebHelp, it suddenly struck me that your >>> frameless design makes implementing context-sensitive help a >>> no-brainer. I remember all the work Jirka had to do to add support >>> for application hooks in the htmlhelp stylesheets, because we had to >>> go through the CHM browser's protocol. With WebHelp, F1 from any >>> control just needs a simple URL link to an HTML page. That's a major >>> selling point, IMO. >> >> Yes it is. With this Css-based approach, users will land on correct >> URL when coming from search engine results, which is not the case if >> framesets were used. >> >> Thanks, >> --Kasun >> >> >>>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]