Hi Luke, Il 18/12/2011 16:51, Luke Campagnola ha scritto: > On Sun, Dec 18, 2011 at 06:56, Antonio Valentino > <antonio.valent...@tiscali.it> wrote: >> Not sure to understand correctly your purpose. >> Currently many (not all) of the keyword entries in the .qhp also have an >> "id" (I'm using the sphinx documentation for testing). >> >> Do you want to have different ids or you just need to add missing ones? > > The <keyword> tags in Qt's .qhp files may contain an "id" attribute, > "name" attribute, or both. Anything with a "name" will be included in > the index when viewing the document. Anything with "id" may be called > internally by the program to display a specific section of the > document. >
OK > If I understand the qthelp builder correctly, its behavior is to turn > all sphinx index entries into .qhp keyword tags with a "name" > attribute. If the index entry looks like "indexEntry (location)", then > the resulting keyword tag will also have id=location. So this allows > the program to display a specific section of the document IF that > section also has an entry in the index. (please correct me if this is > incorrect) > correct > My patch creates keyword tags from reference labels instead of index > entries. It sets the id attribute to the reference label name and does > not include a name attribute (so the keyword does not show up in the > index). This enables the program to display locations in the document > without requiring that they have a corresponding index entry. > Ok. My concern regards the fact that almost all the keyword entries added in this way are in some manner duplicates of existing ones. Just they have a different id. > It seems to me somewhat unnatural to create keyword IDs from the > "indexEntry (location)" format, but perhaps there is already a > precedent for this elsewhere? I find it much more natural in my > program to request document locations based on their reference label > rather than their index entry (but this is just my preference). > Yes, I agree with you that if you need keywords with ids then the current implementation is absolutely not the best choice. When I wrote the original patch for adding qthelp support I didn't care at all of ids I just wanted to replicate the document index to allow interactive search. Now you are suggesting that ids are actually useful for other purposes and again I agree with you. Just I'm trying to have a better understanding of the problem. >> Please note that the decision of add ng an id or not is currently made >> in the keyword_item( method >> >> https://bitbucket.org/birkenfeld/sphinx/src/65e4c29a24e4/sphinx/builders/qthelp.py#cl-253 >> >> using the _idpattern regexp >> >> https://bitbucket.org/birkenfeld/sphinx/src/65e4c29a24e4/sphinx/builders/qthelp.py#cl-25 >> > > I saw that, but adding my functionality through the keword_item method > would have required more substantial reorganization of the existing > code (since the path build_keywords -> keyword_item is written > specifically for processing index entries, not reference labels). I > opted instead for a more minimal modification. > Understood, but if you think that a non-minimalistic approach is a better solution please let me know, I could help to implement and test it. Meanwhile I started a fork [1] on bitbucket.org to share the code. Your patch seems to work good, just I added some escaping. [1] bitbucket.org/avalentino/sphinx >> In any case (both in the current implementation and with your patch) not >> all labels around in the doc are collected as keywords in qtdocs. > > I think correcting this may be out of my reach at present--my > understanding of the Sphinx internals is quite poor. I may revisit the > issue later if it causes me trouble. > > > Cheers, > Luke > ciao -- Antonio Valentino -- You received this message because you are subscribed to the Google Groups "sphinx-dev" group. To post to this group, send email to sphinx-dev@googlegroups.com. To unsubscribe from this group, send email to sphinx-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sphinx-dev?hl=en.
