Re: Flattened GNUstep structure?

[Pascal J. Bourguignon]

"Christian Edward Gruber" <christian.edward.gruber@gmx.net> wrote
> Hi Pascal.  I respectfully take philosophical exception to your approach
> here.
> 
> Pascal J. Bourguignon wrote:
> > Make a system usable even by a fool and only a fool will use it.
> 
> This is an extremely frustrating statement for me.  

Sorry, that was not the intention.  I agree that my statement may have
been a little too strong, however, it concisely expressed what I mean.


> Do smart people not use
> toasters, or automobiles either?  The above quoted statement is the sort of
> anti-human-factors nonesense that keeps smarter stronger healthier
> more-robust software from becoming "main-stream" whilst pieces of total crap
> become the industry standard.

Well,  far from  me  to prevent  make  our systems  and software  more
"intelligent" and smoother.



Avoiding the  "deep" directory  structure will not  simplify anything.
It's never seen by the user.  It's rarely seen by the developer or the
administrator.  Most of these ${CPU}/${OS}/${LIBCOMBO} are hidden deep
in .app, .gdladaptor, .framework, or  other file packages, or in *_obj
directories,  all of  which are  managed  by the  Makefiles. The  only
others are encountered in  developer directories such as Libraries and
Headers, where it would be difficult to flatten them anyway.

NeXTSTEP  had /usr/include/arch/{sparc,i386,m68k,...}/ too.
Nobody tries to flatten /usr/src/{bsd,hurd,linux}/arch/{sparc,alpha,i386}.
Why would we want/need to flatten GNUstep? 


I understand  that it  may be difficult  to understand that  when some
extensions are found  in directory names it means  that you should not
look  inside  the directory.   We  need  GWorkspace.app  to make  that
clear. When  you look at your  TV screen, you don't  unscrew the cover
because  there's   this  notice  "Opening  the  case   will  void  the
warranty!". Well, it's the same here. Enter these directories, and the
warranty of  GNUstep will  be void. And  that's because  the designers
know that  you'll feel  the need to  simplify and "flatten",  and that
will lead to catastrophes.


I  mean, if  we  were on  MacOS, all  this  stuff would  be stored  in
resources, and nobody would talk  about flattening the struture of the
resource  forks. Well, actually,  resource forks  are quite  flat, and
that's  a pain.   Here we  have  the chance  to be  able to  structure
logically your low-level stuff, really  I don't understand why one may
want to flatten it. Nobody  would gain anything by flattening (oh yes:
two inodes per flattened tree; just do a df -i to see what a gain that
would be!), while a lot of convenience and generality would be lost.


> One of the key benefits of NeXTSTEP in the first place was that both really
> really smart people AND complete computer illiterates could use it.  My wife
> after years of computer phobia became sufficiently courageous enough to
> overcome her "neo-luddite" (self described) attitude, because she saw how
> elegant, simple, and obvious the NeXTSTEP approach and interface was.

This has nothing to do with our directory structure.


> Meanwhile, I was able to do things with its development system that I simply
> couldn't have done with my programming resources in (nearly) any other
> development system.

And the  directory structure of  NeXTSTEP and the structure  of Mach-O
files did certainly help here.

 
> > It  would  be  much  better  to write  some  documentation  about  the
> > directory structure than  to have this discussion and  to develop some
> > complicated scheme  to flatten the directory structure  and still keep
> > the feature the deep structure implements.
> 
> Yes and no.  Yes, write the docs.  Of course, that's obvious.  But don't
> develop a complicated scheme to flatten, develop an elegant scheme to
> completely insulate the users from the deep structure OR flat structure.

The  users  are  already  insulated  from  our  implementation  "deep"
strutures.   It  may not  be  flashingly  apparent  because up  to  now
GWorkspace.app did not exist.


> And simplify the structure to the level where it achieves the objectives
> elegantly and without excess confusion.  If the current system is that level
> of simplification, then so be it, but the answer is not to poo-poo those who
> would seek a simpler solution.

Yes. But beware of the simplistic solution. It's not the simplier!






If  you really  want  to simplify,  there's  one thing  that could  be
simplified:  instead of  naming  the executable  of  an application  :
'MyApp.app/MyApp',  let's  name  it 'MyApp.app/executable'.   That  is
replacing  f(x)/g(x) with  f(x)/constant is  simplifying. 



-- 
__Pascal Bourguignon__    PGP Key ID:      0xEF5E9966                     (o_
mailto:pjb@imaginet.fr    PGP fingerprint: 00 F5 7B DB CA 51 8A AD 04 5B  //\
http://informatimago.free.fr/index         6C DE 32 60 16 8E EF 5E 99 66  V_/

() Join the ASCII ribbon campaign against html email and Microsoft attachments.
/\ Software patents are endangering the computer industry all around the world.
   Join the LPF:     http://lpf.ai.mit.edu/      http://petition.eurolinux.org/