Re: Thoughts.

[Donovan Rebbechi <elflord@pegasus.rutgers.edu>]

> without a clue generating docs onles the program to do it is pure
> WYSIWYG.
> THAT by the way is an important option.  There must be at least one
> simple 
> word processor like WYSIWYG authoring tool to produce this metafile
> format.

Not if the format of the file is very simple and doesn't require the
author to remember any kind of markup tags (which is the case in HTML)
The problem is not that the author needs to see what they're doing
(indeed, this is a clear cut example where they need to focus on 
content and just let the parser take care of the form) 
The real issue is that the author shouldn't have to remember 
complicated markup tags (like they would need to if they wrote 
standard html)

> Also I would distribute the DOCs as HTML, regardless of what format they

yep. I am 100% for html as a format for online help. 
Like you say, the portability is a big plus.
Of course, html doesn't print quite so well though. 

> > without data loss ?
> >
> None whatsoever.  but do we want any new help format ?  

I am proposing a new format for writing the files, not reading/
browsing them. This is an important distinction to make.

> > In fact, to enforce consistency in the look of the help system, some kind
> > of text file "marked up" to the other formats would be better. For example
> > :
> > %TaskName       Copy
> > %TaskGroup      /KDE/file-management
> > %Author         Donovan Rebbechi <elflord@pegasus.rutgers.edu>
> > %Description    A tutorial on copying files in KDE
> > %Steps
> > %1      blah blah blah ...
> > 
> > OK, I ripped this idea off the RPM spec file thing. The point is that html
> > offers too much scope for the author to put in junk that's not needed or
> > wanted, and it will take a more restrictive file format to be effective.
> > This does not require much of the author, since some-one not familiar with
> > the format can write one of these things by editing another one, since the
> > format is very canned.
> >
> Makes a lot of sense.  and ?I can see how this would be easy to
> translate 
> into HTML.

Yep. So easy that I could write the program (and I'm not a programmer...)

> Then they should be fixed.  but do we care ?  


probably not (-: the thing to do is to write task help on using tar.
The man format is comprehensive by design and 90% of the tar
options are never used by the beginner (as you state below)


> Which is why moving the stuff that is in there now to /usr/doc/pachages
> is such a brilliant idea.  

There's probably nothing wrong (??) with putting the packages there.
since very few programs seem to depend on /usr/doc being where it is. 
One thing to keep in mind: this will cause incompatibilities with
rpm and dpkg formats. 

RPM itself  assumes that the "package info" such as README/COPYING
etc goes in /usr/doc. I almost wonder if the rpmrc file allows
you to change the doc directory. (you'd hope so...)
this is worth checking. 

> Other distributions may follow us. 

yeah, once SEUL really is a distribution, they might (-:

> 4 : Modify the /etc/profile

woah ... actually, I'd hope the installation routine would do 
this. However, for now, I guess they might not. 


	--Donovan
_____________________________________________________

Donovan Rebbechi, Lord of the Elves, 
Dept of Mathematics, Rutgers University Newark

Visit my webpage: http://pegasus.rutgers.edu/~elflord
*****************************************************
>