Re: Nautilus as help browser - first impressions.

[Ali Abdin <aliabdin aucegypt edu>]

* Elliot Lee (sopwith@redhat.com) wrote at 04:12 on 24/08/00:
> On Wed, 23 Aug 2000, Alexander Kirillov wrote:
> 
> > -------------
> > 1. Help tree (in the left panel): 
> >     This tree contains "Applications",
> >     "Development", "info", "manual" and "system". To my surprise, most
> >     of man pages are *not* in the section "manual". For example man
> >     pages for user commands (Section 1) are in Applications->Command
> >     line and man pages for section 5 (File formats) are in System
> >     ->Configuration. I strongly object. I never thought that xeyes is
> >     a command line application. On the other hand, tar is a command
> >     line app - but info page for tar is not in Applications->Command
> >     line. I'd rather have no attempt in categorization at all than
> >     such half-baked one.
> 
> I disagree - I would rather have the man pages categorized loosely than
> have them in
> 
> There are two problems though - if the label "command line" is there, that
> is incorrect, maybe Ali did that. Also, I think I intended to have a map
> to put specific man pages into specific tree locations - I'm pretty sure I
> implemented something like that (or maybe that was for info pages).

No - I did not. I have not touched hyperbola at all since working on the help
stuff. 

To be honest - I advocate the re-write of hyperbola to a much more simple
'Help Contents' list (yes it would include man/info). The reason for the
re-write is:
A) hyperbola is buggy
B) hyperbola is unmaintained
C) nobody really knows its 'real purpose'
D) hyperbola is "incomplete"
E) We would like a system that would incorporate the 'Dewey' system (which
uses the OMF stuff)
 
> > 4. Info pages: 
> >    Info pages are rendered OK. However:
> >    a. It can't find info pages if they do not have "info" in file
> >      name. On my system, many info pages do not - e.g.,
> >      /usr/info/emacs.gz. Thus, "info:emacs" does not work. 
> 
> Your system is broken, then. :)

This is filed as a bug report in bugzilla. I'm not sure what to do about this
bug :)
 
> >    b. There is no way to view the top level info file (dir.info)
> 
> If you mean /usr/info/dir, then no, you can't view it because it is not an
> info file. I do not think it is useful, because it mostly duplicates what
> is in the tree, and people care more about finding documentation than
> finding a list of documentation in a specific format.

I agree with Sopwith here.

> > 5. html docs 
> > 
> >    at the moment, help:appname can't find "index.html" (fixed by Ali
> >    in CVS, I believe), but "help:/path/to/file" works, and html docs
> >    are rendered well. 
> > 6. sgml docs
> > 
> >    I only tried "help:/pat/to/file.sgml". It works fast (on my system
> >    - PIII 500Mhz, 128 Mb RAM) even for large ones like "GDP
> >    handbook". But here are problems (some of them already discussed in
> >    gnome-doc-list, but anyway): 
> 
> > Wishlist: 
> >   
> >    1.  It'd be great if we could put the table of contents (TOC) of a doc in
> >        the left panel so that you have a section shown in the right
> >        panel and TOC in the left panel at the same time
> 
> The intent at one point was to have the TOC be part of the help tree under
> each doc.

yeah that would be nice - but you would need a way to get the TOC output from
gnome-db2html2 into the sidebar. Or you could just write a 'quick mini-parser'
in the sidebar to generate the TOC - I do not think this is a priority though.