Re: Introduction, and Proposed GSFH.

[Tim Harrison]

Nicola Pero wrote:

> > http://www.linuxstep.org/documentation/GNUstepFH.html
>
> Thanks - I immediately applied what I could do without any harm - I
> renamed 'Apps' to 'Applications'.
>
> For the rest, your layout proposal is quite clean, with only Applications,
> Tools and Library (containing everything else) in the top-level dir - but
> the problem is that it would involve moving everything from
> Libraries/Resources, and Headers and Makefiles, into Library/ (this is
> actually the main change) and since I know that particular issue causes
> terrible flamewars (it caused many in the past), and that there is
> absolutely no agreement on Library vs Libraries etc, I just prefer to
> ignore the matter and leave everything as it is :-)


I know this would probably cause another war, but I'd like to see 
GNUstep move toward the use of frameworks for the system.  That way, 
Libraries is no longer needed.

Not to be pushy on the subject, but what is the reasoning behind the 
choice not to move -base, -gui, etc to frameworks instead of libraries?


> Perhaps we could introduce some flexibility here, allowing users to choose
> the layout they prefer - the problem is in that way each user will have
> his own layout, and while gnustep-make can support that easily, it might
> complicate a lot the life of applications looking for resources on the
> filesystem.  It might also be just more confusing for users themselves,
> because when they install, say, a new distribution, they will find a
> different layout - which is confusing.


I can understand that.  Putting a user on a SuSE box, and then moving 
them to a Red Hat box can be an interesting experience.  However, I 
would think that one of the goals of GNUstep would be to abstract the 
inner workings of the development environment from the normal user, so 
they don't have to understand it to use it (not to develop with it, but 
just to run, say, GNUMail.app, or EasyDiff.app).

My suggestion is this.  Instead of allowing complete customization for 
the user, how about presenting them with two options:

--osx-layout

or

--standard

Standard would, of course, be the default, and wouldn't need to be 
specified (I list it simply to demonstrate the other option).

If you specified the --osx-layout (or whichever name it would have), 
most of the directories could have associated environment variables, or 
an domain entry in defaults, allowing apps to locate them.


> Btw, you seem to completely ignore the existence of libraries - while on
> gnustep we tend to prefer libraries to frameworks.  Not that there is much
> of a difference between the two, since we're working on support for
> bundling any sort of resources with a library (you can already see an
> experiment of that in place with gnustep-gui, which is installing his own
> localization files and reading them).  It might be my opinion that
> gnustep-base is no special in that respect, I suppose most of gnustep-base
> resources might be moved into Libraries/Resources/gnustep-base/ - but
> that's still a vague idea.


If it's one of GNUstep's goals to aim more toward OS X 
compliance/compatibility, why not move everything to frameworks?  It 
would make life a bit easier for porting, would it not?  If they two 
systems (Cocoa and GNUstep) are laid out similarly, it becomes easier 
for a Cocoa developer to immediately jump into GNUstep development, and 
vice versa.

Of course, I'm a relative newcomer to GNUstep, and don't know why 
certain decisions were/are made.  But, maybe that's a good thing.  I 
don't want to start a fight, but there are some things that I think 
could stand to be reviewed.


> Anyway - resources for a specific library (will) go into
>
> xxx/Libraries/Resources/gnustep-gui/


And with a framework, you wouldn't need the Resources directory at all. 
 Everything would be self contained in the framework.

I personally think that if you're going to use bundles (application 
bundles, dynamically loadable bundles), and developers are making their 
own apps that have frameworks, application bundles, and dynamically 
loadable bundles, then why not go all the way, and make the entire 
development environment cohesive, by moving the libs into frameworks. 
That way, everything is designed the same way.

Of course, I could be completely ignorant, or just blatantly wrong. :) 
But, I have to say my piece, and it seems that everyone is rather 
receptive to controversial ideas lately. :)



--

Tim Harrison
harrison@timharrison.com
http://www.linuxstep.org/