Re: crossreferences in installed xml

[Matthias Clasen <maclas gmx de>]

> fre 2002-05-31 klockan 12.32 skrev Matthias Clasen:
> > > 
> > > Sorry for the late reply. 
> > 
> > Thanks, anyway.
> > 
> > > 
> > > As I said, ghelp doesn't do any lookups in scrollkeeper, therefor you
> > 
> > You mean yelp doesn't do any lookups when resolving ghelp: uris, or do
> > you mean that ghelp: is not specified to allow such lookups ?
> 
> The ghelp: uri scheme is defined in this document by Jonathan Blandford
>
http://lists.gnome.org/archives/gnome-doc-list/2001-September/msg00000.html
> 
> So yes, ghelp is not specified to allow these lookups and thus neither
> libgnome or Yelp does them.
>  
> > > need to put all documents in one place. This is probably fine for all
> > > the user docs (and might very well be for API docs too). Though I
> don't
> > > think this is the correct solution since the API docs doesn't really
> fit
> > > in $(prefix)/share/gnome/help, at least I don't think so.
> > 
> > My current thinking is that the xml api docs will end up in 
> > ${prefix}/share/gtk-doc/xml, to go alongside the html docs in
> > ${prefix}/share/gtk-doc/html. According to what you said above, this
> > will automatically take care of having the api docs not appear among the
> > user documentation in yelp...
> 
> OK, so this is how Yelp works (short version) :)
> 
> It reads information about available documents from ScrollKeeper and
> puts them in a tree structure internally (this is used to provide the
> views of available documents). This information contains full paths to
> the documents on the form ghelp:/usr/share/gnome/.../foo.xml.
> 
> When someone wants to open a URI with Yelp from the command line (or
> >from another application), Yelp is passed a ghelp-uri (which can be on
> any of the forms proposed in the document by jrb).
> 
> Yelp then converts this URI to a full path URI (by using
> $prefix/share/gnome/help directory). If it finds it, it's displayed,
> otherwise it gives an error.
> 
> So, when looking up a document Scrollkeeper is never used, which I think
> is stupid, I would my rather have it so that the uri scheme worked from
> scrollkeeper rather than some directory on the hard disk.
> 
> I don't know how it should be done to change the ghelp: uri scheme and
> still contain support for the old path based one.
> 
> Perhaps we should just add to it that first it should be looked up in
> scrollkeeper and if it's not found it should go to the path described
> above.
> 
> So if we put the documents in Scrollkeeper (which I really think we
> should) they will be available in Yelp (which we don't want), so my
> proposal here is to put all the API documents in Yelp in a single sub
> category (API or whatever), and then let Yelp filter out this category.
> Modify Devhelp to use Scrollkeeper rather than it's own weird format.
> 
> In the long run I want to somehow merge large parts of Yelp and Devhelp
> and just provide different GUI's (at least possibly).
>  
> > PS: What about simple xpointers ? Will yelp/devhelp grok something like
> > <ulink
> >
>
url="file:///usr/local/share/gtk-doc/xml/glib/glib.xml#g-malloc">muh</ulink> ?
> 
> Since this is a full path it will work. The problem is that it's not
> relocatable. Also, I'm talking about Yelp here. Devhelp is going to need
> quite some love to be able to do this. I think the best way to do this
> is to start of by just adding a switch to Yelp --devhelp or something
> and then let it show Devhelp information, but I haven't thought much on
> this issue.
> 
> Hope it cleared things up a bit :)
> 

Yes, thanks, I think I get the picture now. In particular, its interesting
to know
that yelp can be used completely without scrollkeeper (makes testing a bit
easier).

-- 
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net