Re: Standardizing help paths



>  No, things have not been invented to handle specifying an abstract
>  location in the help. Let's say we continue using ghelp: as a URL prefix
>  (which is not so bad as long as we centralize the place where we do all
>  this URL translation, which is not the case currently) - we still have big
>  problems, because ghelp: is always of the form 'ghelp:appname' or
>  'ghelp:appname/filename.html#section', which is not going to allow
>  flexibility in indexing or switching to XML displaying or what have you
>  (in indexing, for example, we need to be able to be able to find the html
>  file & section that corresponds to a specific part of the SGML sources,
>  and vice versa). The easiest way to solve this problem is to use an
>  abstract addressing method that can be mapped to different content
>  implementations.

Right now we have the $(datadir)/gnome/help/appname/[lang]/topic.dat stuff,
which looks like

	foo.html	Using FooApp
	bar.html#blah	Doing blah

It gives the titles of the things that go in the Help menu, and maps
them to HTML files with anchors.

We should deprecate this setup.

We can already put ID fields in the DocBook sources, so we should use
them.  We need a reliable way to map these IDs to the final HTML
sections.  Mark and Dave say that this can be done.  If that is the
case, then all is easy.  I don't know if this is a valid URI, but we
could use "ghelp:appname#id", where id is the one you put in the
DocBook source.

To automatically generate the stuff in the Help menu, we could turn
topic.dat to look like

	someid		Using FooApp
	someotherid	Doing blah

instead of specifying the actual HTML/anchor stuff.

If we cannot reliably map IDs to HTML/anchor strings, we need a file
that gives us the mapping.  This should be generated by Jade.  In any
case, the stuff the app specifies should always be the DocBook IDs.

Now, a question for the DocBook wizards.  In addition to IDs, there
also is "anchor" tag, which marks a spot in the text.  Is this
relevant for the help stuff?  Semantically, how is it different from
the IDs?

  Federico



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]