[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Introduction, and Proposed GSFH.

From: Tim Harrison
Subject: Re: Introduction, and Proposed GSFH.
Date: Thu, 28 Feb 2002 11:58:53 -0500
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6) Gecko/20011120

Nicola Pero wrote:


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:




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


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]