🚀 go-pugleaf

Again, as long as we're on the subject of standards, how do people
feel about having some sort of disk layout standard, like Unix has
(i.e. the binaries are kept in /bin, system database files are kept in
/etc, user files are kept in /usr, manuals for programs are kept in
/usr/man, and so on).

Having a standard of a few common directories would mean that
programs could make assumptions about directory structure to allow
users that aren't expert enough to edit files or pathname lists or
just "don't know what the heck is going on" to get by with few 
problems most of the time they use or install applications.

Installation scripts or programs could be distributed for each program 
that would automatically take care of unpacking, putting the binary,
the manual file and help file(s) in standardized directories, adding a
line to the desktop.inf so that double clicking a data file starts the
application, and...(do you want to add anything?)

For GEM applications that require at most one resource file but no 
other extra files, we might have one directory to put these (I call 
it c:/gembin on my system) and store the doc files in say, 
c:/usr/gemdoc so that they're only two mouse clicks away.  Where to
keep the resource file?  I'd put it in c:/rsc or out of the way in
c:/usr/gemrsc if possible, but some programs require the rsc file to be
around the prg file (or even worse, in the root directory).

For bigger GEM applications, some of these require an obnoxious 
/itsfatname folder to be present.  We may have no choice but to continue
this trend.  I would prefer to put these folders in c:/gembin myself, or
under something like c:/wordproc or c:/apps.  The day might come when a
novice user could install software on his hard disk by simply double
clicking on the standardly named install.prg (or install.sh, or whatever), 
not having to know anything about GEM other than how to open "things" on 
the desktop.

That reason alone (the continued sanity of non-quasi-experts in 
the user base) is why I haven't been one of the many critics 
complaining that Atari shouldn't have made the hard disk on the TT 
a standard option (I feel justified in complaining about its price,
in Canada at least).

People might balk at the inconvenience of putting GEM applications 
too many levels below the root directory.  OK, maybe now it is, 
but if we had a builtin desktop that allowed putting frequently 
used executables on the desktop next to the file icons, this 
wouldn't be a problem.  Neodesk and probably some other 
replacement desktops allow this, but forcing people to buy 
something to be part of a standard is a great incentive not to 
follow the standard.  Put this one off, I guess.

Another thing to think about is the partitioning scheme, but that
may be too device dependent for us to agree on a standard (some people 
may have 20M, others 200M).  If we wanted to get around that, looks 
like mounting one partition from another is the nicest solution (so 
that /bin on c: is actually linked to the root of d:, for example).
When TOS will allow this is a good question.  An alternate file 
system running under MiNT seems like our nearest chance for this.


So, to sum up, how about these preliminary choices:

What				Where				When
--------			------				----
'Text' Binaries			c:/bin
Small GEM Binaries		c:/gembin
Large GEM Binaries		(In the application's folder)	now
				c:/gembin/<appname>		future
RSC files			(no choice)			now
				c:/usr/gemrsc 			future
'Text' program Doc files	c:/usr/man
Small GEM App doc files		c:/usr/gemdoc
Large GEM App doc files		(In the application's folder)	now
				c:/usr/gemdoc/<appname>		future
'Text' program help files	c:/usr/man/extra ?
Large GEM App Help files	(In the application's folder)	now
Large GEM App Help files	c:/usr/gemhelp/<appname> 	future
System database files		c:/etc
Fonts				c:/gemsys or whatever		now
				c:/etc/fonts 			future
desktop.inf file		/				now
				/etc/desktop.inf 		future
Accessories to load		/				now 
				check /, then /usr/accs		future
pre-GEM programs to load	/auto 				now
				check /auto, then /usr/auto	future

Well, post up what y'all think.  Look out -- if this gets far enough
maybe Atari will include some of our ideas for this on its new TT 
disks, or even ask official developers to abide by it.  It will 
be worth it even if it gets them to think in that direction.


plin
--
----- ---- --- -- ------ ---- --- -- - -  -  plinio@seas.ucla.edu 
I don't think, I'm crazy.