gnustep/tools-make
0
0
Fork 0
mirror of https://github.com/gnustep/tools-make.git synced 2025-04-23 22:33:28 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Minor corrections to the user FAQ.

Browse source 
git-svn-id: svn+ssh://svn.gna.org/svn/gnustep/tools/make/trunk@21251 72102866-910b-0410-8b05-ffd578937521
This commit is contained in:
David Lazaro Saz 2005-05-23 18:58:53 +00:00
parent f7da0d90ea
commit 0b8ba064d0
2 changed files with 69 additions and 64 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

5
ChangeLog
View file

@ -1,3 +1,8 @@
2005-05-23 David Lazaro Saz <dlazaro@acm.org>
* Documentation/userfaq.texi: Updated style, trademark usage and some
spelling mistakes.
2005-05-21 Adam Fedor <fedor@gnu.org>
* Update FSF Address.

128
Documentation/userfaq.texi
View file

@ -35,19 +35,19 @@ at the (developer) FAQ for more developer oriented questions.
@subsection What is GNUstep?
GNUstep is the Free Software Foundation's effort to implement NeXT
Software Inc.'s (now Apple Inc.) OpenStep Standard. The project is not
finished, so some parts are not as polished as they could be.
Software, Inc.'s (now Apple Computer, Inc.) OpenStep Standard. The project is
not finished, so some parts are not as polished as they could be.
@node What is the OpenStep standard?, What platforms does GNUstep run on?, What is GNUstep?, GNUstep General Information
@subsection What is the OpenStep standard?
OpenStep is an Application Programming Interface (API) for creating
applications using the Objective C language. It was published by NeXT
Computer Inc. in 1994.
applications using the Objective-C language. It was published by NeXT
Computer, Inc. in 1994.
OpenStep consists of three parts: the @samp{FoundationKit}, a library of
non-graphical objects; the @samp{AppKit}, a library of objects useful in
creating graphical applications; and @samp{Display Postscript}, an
OpenStep consists of three parts: the @samp{Foundation Kit}, a library of
non-graphical objects; the @samp{Application Kit}, a library of objects useful
in creating graphical applications; and the @samp{Display PostScript System}, an
interface for drawing to the screen using the PostScript graphics
language.
@ -60,25 +60,25 @@ You can obtain a copy of the OpenStep standard from the GNUstep web site
See the list of supported platforms at
@url{http://www.gnustep.org/information/machines_toc.html} for
information on what machines GNUstep builds on and what the status of
the ports is. Probably a few days porting to any other Unix system where
the ports is. Probably a few days porting to any other UNIX system where
current gcc compilers and gdb debugger work.
@node Does GNUstep run on Windows?, What is GNUstep's position towards KDE and the GNOME project?, What platforms does GNUstep run on?, GNUstep General Information
@subsection Does GNUstep run on Windows?
The primary targets for GNUstep are free 'Unix' platforms such
as GNU/Linux.
The primary targets for GNUstep are free UNIX system-based platforms such
as GNU/Linux and FreeBSD.
That being said, the base library should run on Windows-NT,98,2000 with the
Cygwin unix emulation library from Cygnus
(http://sourceware.cygnus.com/cygwin/) or the MinGW libraries. At
present there are a few problems with networking (Distributed Objects)
support, but the library is believed to work.
That being said, the base library should run on Windows NT, 98, 2000, and XP
with the Cygwin UNIX system-emulation environment from Cygnus
(@url{http://www.cygwin.com/}), or the MinGW environment
(@url{http://www.mingw.org}). At present there are a few problems with
networking (distributed objects) support, but the library is believed to work.
The gui library uses the win32 backend library to work under
The GUI library uses the win32 backend library to work under
Windows. The backend library is a thin layer that converts the
GNUstep methods to handle drawing of GUI elements to calls to the
win32 API. This project is in beta.
Windows API. This project is currently in beta.
The application-wrapper used for GNUstep already allows for multiple
binaries to be stored for different systems, so you should be able
@ -90,14 +90,14 @@ to write once, deploy anywhere.
You can use GNUstep with GNOME and/or KDE. GNUstep displays
on top of X11. You can still do programming in C (since Objective-C
is just a super-set of C), and when (if?) GCC gets around to it,
you'll be able to mix C++ and Objective-C code in the SAME file.
is just a super-set of C), and when GCC gets around to it,
you'll be able to mix C++ and Objective-C code in the same file.
GNUstep, is much more than a window manager or desktop environment.
It frees you to develop cross-platform applications without the
work of developing an OS independent framework from scratch. It
gives you lots of basic functionality, from Font Panels to Unicode
strings to Distributed Objects.
gives you lots of basic functionality, from font panels to Unicode
strings to distributed objects.
@node How can I get GNUstep?, How do you run GNUstep?, What is GNUstep's position towards KDE and the GNOME project?, GNUstep General Information
@subsection How can I get GNUstep?
@ -119,14 +119,14 @@ some sort of program or window manager.
It isn't.
GNUstep is a whole load of things - primarily a set of libraries
GNUstep is a whole load of things --- primarily a set of libraries
for developing software.
At present, it's those libraries, plus various command-line based
support tools and service providing daemons, plus various GUI
development tools, a GUI desktop/workspace application, etc.
At no stage will you ever 'run' GNUstep - you will run applications
At no stage will you ever 'run' GNUstep --- you will run applications
and tools and will make use of it's services. At some point
you may well find packages distributed as 'GNUstep' systems in the
way that you get 'GNU/Linux' systems packaged today. Look at
@ -137,7 +137,7 @@ GNUstep and look at the example applications in the gnustep-examples
package. Build 'Finger' or 'Ink' and start it with 'openapp Finger.app'
or 'openapp Ink.app'
To look best - use WindowMaker (the currently preferred GNUstep
To look best, use WindowMaker (the currently preferred GNUstep
window manager) as your window manager.
@node Is there a web site?, When is GNUstep intended to be available?, How do you run GNUstep?, GNUstep General Information
@ -156,10 +156,10 @@ snapshots.
@subsection What is usable?
@itemize @bullet
@item gnustep-make does pretty much what the makefiles in NeXTstep do.
@item gnustep-make does pretty much what the makefiles in NEXTSTEP do.
@item gnustep-base (Foundation) works well and is used in production evironments.
@item gnustep-gdl2 works well and is used in production evironments.
@item gnustep-gui (AppKit) has a lot working but there is still stuff missing.
@item gnustep-gui (Application Kit) has a lot working but there is still stuff missing.
@end itemize
What does this mean for users? Many applications will run quite well.
@ -189,8 +189,8 @@ GNUstep web site.
@subsection Are there any precompiled packages available?
Check @url{http://www.gnustep.org/resources/sources.html} for links to
RPMS, Debain packages, and BSD ports. Also Windows installers, MacOSX biniaries
and others.
RPMs, Debian packages, and BSD ports. There's also Windows installers, Mac OS X
binaries and others.
@node What are these type and size warnings?, What are these import warnings?, Are there any precompiled packages available?, Compiling and Installing
@subsection What are these type and size warnings?
@ -208,7 +208,7 @@ fixed in GCC version 3.1.
@node What are these import warnings?, , What are these type and size warnings?, Compiling and Installing
@subsection What are these import warnings?
Do you get these obnoxious warning whenever you compile an application, tool,
Do you get this obnoxious warning whenever you compile an application, tool,
or Objective-C program:
@example
@ -228,53 +228,53 @@ you are using an early compiler, you can supress these warnings by adding
@section Compatibility and Layout
@menu
* Can I run NeXT OPENSTEP or MacOSX programs on GNUstep?::
* Is GNUstep following Changes to OpenStep and MacOSX?::
* Do we have to have the NeXTstep look and feel?::
* Can I run NeXT OPENSTEP or Mac OS X programs on GNUstep?::
* Is GNUstep following changes to OpenStep and Mac OS X?::
* Do we have to have the NEXTSTEP look and feel?::
* What's up with the directory structure?::
* Why not use Frameworks?::
* Why not use framework bundles?::
@end menu
@node Can I run NeXT OPENSTEP or MacOSX programs on GNUstep?, Is GNUstep following Changes to OpenStep and MacOSX?, Compatibility and Layout, Compatibility and Layout
@subsection Can I run NeXT OPENSTEP or MacOSX programs on GNUstep?
@node Can I run NeXT OPENSTEP or Mac OS X programs on GNUstep?, Is GNUstep following changes to OpenStep and Mac OS X?, Compatibility and Layout, Compatibility and Layout
@subsection Can I run NeXT OPENSTEP or Mac OS X programs on GNUstep?
You can't run these programs on GNUstep, but if you have the source
code for the programs, you should be able to port them to GNUstep and
compile them. Whether or not you will be able to run them depends on how
complete GNUstep is at the time.
@node Is GNUstep following Changes to OpenStep and MacOSX?, Do we have to have the NeXTstep look and feel?, Can I run NeXT OPENSTEP or MacOSX programs on GNUstep?, Compatibility and Layout
@subsection Is GNUstep following Changes to OpenStep and MacOSX?
@node Is GNUstep following changes to OpenStep and Mac OS X?, Do we have to have the NEXTSTEP look and feel?, Can I run NeXT OPENSTEP or Mac OS X programs on GNUstep?, Compatibility and Layout
@subsection Is GNUstep following changes to OpenStep and Mac OS X?
Yes, gnustep-base already contains the documented changes in the
Foundation library. GNUstep aims to be compatible with both the
OpenStep specification and with MacOS-X. It should be easy to write
OpenStep specification and with Mac OS X. It should be easy to write
an application that compiles cleanly under both GNUstep and Cocoa.
@node Do we have to have the NeXTstep look and feel?, What's up with the directory structure?, Is GNUstep following Changes to OpenStep and MacOSX?, Compatibility and Layout
@subsection Do we have to have the NeXTstep look and feel?
@node Do we have to have the NEXTSTEP look and feel?, What's up with the directory structure?, Is GNUstep following changes to OpenStep and Mac OS X?, Compatibility and Layout
@subsection Do we have to have the NEXTSTEP look and feel?
GNUstep is aiming for something like the NeXTstep-3.3 look and feel.
GNUstep is aiming for something like the NEXTSTEP 3.3 look and feel.
Although we don't want to force anyone into this, a lot of the power and
ease of use comes from this feel. The look of GNUstep is something
different - buttons and other widgets can look different but still act
different --- buttons and other widgets can look different but still act
the same way. We hope to implement themes which will allow
this. Actually we're hoping someone will volunteer to do it.
@node What's up with the directory structure?, Why not use Frameworks?, Do we have to have the NeXTstep look and feel?, Compatibility and Layout
@node What's up with the directory structure?, Why not use framework bundles?, Do we have to have the NEXTSTEP look and feel?, Compatibility and Layout
@subsection What's up with the directory structure?
First of all, GNUstep uses a slightly different directory structure than
NeXT or MacOSX. Part of this is historical, part is because we can't do
things the same way (see @pxref{Why not use Frameworks?}). Although currently
the structure is very similar to the it is done in MacOSX.
NEXTSTEP or Mac OS X. Part of this is historical, part is because we can't do
things the same way (see @pxref{Why not use framework bundles?}). Although
currently the structure is very similar to the one used in Mac OS X.
@node Why not use Frameworks?, , What's up with the directory structure?, Compatibility and Layout
@subsection Why not use Frameworks?
@node Why not use framework bundles?, , What's up with the directory structure?, Compatibility and Layout
@subsection Why not use framework bundles?
Frameworks are much more difficult to port and to use, and are very
unnatural on a unix system - extremely unnatural on Windows. In a
framework, the shared dynamic library is inside a framework wrapper
Framework bundles are much more difficult to port and to use, and are very
unnatural on a UNIX system; extremely unnatural on Windows. In a
framework bundle, the shared dynamic library is inside a framework wrapper
directory. Because of this, the dynamic linker can't find it.
We have frameworks, so how do we work around that? Well, we build dynamic
@ -289,29 +289,29 @@ path, but that is simply a shared library then! Absolutely @emph{no}
difference. You put the dynamic library in a system directory in the
dynamic linker path, and associate with that library a resource directory.
I think OpenStep for Windows did that, and still called them frameworks.
Oh well we can do the same then, and call our libraries frameworks.
OpenStep for Windows did that, and still called them frameworks.
So we can do the same, and call our libraries frameworks.
In a shared library, the shared dynamic library is in a directory which is
in the path to the dynamic linker. the dynamic linker can find it very
easily. this is how all shared and static libraries work on Unix systems,
on Windows systems and possibly on most system at all.
easily. this is how all shared and static libraries work on UNIX systems,
Windows systems and possibly most system at all.
Moreover, the OpenStep API requires us to provide some stuff for
frameworks, like creating and registering automatically a framework
object each time a framework is used (linked at runtime, or linked into
the app), and attaching to it the list of classes inside the framework -
which are not particularly trivial to implement - they depend on playing
with the linker and the object file format - and might produce troubles
which are not particularly trivial to implement --- they depend on playing
with the linker and the object file format --- and might produce troubles
when porting. And we never use these facilities.
For Apple MacOSX sure it's easier. They can modify
For Apple Mac OS X sure it's easier. They can modify
the system linker, compiler, the system dynamical linker. They
always know on which platform they are working (their own), etc. They can
modify the system to support frameworks natively. Easy that way.
But GNUstep is meant to run on many different platforms, platforms which
we don't control (Windows, Sun Solaris, Darwin, GNU/Linux, Unix
we don't control (Windows, Sun Solaris, Darwin, GNU/Linux, UNIX system
variants) and which have different linkers and do not support frameworks
natively. On some systems it's difficult to just load a bundle or
compile a shared library!
@ -319,21 +319,21 @@ compile a shared library!
So building the core libraries as 'libraries' means that it's much
easier to port them, and it's much more difficult to break them.
Sure, frameworks have a bundle of resources associated with it - but we
Sure, frameworks have a bundle of resources associated with it --- but we
can very easily associate a bundle of resource with a shared library, no
reason why not. We are doing it.
So please note that GNUstep libraries are meant to be much similar to
MacOS X frameworks. They are composed of a shared library and
Mac OS X frameworks. They are composed of a shared library and
associated with a bundle of resources. There is a difference in
terminology, in where the resources are installed, and possibly a slight
difference in the NSBundle API to get to the resource bundle (anyway,
it's a one line difference between MacOSX and GNUstep, so it looks like
it's a one line difference between Mac OS X and GNUstep, so it looks like
very easy to #ifdef).
In other words, GNUstep libraries are meant to basically do the same as
frameworks do on MacOSX, but to be portable to strange platforms (such as
Windows).
frameworks do on Mac OS X, but to be portable to very different platforms (such
as Windows).
@c ****************************************************************