Difference between revisions of "Developer FAQ"
(stub) |
Stefanbidi (talk | contribs) |
||
| Line 3: | Line 3: | ||
= GNUstep Frequently Asked Questions with Answers = | = GNUstep Frequently Asked Questions with Answers = | ||
| − | + | Last updated September 7, 2006. Please send corrections to gnustep-maintainer@gnu.org. Also look at the user FAQ for more user oriented questions. | |
== Compatibility == | == Compatibility == | ||
=== Is it easy to port OPENSTEP programs to GNUstep? === | === Is it easy to port OPENSTEP programs to GNUstep? === | ||
| + | It is probably easy for simple programs. There are some portability tools to make this easier, or rewrite the Makefiles yourself. You will also have to translate the NIB files (if there are any) to GNUstep model files using the nib2gmodel program (from ftp://ftp.gnustep.org/pub/gnustep/dev-apps). | ||
| + | |||
=== How about porting between Cocoa and GNUstep? === | === How about porting between Cocoa and GNUstep? === | ||
| + | t's easier from GNUstep to Cocoa than Cocoa to GNUstep. Cocoa is constantly changing, much faster than GNUstep could hope to keep up. They have added extensions and new classes that aren't available in GNUstep yet. Plus there are some other issues. If you start with Cocoa: | ||
| + | * Use #ifndef GNUSTEP for Apple only code. | ||
| + | * Do not use CoreFoundation | ||
| + | * Do not use Objective-C++ (except with gcc 4.1 or later) | ||
| + | * Do not use Quicktime or other proprietary extension | ||
| + | * You need to convert .nib files (see next question see section 1.1.3 Tools for porting) | ||
| + | See also http://mediawiki.gnustep.org/index.php/Writing_portable_code for more information. | ||
| + | |||
=== Tools for porting === | === Tools for porting === | ||
| + | While the programming interface should be almost transparent between systems (expect for the unimplemented parts, of course), there are a variety of other files and tools that are necessary for porting programs. | ||
| + | |||
| + | `ni2gmodel' | ||
| + | This program coverts nib files from any system, such as Cocoa or OPENSTEP to a gmodel format file. Gmodel can be read directly by GNUstep or you can convert this to a more GNUstep-native gorm format (using the Gorm interface modeller). | ||
| + | |||
| + | `Renaissance' | ||
| + | GNUstep Renaissance allows you to describe your user interfaces (that is, the windows in your application, and the buttons, boxes, textfields, etc in the windows) in simple and intuitive XML files, using an open, standard format describing the logic of the interface. It has a number of advantages over the proprietary nib format: portability, open standard, easy localization, themeability, and intelligent autolayout. | ||
| + | |||
| + | `Gorm' | ||
| + | The equivalent of the Interface Builder in GNUstep. As of version 1.1.0 Gorm allows reading and writing of Mac OS 10.2 or later Cocoa NIB files. Please see http://lists.gnu.org/archive/html/discuss-gnustep/2006-09/msg00008.html. | ||
| + | |||
| + | `OpenStep2GNUConverter and nfmake' | ||
| + | Two programs that allow you to convert PB files to GNUstep makefiles or compile a program on GNUstep directly from PB files. They probably work only for OPENSTEP systems and are a little out-of-date. | ||
| + | |||
| + | `StepTalk' | ||
| + | A portable scripting environment that lets your do scripting in almost any language you like. | ||
| + | |||
=== Can I transfer archived data from GNUstep to Cocoa? === | === Can I transfer archived data from GNUstep to Cocoa? === | ||
| + | Apple's archiving format is proprietary and not documented, so this poses a problem for anyone wanting to implement compatibility with it. However, even if we reverse engineered the format, there are enough differences between the class and ivar layouts to make this sort of compatibility difficult. Not to mention the fact that we would constantly have to keep up with the changes Apple made. Also Apple's archiving format, as far as we know, would not be compatible between different machines because of endiness issues, although GNUstep doesn't have this problem. | ||
| + | |||
| + | The new keyed archiving using XML file formats is much more portable, and GNUstep is trying to maintain compatibility with Apple with this type of archiving. | ||
| + | |||
=== Does distributed objects work between GNUstep and Cocoa? === | === Does distributed objects work between GNUstep and Cocoa? === | ||
| + | See the answer to the previous question (on archive compatibility) for why this won't work either. | ||
| + | |||
=== Is there an Interface Builder for GNUstep? === | === Is there an Interface Builder for GNUstep? === | ||
| + | There is an Interface Builder for GNUstep called Gorm. A lot of work has been put into it and it works very well. You can download it from the ftp site or via http. The Project Manager ProjectCenter is also available. | ||
| + | |||
=== Can I use my original NIB files? === | === Can I use my original NIB files? === | ||
| + | No - NeXT/Apple never documented their nib format, so GNUstep supports both the 'gmodel' format (which stores information as text (property-lists) and can therefore be edited 'by hand') and binary archive format (which can be edited by Gorm). There IS a conversion tool called nib2gmodel that can be compiled under OPENSTEP to convert nib files to GNUstep gmodel files. | ||
| + | |||
| + | Newer nib files use XML format keyed archiving and may possibly be transportable, although differences in class and ivar layout may still make this difficult. | ||
| + | |||
=== Can one use the hybrid "Objective-C++" ? === | === Can one use the hybrid "Objective-C++" ? === | ||
| + | Yes. As of release 4.1 the GNU C Compiler (GCC) supports "Objective-C++". | ||
| + | |||
=== Is there a plan to support the Java/YellowBox Bindings? === | === Is there a plan to support the Java/YellowBox Bindings? === | ||
| + | Yes. The GNustep Java library/bridge called JIGS is available now. JIGS is a free (LGPL) Java Interface for GNUstep; it can automatically wrap Objective-C libraries based on GNUstep, making them accessible directly to the Java programmer as if they were Java libraries. As a side effect, it is also possible to use the whole engine in the reverse way: JIGS provides a high level API to allow Objective-C programmers to start java virtual machines inside GNUstep Objective-C code and access java objects in the java virtual machine transparently, as if they were objective-C objects. | ||
| + | |||
=== What if I compile GNUstep under OPENSTEP/MacOS X? === | === What if I compile GNUstep under OPENSTEP/MacOS X? === | ||
| + | GNUstep uses the X-windows display postscript extension. The interface to that is not the same as the interface to the OPENSTEP/MacOS-X windows server. While someone could write a backend library to provide the interface, nobody has bothered to date. | ||
| + | |||
| + | You can, however, use a GNUstep program with an X11 server running on MacOSX. | ||
| + | |||
=== Is the Objective C API for GTK related? === | === Is the Objective C API for GTK related? === | ||
| + | No. GNUstep applications provide their GUI via the OpenStep API, which provides fully object-oriented access to GUI manipulation. | ||
| + | |||
| + | The object-oriented nature of the libraries and language make it much easier for new users to create their own subclasses rather than simply using the supplied widgets as in other frameworks. | ||
| + | |||
=== How about implementing parts of the Application Kit with GTK? === | === How about implementing parts of the Application Kit with GTK? === | ||
| + | Yes and No - The GNUstep architecture provides a single, platform-independent, API for handling all aspects of GUI interaction (implemented in the gstep-gui library), with a backend architecture that permits you to have different display models (display postscript, X-windows, win32, berlin ...) while letting you use the same code for printing as for displaying. Use of GTK in the frontend gui library would remove some of those advantages without adding any. | ||
| + | |||
| + | That being said, a backend library could be implemented using gtk if anyone wanted to do so. Since the frontend library handles most of the work involved in implementing the OpenStep API, the backend is a relatively thin layer and the advantages of GTK over direct xlib or win32 calls is likely to be minimal. If/when GTK is ported to more systems, a backend written using it could be a valuable asset - volunteers are, as always, welcome. | ||
| + | |||
Revision as of 22:15, 7 September 2006
| This article or section is a stub (i.e., in need of additional material). You can help us by expanding it |
|---|
GNUstep Frequently Asked Questions with Answers
Last updated September 7, 2006. Please send corrections to gnustep-maintainer@gnu.org. Also look at the user FAQ for more user oriented questions.
Compatibility
Is it easy to port OPENSTEP programs to GNUstep?
It is probably easy for simple programs. There are some portability tools to make this easier, or rewrite the Makefiles yourself. You will also have to translate the NIB files (if there are any) to GNUstep model files using the nib2gmodel program (from ftp://ftp.gnustep.org/pub/gnustep/dev-apps).
How about porting between Cocoa and GNUstep?
t's easier from GNUstep to Cocoa than Cocoa to GNUstep. Cocoa is constantly changing, much faster than GNUstep could hope to keep up. They have added extensions and new classes that aren't available in GNUstep yet. Plus there are some other issues. If you start with Cocoa:
- Use #ifndef GNUSTEP for Apple only code.
- Do not use CoreFoundation
- Do not use Objective-C++ (except with gcc 4.1 or later)
- Do not use Quicktime or other proprietary extension
- You need to convert .nib files (see next question see section 1.1.3 Tools for porting)
See also http://mediawiki.gnustep.org/index.php/Writing_portable_code for more information.
Tools for porting
While the programming interface should be almost transparent between systems (expect for the unimplemented parts, of course), there are a variety of other files and tools that are necessary for porting programs.
`ni2gmodel' This program coverts nib files from any system, such as Cocoa or OPENSTEP to a gmodel format file. Gmodel can be read directly by GNUstep or you can convert this to a more GNUstep-native gorm format (using the Gorm interface modeller).
`Renaissance' GNUstep Renaissance allows you to describe your user interfaces (that is, the windows in your application, and the buttons, boxes, textfields, etc in the windows) in simple and intuitive XML files, using an open, standard format describing the logic of the interface. It has a number of advantages over the proprietary nib format: portability, open standard, easy localization, themeability, and intelligent autolayout.
`Gorm' The equivalent of the Interface Builder in GNUstep. As of version 1.1.0 Gorm allows reading and writing of Mac OS 10.2 or later Cocoa NIB files. Please see http://lists.gnu.org/archive/html/discuss-gnustep/2006-09/msg00008.html.
`OpenStep2GNUConverter and nfmake' Two programs that allow you to convert PB files to GNUstep makefiles or compile a program on GNUstep directly from PB files. They probably work only for OPENSTEP systems and are a little out-of-date.
`StepTalk' A portable scripting environment that lets your do scripting in almost any language you like.
Can I transfer archived data from GNUstep to Cocoa?
Apple's archiving format is proprietary and not documented, so this poses a problem for anyone wanting to implement compatibility with it. However, even if we reverse engineered the format, there are enough differences between the class and ivar layouts to make this sort of compatibility difficult. Not to mention the fact that we would constantly have to keep up with the changes Apple made. Also Apple's archiving format, as far as we know, would not be compatible between different machines because of endiness issues, although GNUstep doesn't have this problem.
The new keyed archiving using XML file formats is much more portable, and GNUstep is trying to maintain compatibility with Apple with this type of archiving.
Does distributed objects work between GNUstep and Cocoa?
See the answer to the previous question (on archive compatibility) for why this won't work either.
Is there an Interface Builder for GNUstep?
There is an Interface Builder for GNUstep called Gorm. A lot of work has been put into it and it works very well. You can download it from the ftp site or via http. The Project Manager ProjectCenter is also available.
Can I use my original NIB files?
No - NeXT/Apple never documented their nib format, so GNUstep supports both the 'gmodel' format (which stores information as text (property-lists) and can therefore be edited 'by hand') and binary archive format (which can be edited by Gorm). There IS a conversion tool called nib2gmodel that can be compiled under OPENSTEP to convert nib files to GNUstep gmodel files.
Newer nib files use XML format keyed archiving and may possibly be transportable, although differences in class and ivar layout may still make this difficult.
Can one use the hybrid "Objective-C++" ?
Yes. As of release 4.1 the GNU C Compiler (GCC) supports "Objective-C++".
Is there a plan to support the Java/YellowBox Bindings?
Yes. The GNustep Java library/bridge called JIGS is available now. JIGS is a free (LGPL) Java Interface for GNUstep; it can automatically wrap Objective-C libraries based on GNUstep, making them accessible directly to the Java programmer as if they were Java libraries. As a side effect, it is also possible to use the whole engine in the reverse way: JIGS provides a high level API to allow Objective-C programmers to start java virtual machines inside GNUstep Objective-C code and access java objects in the java virtual machine transparently, as if they were objective-C objects.
What if I compile GNUstep under OPENSTEP/MacOS X?
GNUstep uses the X-windows display postscript extension. The interface to that is not the same as the interface to the OPENSTEP/MacOS-X windows server. While someone could write a backend library to provide the interface, nobody has bothered to date.
You can, however, use a GNUstep program with an X11 server running on MacOSX.
No. GNUstep applications provide their GUI via the OpenStep API, which provides fully object-oriented access to GUI manipulation.
The object-oriented nature of the libraries and language make it much easier for new users to create their own subclasses rather than simply using the supplied widgets as in other frameworks.
How about implementing parts of the Application Kit with GTK?
Yes and No - The GNUstep architecture provides a single, platform-independent, API for handling all aspects of GUI interaction (implemented in the gstep-gui library), with a backend architecture that permits you to have different display models (display postscript, X-windows, win32, berlin ...) while letting you use the same code for printing as for displaying. Use of GTK in the frontend gui library would remove some of those advantages without adding any.
That being said, a backend library could be implemented using gtk if anyone wanted to do so. Since the frontend library handles most of the work involved in implementing the OpenStep API, the backend is a relatively thin layer and the advantages of GTK over direct xlib or win32 calls is likely to be minimal. If/when GTK is ported to more systems, a backend written using it could be a valuable asset - volunteers are, as always, welcome.