[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:
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/
- Re: Introduction, and Proposed GSFH., (continued)
- Re: Introduction, and Proposed GSFH., Stefan Urbanek, 2002/02/28
- Re: Introduction, and Proposed GSFH., Nicola Pero, 2002/02/28
- Re: Introduction, and Proposed GSFH., Jeff Teunissen, 2002/02/28
- Re: Introduction, and Proposed GSFH., Nicola Pero, 2002/02/28
- Re: Introduction, and Proposed GSFH., Tim Harrison, 2002/02/28
- Re: Introduction, and Proposed GSFH., Jeff Teunissen, 2002/02/28
- Re: Introduction, and Proposed GSFH., Tim Harrison, 2002/02/28
- Re: Introduction, and Proposed GSFH., Tim Harrison, 2002/02/28
Re: Introduction, and Proposed GSFH.,
Tim Harrison <=
Re: Introduction, and Proposed GSFH., Nicola Pero, 2002/02/28
Re: Introduction, and Proposed GSFH., Tim Harrison, 2002/02/28
Re: Introduction, and Proposed GSFH., Adam Fedor, 2002/02/28
Re: Introduction, and Proposed GSFH., Marcus Müller, 2002/02/28
Message not available
Re: Introduction, and Proposed GSFH., Erik Dalén, 2002/02/28