plinio@crowe.seas.ucla.edu (Plinio Barbeito/) (03/21/91)
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.
rosenkra@convex.com (William Rosencranz) (03/21/91)
In article <2232@lee.SEAS.UCLA.EDU> plinio@crowe.seas.ucla.edu (Plinio Barbeito/) writes: >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). no problem here. i would hazard a guess that most cmdline shell users do this already. >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?) if you supply source (or even binaries) there is generally a makefile present. of course that assumes the installer has make and knows how to use it. make can very easily put things in the right place with relatively simple changes in the makefile, generally only 1 or 2 macros. just posted to comp.sources.unix is the purdue install system. i have not really looked at it yet, but it could probably be adapted for this use. think of this sort of program, universally accepted, as analogous to the patch program for updating source files. a well written README should be all you need, but that can often be asking too much. in all fairness, constantly changing stuff like gnu c can be a pain to document well. it is a catch-22 that this is just the sort of thing you DO want to document because of its complexity. on the other hand, a while ago i harped on TeX because of its rather limited installation instructions. and TeX is a VERY complicated system, even for otherwise expert users. in the last few weeks i saw numerous requests for help here in installing TeX. >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. i can propose another alternative: for those capable of running a binary patch editor, building in patch space in internal path strings is easy: char *path = "C:\\GEMPROG\\SUBDIR\\FILE.DAT\0 "; then you can just hack in a new location (or better yet, provide a simple tool to do it for the user. another thing might be to provide a configuration file (a la the DECKTOP.INF) though you then have more or less the same problem: where to put theses suckers. it usually ends up in root directory. i prefer the patch space scheme, even for code which i have src for. it takes 10 seconds to patch an executable which might take minutes or more to recompile. [ suggested locations for things deleted ] you have the technical stuff nicely squared away. however, you are probably reaching only a tiny fraction of people writing code in this forum. i doubt that this sort of thing can be standardized, with the possible exception of unix-like environments which have a well defined model. however, i like your ideas and may adopt some of them personally, since things seem well organized. good luck in your martyrdom :-( >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. i doubt atari would take a stand on this sort of thing. and they probably should not (or can not, at this point). it is really up to s/w vendors to set this sort of standard, mostly by brute force (i.e. having your program running on more systems than a competing configuration/product). where atari would take a stand is with the TT's support of unix. and they mostly do that by default (since unix defines the bulk of where to put things by tradition). don't get me wrong: i would love to see things standardized. fortunately, the cmdline faction here has a direction (more or less) defined by unix. the desktop faction is, has always been, and probably always will be on their own in this regard. there is no real GUI standard like there is in the mac world or even the PC/windows world, i suppose. there is no what i would consider "look and feel" standard for gem applications, IMHO. just the physical appearance of the window borders is not enough to constitute look and feel, regardless of what apple's lawyers might say to the contary :-). maybe that might be a more laudible goal for which to aspire... good luck. above all, keep thinking! -bill rosenkra@convex.com -- Bill Rosenkranz |UUCP: {uunet,texsun}!convex!c1yankee!rosenkra Convex Computer Corp. |ARPA: rosenkra%c1yankee@convex.com
david@doe.utoronto.ca (David Megginson) (03/22/91)
In <2232@lee.SEAS.UCLA.EDU>, Plinio Barbeito/ writes: > 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). Even Unix is not entirely standard, which is why Makefiles usually allow you to modify absolute pathnames for your system. That works fine for Unix, where practically all free programs are distributed in source-code form and all systems have a C compiler, but it would not work so well on the ST, where much of the distribution is in binary form, and absolute pathnames are usually replaced with environment variables. Until the ST support symlinks (ie. never), I don't think that we will ever be able to lay down a set of absolute rules for pathnames. The best bet is the Unixmode standard, which will allow you to refer to (say) c:/bin as /bin, etc. Eric Smith may build the standard into a future version of MiNT. -- //////////////////////////////////////////////////////////////////////// / David Megginson david@doe.utoronto.ca / / Centre for Medieval Studies meggin@vm.epas.utoronto.ca / ////////////////////////////////////////////////////////////////////////
plinio@crowe.seas.ucla.edu (Plinio Barbeito) (03/23/91)
In article <1991Mar21.100227.13538@convex.com> rosenkra@convex.com (William Rosencranz) writes: >In article <2232@lee.SEAS.UCLA.EDU> plinio@crowe.seas.ucla.edu (Plinio Barbeito/) writes: >>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?) > >if you supply source (or even binaries) there is generally a makefile >present. of course that assumes the installer has make and knows how >to use it. make can very easily put things in the right place with >relatively simple changes in the makefile, generally only 1 or 2 macros. The problem is that I don't want users to have to know anything more than how to double-click something to get started. Expecting them to have make, or to know how to use it is too much of an assumption. In more detail: the user buys a disk or downloads a file. He double-clicks on that file. It unpacks itself into the right directories on the fixed disk and (optionally) starts up the application (ideally, for security reasons, access is restricted to the application as to which directories it can write to). This is done in a *standard* way so that once the user has installed one application, he feels confident that he can install any product. The application puts an icon on the desktop so that the user can start it up in the future (without actually having to know where it is stored). To take it a step further, dropping the icon in the trash starts a deinstallation -- more than just the binary is deleted, an attempt is made to delete the files the application installed. This way, the user only has to be familiar with the aspects of the program that are important to him, not what support files have to be in what directory and so on. >just posted to comp.sources.unix is the purdue install system. i have >not really looked at it yet, but it could probably be adapted for this >use. think of this sort of program, universally accepted, as analogous >to the patch program for updating source files. If it isn't too huge, it may be worth looking into, thanks for the suggestion. >a well written README should be all you need, but that can often[...] The problem with README files is that you then have to figure out where to store them, and unless you have a folder on your hard disk for every little program you use (eek!) this gets to be a maintenance problem. >i can propose another alternative: for those capable of running a binary >patch editor, building in patch space in internal path strings is easy: > > char *path = "C:\\GEMPROG\\SUBDIR\\FILE.DAT\0 "; > >then you can just hack in a new location (or better yet, provide a simple >tool to do it for the user. I think you've missed the point. To make the ST truly user-friendly, the user shouldn't have to worry about any of this. ... >of unix-like environments which have a well defined model. however, i like >your ideas and may adopt some of them personally, since things seem well >organized. good luck in your martyrdom :-( Well, I didn't intend to _set_ a standard, just to open it up for discussion. Thanks for your compliments anyway... >good luck. above all, keep thinking! Uh, that will require a major effort on my part, but I'll try. ;-) plin -- ----- ---- --- -- ------ ---- --- -- - - - plinio@seas.ucla.edu This page intentionally left blank so that it could contradict itself.
rosenkra@convex.com (William Rosencranz) (03/23/91)
plinio@crowe.seas.ucla.edu (Plinio Barbeito) writes: >after i wrote: >>i can propose another alternative: for those capable of running a binary >>patch editor, building in patch space in internal path strings is easy: >> >> char *path = "C:\\GEMPROG\\SUBDIR\\FILE.DAT\0 "; >> >>then you can just hack in a new location (or better yet, provide a simple >>tool to do it for the user. > >I think you've missed the point. To make the ST truly user-friendly, >the user shouldn't have to worry about any of this. yes, i agree in a perfect world you should never have to think about the tools you are using. they should just automagically work. but in the real world there are always trade-offs and restrictions. you have to draw the line somewhere and make some assumptions, ALWAYS based on cost/ benefit (here cost can be development $$$ or time, generally the same thing). general purpose computers are still not for everyone. it would be nice to be able to walk into a room and say "computer: balance my checkbook, then tell me if i am in trouble". right now, we have to deal with files and less easy to use user interfaces. in 20 years we won't. but we'll have other problems. i have not missed the point. doing this and supplying an install program (can even be inside the program) can patch these locations and the user need only do it once. a well written program will manage this for the user. the only assumptuion made is that users understand what folders are and that they differ from files. and i don't see why it would be a problem to have one folder per application either. less sophisticated users are not going to have 2000 applications. more like 5 to 10. when they get to 20-30 applications, they are more sophisticated and you can expect them to know more and ask more of them. i know you are really talking about where to put things for each program. that means something like you said: put all gem binaries in one place, put all rsc in one place, put all readme/docs in one place. this may mean changing some file names (there may be 150 README files). at the same time the true novice may not know that app.prg is the program (.prg is a "standard" name) and that gem programs generally have things called resources, .rsc (note for nitpickers: i know there are lots of programs with imbedded resources and in most cases, not all, this should be more common practice). he only knows what s/he is told. it also means that the novice will have to know more than you may think, organizational things. letting a program do its thing as if it were the only program the user runs is not necessarily bad, since there are users who only do word processing or only play games or only DTP. there is a lot of bad software out there. at the same time you really can't blame developers on the ST for being sloppy. some stuff is ported from other platforms. and the future of the ST is always debatable. your proposal also means getting lots of developers and perhaps atari behind this. i would not hold my breath. i don't think there is a painless solution. i think your ideas are good, but i don't think inertia can be overcome here. it appears that gem applications are more like islands. this is not the case with unix where pipes and other artifacts insure that applications work and play well with each other. look, if i am meeting resistance to something as innocuous as "-help" which is totally invisible, what makes you think 100's of developers are going to adopt your scheme, no matter how reasonable/rational it is? and for the record, i think it IS reasonable/rational. but the real issue is promulgating a standard, not the technical details associated with it. like most human endeavors, it is political. you have to deal with that as well, considering what is the impact with and without said standard. i did't realize how verbose i can get! sorry... -bill rosenkra@convex.com -- Bill Rosenkranz |UUCP: {uunet,texsun}!convex!c1yankee!rosenkra Convex Computer Corp. |ARPA: rosenkra%c1yankee@convex.com