130733 - index and search generation should be done a part of the build process

Status: RESOLVED WONTFIX

(SeaMonkey :: Help Documentation, enhancement)

Description

[Ian Oeschger (gone)]

The Python files that create the index and the search database for the help
viewer should be run as make targets

Comment 1

[Ian Oeschger (gone)]

Attachment: sample make rules for generating index and search database

This should be made part of the Makefile.in/makefile.win in help/resources

Comment 2

[Ian Oeschger (gone)]

Attachment: generation script that gets called during make

Comment 3

[robinf]

Putting this on the Buffy train.

Comment 4

[Vincent Béron]

The Python script misses quite a few SDX anchors in the html files.
I tried to look into, and there are multiple causes:
- If 2 (or more) SDX anchors are on the same line, then you miss the second one
(regexp?)
- It seems it misses all the SDX anchors with a colon in it (regexp?)
- There are some other ones that are missed as well, but I can't find why (eg,
QuickLaunchSDX and Quick_LaunchSDX in cs_prefs_nav_advandced.html) (no clue)

My Python knowledge is nil, so somebody else will need to look into it.

Alternatively, I have some home-brewn sh scripts that do almost the same (for
the purpose of the french translation), if you're interested.

Comment 5

[Brant Gurganus]

Milestone needs updated, any new status?

Comment 6

[Ian Oeschger (gone)]

moving stuff over to an outside-the-firewall email for the time being, looking
for people to pick these Help and doc bugs up for me.

Comment 7

[R.J. Keller]

mass reassign of all of Ian Oeschger's bugs to me (R.J. Keller).

Comment 8

[R.J. Keller]

Brant, what do you think of this? It would save a lot of time for us, but it's
out of my expertise. If you want it, take it, otherwise just put helpwanted
keyword and leave it open.

Comment 9

[Brant Gurganus]

I think we can do this, but we need to wait until Help gets integrated with the
regular tree and the content pack issues get sorted out.

Comment 10

[R.J. Keller]

What do you think about Seamonkey? I have no clue how to fix this one, so if you
have the knowledge, then do it.

Comment 11

[R.J. Keller]

I'm beginning to disagree with fixing this. I like having control over the TOC
and Index.

Comment 12

[R.J. Keller]

I've been thinking about this bug a bit lately, and how about we generate the
TOC using the build system but not the index? The index (especially in the XHTML
help docs) is very difficult to generate from a build system. The TOC would be a
piece of cake once the XHTML docs are moved over.

Brant, if you got an idea for this bug, feel free to tell me. :) Maybe a perl
script or something.

Comment 13

[Vincent Béron]

It's difficult to generate the index now since there's not always IDX at the end
of corresponding tags. With those, it was a piece of cake, especially for
translations.

Comment 14

[R.J. Keller]

True, but I'd prefer not to do that. There's too many anchors that do nothing
becuase of that. I'd rather have the index not generated by the build system,
and since search-db.rdf is long gone, no need to worry about that. The glossary
could probably be generated.

The TOC would be a piece of cake with the XHTML documentation because it has <h1
id="">, <h2 id="">, etc.

Comment 15

[Vincent Béron]

Re TOC: when a top-level category is in a whole file, yes. When it's split in a
couple files (as it is now for eg certs_prefs_help.html), I don't see how you
plan to do the reparenting.

On a more general approach, I agree with moving towards a way to do it with a
script/program.

For the index, how about using all anchors, ie giving each one a category?
That'll solve the automatic part. Or are there some that you don't want to see
in the index?

How do you plan on generating the glossary? You need the definitions somehow...
(or was it glossary.rdf from glossary.html?)

Comment 16

[R.J. Keller]

> For the index, how about using all anchors, ie giving each one a category?
> That'll solve the automatic part. Or are there some that you don't want to see
> in the index?

No, it's the opposite. I have some areas of the index (plugins, for example)
that I would like to appear multiple times. For example, there should be a
"Editor" index entry and a "Composer" index entry. I do not want multiple
anchors (which would throw off the TOC generation anyway).

> How do you plan on generating the glossary? You need the definitions somehow...
> (or was it glossary.rdf from glossary.html?)

Same way you would get the titles for the TOC and index. Currently, the glossary
has <b id="my_definition">My Definition</b>, just like how the TOC has <h1
id="my_title">My Title</h1>.

Comment 17

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 18

[Jens Hatlak (:InvisibleSmiley)]

The last (real) comments in this bug are from 2003, so way before we switched to the Toolkit Help viewer (which we did between SM 1.1 and 2.0). The old XPFE Help viewer had a sidebar with multiple vertical tabs (like the browser sidebar): Glossary, Index, Search, and Contents. In the new setup, the tabs have been (re)moved: Glossary is only linked from Help contents, i.e. it has no place of it own anymore. Index is gone (!), so is the need to create it. Search is now a search field (top right edge of the window). Only Contents is left unchanged.

The search uses an index file that is actively maintained, i.e. it should *not* be generated automatically. The same applies to Contents (different file, same idea).

As such this bug should probably be marked WONTFIX.

Ian, is the above analysis correct?

Comment 19

[Philip Chee]

> As such this bug should probably be marked WONTFIX.
Done.