>> 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
>> <[email protected]> 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
>>
>>
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
