Re: gnome-help: uris



On Mon, Sep 10, 2001 at 12:31:44PM +0800, Malcolm Tredinnick wrote:
> On Sun, Sep 09, 2001 at 11:37:22PM -0400, David Merrill wrote:
> > I'm having a problem with gnome-help: and similar uris. I knew that
> > those were being made available in the help browser for the user, but
> > I didn't realize that they were being used as uris in ulinks within
> > the docbook source. I need to figure out how to handle them.
> > 
> > Can anyone give me some pointers on how they are processed internally,
> > or how I might deal with them?
> 
> At what level are you wanting to handle them? I'm sorry, but I've
> forgotten what area of the help system you were working on, David (and
> your mail from last week is on a machine I don't have access to right
> now); could you give an example of where the problems are?
> 
> Inside a help-browser you would process a ghelp (or gnome-help) scheme
> by calling gnome_help_display_uri(). Not sure what you do if there are
> "info:" or "man:" schemes involved, since jrb's proposed API didn't
> cover those.

Hehe. I was the guy giving you all grief about not wanting to use a
help browser at all, but a web browser.

> Inside a "help server" that is designed to serve up HTML only pages, you
> probably want to rewrite them all in the output to be HTTP (or whatever
> protocol the help server speaks) references to the server. Then the
> server just needs to know how to do the XXX-to-HTML transforms.

That is what I want to do, but I'm not sure how I can reliably
translate a text string (gnome-help:foo) into the proper document in
ScrollKeeper. ScrollKeeper doesn't manage the documents using that
text string, but by a document id.

> What other situations are there where you have to treat "gnome-help:" in
> a non-opaque fashion?

I don't know yet, sorry. I'm tackling one problem at a time.

BTW, ScrollServer is coming along nicely. I can browse all the
ScrollKeeper documents -- I just don't have images displayed or
gnome-help uris handled. Rendering from sgml to html is using xsltproc
and it is *extremely* fast. Quite fast enough for daily use, according
to John Fleck.

It caches html results (no cache management yet, though -- it's cached
as long as the source file's timestamp is earlier than the html's
timestamp.

It handles online documents too, although they are not cached, just
linked diretly.

There is no chunking, which will add a whole new class of problems.

It's only ~100 lines of python. :-)

-- 
Dr. David C. Merrill                     http://www.lupercalia.net
Linux Documentation Project                   david lupercalia net
Collection Editor & Coordinator            http://www.linuxdoc.org

Free Dmitry Sklyarov!  http://www.freesklyarov.org
Washington DC Protests http://www.lupercalia.net/dmca





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