Re: Where we'll put docs for control-center



May I also add something to this thread? 

1. Nautilus is, IMHO, too slow to be used as a help browser - on my
   machine, it is intolerably slow. Yes, I have an old machine. 

2. I do like gimp help browser for quick lookups of something in
   docs. Actually, I like it much more than ghb. For example, it does
   provide index for the document.  On the other hand,
   there are some things that it does not provide. E.g., it can't use
   Scrollkeeper to show the list of all docs on my system, or include
   TOC in the sidebar. 

Thus, in my opinion it would be ideal if we could provide the user the
choice of what help browser to use: 
Nautilus (slow but best for browsing avalialable documentation,
          searches, etc)
Gimp help browser/ghb/ or even any html browser - for quick lookups 



The only problem is, we need to take care of sgml->html
conversion. We could ship both sgml/html, but then it at least doubles
the package size - which is large as it is. Or maybe, do it at install
time? 

But we really must ask developers - how much trouble it would be to
implement the above? E.g., the index system which is being worked on
for Nau - can we also use it with gimp help browser? 

Sasha






On Sun, Aug 12, 2001 at 12:17:11AM -0500, Kevin Breit wrote:
> On 10 Aug 2001 23:53:08 +0200, Rebecca J. Walter wrote:
> > perhaps it means we need to use something different for a help browser.
> > in  my opinion, nautilus is way too heavy to even CONSIDER for this.
> 
> Rebecca,
> 	Hallaluia (sp?)!!!  Seriously though.  I don't understand entirely why
> Greg feels that Nautilus IS the current solution for our help problems.
> 
> - Nautilus, in itself, is a heavy program (don't deny it).  Back at
> Ximian, I could tolerate reading documentation in it.  But here on this
> 300Mhz/64MB box...well, I want help, not my disk to swap.  As the end
> user, I don't want to wait 30 seconds for my help stuff to show.  The
> average computer user has the attention span of 15 seconds before you
> lose them (look at me for an example ;).  While a lot of us aren't on
> such old hardware as myself, I think a good portion of us...are.
> 
> - This is probably a solvable problem.  But, it's how we treat the
> sidebar.  If you go more than 2 or 3 levels into the tree in the Help
> tab, you need to stretch out the sidebar.  This is a nusance for the
> user.  Then when you make it wider, it's too big to be a sidebar, and at
> this point, arguably, deserves its own window or frame, not a sidebar.
> 
> So...I've said some pretty anti-Nautilus words.  I could be a jerk and
> go on, or I could propose some half-assed idea that PROBALBY won't ever
> be implimented.  I'll go for the later ;)
> 
> - I'd really like to see ghb2 be released.  I'm sure Greg is dying here.
> Seriously though.  From what I can tell, ghb ISN'T a big piece of code.
> It seems to be basically a window with HTML rendering widgets.  I like
> this idea.  Why don't we make a BASIC help browser.  Or how about lets
> take a que from Apple Computers?  It's its own application.  It'll open
> up in its own window.  It'll have its own searching, categorization, doc
> viewer, etc.  Wana embed it in your application?  Good, it's all
> bonoboized.
> 
> Why do this?  We can do a help system...the right way.  We can probably
> design the UI ourselves (with input of course).  We can make it run on
> older and newer hardware alike.  We won't be bound to Nautilus or
> whatever other things are there.  The user not want help at all?  Great,
> don't install it AT ALL!
> 
> That's my opinion and what I'd dig :)
> 
> Kevin Breit
> 
> 
> _______________________________________________
> gnome-doc-list mailing list
> gnome-doc-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-doc-list




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