GNUstepWiki - User contributions [en]

Adding a new Natural Language to GNUstep

2009-07-13T11:41:45Z

Comrade: Creation

These instructions are loosely based on a mail from Fred Kiefer.

== General approach ==

To have a localized application, not only will the application have to be translated, but also GNUstep-base and GNUstep-gui if they've not already been done.

Check to see if base and gui support your language. Language support bundles are present in the Resources directory in the source distributions with an extension .lproj.

'''Note:''' By convention, these localization bundles are named in English.

If your language is not supported yet, copy the English.lproj bundle and name it to the language you wish to support.

At a minimum, you will need to translate the bundle's Localizable.strings file and the package's (or subproject's) GNUmakefile to include the new language name in the xxx_LANGUAGES variable. If the resource (such as a GUI application, or GNUstep-gui) uses .gorm files for GUI elements such as menus and panels, these will also need to be translated using Gorm.

== Localizable.strings ==

Localizable.strings is a file containing strings in a base language (often English) which correspond to strings embedded in the source code and the translated string.

You will need to put strings that correspond to the language you are targetting in the right hand column. Missing quotation marks, equal signs or terminating semicolons will cause problems.

'''Note:''' Applications need to use the _() syntax in source code to support automatic use of Localizable.strings.

== GNUmakefile ==

Add the name of the language to the project's ''projectname''_LANGUAGES variable.

== Gorm files ==

Find all files ending in .gorm that were copied from the orginal language bundle and load them one by one. Change all the text that is displayed to the user in menus, panels, windows, buttons and so on, and if necessary, also change the layout (average string length and height tend to differ between even closely-related languages, right-to-left languages may conventionally place default buttons in different locations on panels, as examples).

== See also ==

[[http://gnustep.made-it.com/GSPT/xml/Tutorial_en.html#AEN1516 Dennis Leeuw's tutorial]]

Developer Guides

2009-07-13T11:01:07Z

Comrade: Translating GNUstep

This page is intended as a collection of guides for developers.

== Introductory Articles on GNUstep Development ==

{{Stub}}

=== [[GNUstep Suite|Introduction to GNUstep Libraries and Tools]] ===

A general overview of GNUstep.

=== [http://www.gnustep.org/resources/documentation/Developer/Base/ProgrammingManual/manual_toc.html Introduction to GNUstep (Foundation) Programming] ===

The aim of this manual is to introduce you to the Objective-C language and the GNUstep development environment, in particular the Base library. The manual is organised to give you a tutorial introduction to the language and APIs, by using examples whenever possible, rather than providing a lengthy abstract description.

While Objective-C is not a difficult language to learn or use, some of the terms may be unfamiliar, especially to those that have not programmed using an object-oriented programming language before. Whenever possible, concepts will be explained in simple terms rather than in more advanced programming terms, and comparisons to other languages will be used to aid in illustration.

=== [http://www.roard.com/docs/lmf2.article/en.html (GUI) Programming under GNUstep] ===

This guide will introduce you to the [[AppKit]] classes and how to use [[Gorm]] to create graphical interfaces.

=== [[Writing Makefiles]] ===

The Makefile package is a system of make commands that is designed to encapsulate all the complex details of building and installing various types of projects from libraries to applications to documentation. This frees the developer to focus on the details of their particular project. Only a fairly simple main makefile need to be written which specifies the type of project and files involved in the project.

=== [ftp://ftp.gnustep.org/pub/gnustep/core/gnustep-examples-1.1.0.tar.gz Sample GNUstep Programs] ===

This isn't really an article but rather a collection of small "codified guides" for the pragmatic programmer who wants to explore GNUstep by looking at and messing around with example code. This is best done while reading about basic concepts of OpenStep or Cocoa with the API documentation ([[Foundation]], [[AppKit]]) open in the background.

== General ==

=== [[Writing portable code|Coding for Portability]] ===

Writing code that will compile and then run on different platforms can be surprisingly easy. This guide describes
some straight-forward steps to take to make your program easy to port to new platforms.

=== [[Property Lists|Using Property Lists]] ===

A regular issue that programmers face is storing structured configuration information, and reading it back. GNUstep has a standard mechanism that can be used for this task, amongst others: Property Lists.

=== [[Deployment on Windows]] ===

This article will tell you how to deploy GNUstep applications on Windows.

=== [[Adding a new Natural Language to GNUstep|Translating GNUstep]] ===

Translation of GNUstep applications involves a number of steps, including translation of GNUstep Base and GNUstep GUI.

== Graphical Applications ==

=== Simple Graphical Application Design ===
GNUstep includes several sophisticated development tools. GNUstep GUI interfaces are designed using [[Gorm]] (Graphical Object Relationship Modeler), an elegant application developed by Gregory Casamento. (See his [http://heronsperch.blogspot.com/ blog] for the latest news on GORM.) There are two proto-IDEs, [[ProjectCenter]] and [[ProjectManager]].

There are several introductory tutorials for using these development tools. The first [http://www.gnustep.it/pierre-yves/index.html tutorial] by Pierre-Yves Rivaille is a classic demonstrating the process used to create the ubiquitous currency converter application. A second [http://www.nongnu.org/gstutorial/ tutorial] by Yen-Ju Chen is somewhat more in-depth and extensive.

Nicolas Roard created a [http://gnustep.org/experience/DevelopmentDemonstration.html video] demonstrating the process of developing a simple calculator, and another [http://home.gna.org/pmanager/videos.html video] here by Sašo Kiselkov if you feel the need to create another currency converter.

=== [[Document based applications|Document-based Application Design]] ===

One of the most common use-patterns of applications on modern platforms is that of document-based applications --- applications which can have several active user-controlled contexts. Some familar examples might be a word processor where the user may have multiple document windows concurrently, or a web browser which allows a user to have a number of different browser windows open at the same time. This guide provides information and tips on how to code this style of application.

== Web Applications ==

Please have a look at [[Creating A Simple GSWeb Application]] to learn how to create a [[GNUstepWeb|GNUstep Web]] application.

== Other Information ==

=== Developer sites ===

* [http://www.roard.com/docs/ GNUstep HelpCenter]

[[Category:Development]]

EdenMath.app

2009-01-28T16:55:03Z

Comrade: spelling of calculator ;-)

{{stub}}

{{Application|
shortdescription = EdenMath is a scientific calculator originally written for Mac OS X. |

currentversion = [http://rburns.paiges.net/software/edenmath/files/EdenMath_GNUstep-1.1.1.tar.gz 1.1.1] |

releasedate = May 11, 2005 |

license = GPL |

overview = EdenMath is a scientific calculator which does standard arithmetic, probability, and trigonometric functions. |

features = |

maintainer =
* [[User:Rburns | Rob Burns]] -- GNUstep version
* Chad Armstrong -- OSX Version |

relatedlinks =
* [http://rburns.paiges.net/software/edenmath/ GNUstep version]
* [http://www.edenwaith.com/products/edenmath/ OSX version] |

category = [[Category:Science Applications]]
}}

DBModeler.app

2009-01-28T16:51:37Z

Comrade: Add feature list

{{stub}}

{{Application|
shortdescription = DBModeler.app is based loosely on EOModeller.app and is used to create EOModels -- definitions of mappings between the tables, columns and rows of a relational database to objects within a GNUstep program that uses [[GDL2]] (GNUstep's EOF implementation). |
currentversion = Unknown |
releasedate = Unknown |
license = GPL 2.0 |
overview =
[[Image:DBModeler-snapshot.png|frame|Snapshot of DBModeler.app in operation]]
Existing EOModels may be opened and modified, new ones may be created manually, or even "reverse-engineered" from an existing database if DBModeler is able to connect to an existing database.

The resulting EOModels can be used to allow simple database connectivity in GNUstep applications, tools, or within GNUstep Web applications without significant additional coding effort.|
features =
* create entity-relationship models
* view models in diagram form
* reverse-engineer models from existing databases
* drag-and-drop entities and relationships into Gorm for integration into GUI apps
* generate databases and table schemas in supported databases |
maintainer = * [mailto:ratmice@yahoo.com Matt Rice] |
relatedlinks = |
category =
[[Category:Database Applications]]
[[Category:Development Applications]]
}}

GSWeb application deployment

2008-01-19T18:37:35Z

Comrade: libplist -> libproplist

It's recommended to use the new [[Apache2Adaptor]] to serve your dynamic pages using Apache 2.

If using the new Apache2Adaptor, disregard instructions for the older adaptors that use libproplist.

Different platforms use different configuration styles for Apache 2. Ensure you identify how it works on your platform.

=== Ubuntu 7.10 ===
To use a new Apache module, configuration files must be updated in the <tt>/etc/apache2/mods-enabled</tt> directory. The relevant files may already be installed in <tt>/etc/apache2/mods-available</tt> directory, and only require symlinking.

<tt>/etc/apache2/mods-enabled/gsw.load</tt> is used to force the module to be loaded by Apache 2:
<pre>
LoadModule gsw_module /usr/lib/apache2/modules/mod_gsw.so
</pre>

<tt>/etc/apache2/mods-enabled/gsw.conf</tt> is used to configure the adaptor with information about the web applications for which it will provide access:
<pre>
<IfModule gsw_module>
ShowApps on
App Name=SimpleDemo Instance=1 Host=127.0.0.1:9001
</IfModule>
</pre>

----

[[Category:GNUstepWeb]]

Creating A Simple GSWeb Application

2008-01-19T18:34:37Z

Comrade: Updated the component section to give an outline of files needed

== Introduction ==

[[GNUstepWeb]] is a framework for creating web-based applications using Objective-C. This guide aims to provide an overview of what is required in the creation and design of a very simple web application.

It is assumed you are familiar with GNUstep, and have a working GNUstep installation, including the [[GDL2]] and [[GSWeb]] frameworks. Pre-requisites for [[GSWeb application deployment]] should also be in place.

== File Components ==

In building your web application you will need to create a number of files. From scratch, the following should be a rough guide to getting it working. These include the Makefile, some mandatory "plumbing" code in Objective-C, [[GSWComponent]]s to provide the pages and subpage elements of the web application, and run-time resources.

=== The Makefile ===

For a web application, a special makefile is needed: luckily it's very similar to makefiles you may have used for other kinds of project. There is currently no out-of-the-box way to have these files built for you, so you'll have to do it manually.

'''GNUmakefile'''

Initial makefile includes needed to set up the make environment should be:
<pre>
include $(GNUSTEP_MAKEFILES)/common.make
include $(GNUSTEP_MAKEFILES)/Auxiliary/gsweb_wo.make
</pre>

Note that the second include forces GNUstepWeb to use Apple's WebObjects naming conventions. Dropping the _wo in the included filename will enable GSW naming conventions. It is useful to decide which convention you plan to use in the application early on because changing later will involve changing the naming convention of class names in many files in your project.

The key variables used in a web application's makefile are:
;GSWAPP_NAME:used to define the project's name in the makefile, replace the {PROJECTNAME} with the name in the variables listed below
;{PROJECTNAME}_HAS_GSW_COMPONENTS:used to indicate that [[GSWComponent]]s are present in the project. Normally, this is set to <TT>YES</TT>
;{PROJECTNAME}_PRINCIPAL_CLASS:used to identify the main class of the web application
;{PROJECTNAME}_RESOURCE_FILES:used to indicate the list of files that are needed in the runtime bundle
;{PROJECTNAME}_OBJC_FILES:contains the list of Objective-C files needed to compile the web application
;{PROJECTNAME}_COMPONENTS:lists the names of the components that will be used to create pages and other elements in the web application

The final makefile includes needed to set up the make environment should be:
<pre>
-include GNUmakefile.preamble
include $(GNUSTEP_MAKEFILES)/gswapp.make
-include GNUmakefile.postamble
</pre>
The preamble and postamble files are optional includes and will not error if they don't exist. It's good practice to have these in place to allow compile-time modifications during the development process and also for others if you distribute the code.

A worked-out example of a simple GNUmakefile for a GSWeb application is:

<pre>
include $(GNUSTEP_MAKEFILES)/common.make
include $(GNUSTEP_MAKEFILES)/Auxiliary/gsweb_wo.make

GSWAPP_NAME = SimpleDemo
SimpleDemo_HAS_GSW_COMPONENTS = YES
SimpleDemo_PRINCIPAL_CLASS = SimpleDemo
#SimpleDemo_RESOURCE_FILES = Resources/SimpleDemo.eomodeld
SimpleDemo_OBJC_FILES = \
SimpleDemo.m \
Session.m \
SimpleDemo_main.m \
Main.m \
Details.m

SimpleDemo_COMPONENTS = \
Main.wo Details.wo

-include GNUmakefile.preamble
include $(GNUSTEP_MAKEFILES)/gswapp.make
-include GNUmakefile.postamble
</pre>

The name of the project is SimpleDemo, and it contains GSWComponents (the basic building blocks of GSWeb), its principal class is SimpleDemo, there are no resource files for the runtime (there is an entry, but it's hashed-out), there are five Objective-C source files, and two components. You can see that the syntax allows you to break lines using the backslash '''\''' character as the last on the line to assist readability, especially for long lists of values, like the OBJC_FILES.

For more information as to customising this file, as well as setting up compiler options for third party libraries and includes, see the GNUstep makefile manual.

=== Mandatory code ===

GNUstepWeb expects a small amount of glue code and several classes to be present at runtime. Initial implementation of a web application may leave these in boiler-plate form, but most real-world projects end up adding significant extra functionality through the extension mechanisms they offer.

The mandatory code is as follows:
;main function:the runtime jumps to the beginning of the main function, which is used for initialisation of the the web application and can be used for initialisation of other resources such as C libraries etc
;Session class definition:used for per-session initialisation in the web application, in addition to holding instance variables and methods for each session. This class should be literally named Session.
;GSWApplication or WOApplication-derived class definition:used for web application instance-wide initialisation, and it may hold instance variables and methods across the entire instance.

Some worked out examples for the SimpleDemo web application follow. First SimpleDemo_main.m
<pre>
// SimpleDemo_main.m

#import <WebObjects/WebObjects.h>

int main (int argc, const char *argv[])
{
int rc;
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
rc = WOApplicationMain(@"SimpleDemo", argc, argv);
[pool release];
return rc;
}
</pre>
This creates an autorelease pool and begins the web application by invoking the application object.

Next Session.h:

<pre>
// Session.h from SimpleDemo

#import <WebObjects/WebObjects.h>

@interface Session: WOSession

// fill me with session instance variables

@end
</pre>

And Session.m:
<pre>

// Session.m from SimpleDemo
#import "Session.h"

@implementation Session

- (id) init
{
[super init];
[self setStoresIDsInCookies: YES];
[self setStoresIDsInURLs: NO];
return self;
}

@end
</pre>

The Session.m code above implements a small change in the normal behaviour of GNUstepWeb, forcing it to store session identifiers in cookies and not in the URL. There are good reasons not to do this in practice for some real web applications, but it does show the Session object may be used to change behaviour on a per-session basis.

Now for the application object, in two parts, SimpleDemo.h:

<pre>
// SimpleDemo.h

#import <WebObjects/WebObjects.h>

@interface SimpleDemo: WOApplication

@end
</pre>

And SimpleDemo.m:
<pre>
// SimpleDemo.m

#import "SimpleDemo.h"

@implementation SimpleDemo

@end
</pre>

The application can run quite successfully with very little other than this boilerplate code. Of course, real functionality requirements may mean creating or overriding methods in these classes (especially the -init methods), creation of new instance variables and so on.

=== Components ===

GSWeb uses a directory for every component. A component can represent a whole web page or just a part of it. It is easy to re-use pieces needed multiple times.

A component contains three files containing the HTML, the connections or bindings of your objects and additional information like the text-encoding used in the component. Those files are suffixed .html, .wod and .woo.

Additionally, a component is normally implemented with a corresponding subclass of [[GSWComponent|GSWComponent or WOComponent]].

In the SimpleDemo web application there are only two components defined. In a real application it's usual to have custom components providing style sheet information, headers, footers, navigation bars and so on that are reused in the components that correspond to pages.

==== Main.wo ====

The Main component normally provides the first page when a connection is made to the web application. The name is not arbitrary, and normally every GNUstepWeb application contains a Main component. Our implementation will consist of five files:
# <tt>Main.h</tt> the Objective-C class header for the Main component
# <tt>Main.m</tt> the Objective-C class implementation for the Main component
# <tt>Main.wo/Main.html</tt> containing the HTML markup
# <tt>Main.wo/Main.wod</tt> containing the bindings of the dynamic elements that exist in the HTML to the application's objects, and
# <tt>Main.wo/Main.woo</tt> which contains the text-encoding information.

==== Details.wo ====

The Details component is used to see how multiple page interactions and show additional component capabilities. The name is arbitrary.

Our custom component implementation will consist of five files:
# <tt>Details.h</tt> the Objective-C class header for this component
# <tt>Details.m</tt> the Objective-C class implementation for this component
# <tt>Details.wo/Details.html</tt> containing the HTML markup
# <tt>Details.wo/Details.wod</tt> containing the bindings of the dynamic elements that exist in the HTML to the application's objects, and
# <tt>Details.wo/Details.woo</tt> which contains the text-encoding information.

==== Want to know more? ====

The .woo files can seem a little mysterious in that they are only being used here to identify the text-encoding information of the component. In actual fact, they can be used for a number of other, quite powerful purposes including serialised information related to direct database transactions initiated from the .html and .wod files - in other words to avoid writing code!

A more in-depth description of [[GSWComponent|Components]] is available.

===The application dictionary===

=== Interface files ===

----

[[Category:GNUstepWeb]]
[[Category:Development]]

GSWeb application deployment

2008-01-19T18:09:20Z

Comrade: typewriter font

It's recommended to use the new [[Apache2Adaptor]] to serve your dynamic pages using Apache 2.

If using the new Apache2Adaptor, disregard instructions for the older adaptors that use libplist.

Different platforms use different configuration styles for Apache 2. Ensure you identify how it works on your platform.

=== Ubuntu 7.10 ===
To use a new Apache module, configuration files must be updated in the <tt>/etc/apache2/mods-enabled</tt> directory. The relevant files may already be installed in <tt>/etc/apache2/mods-available</tt> directory, and only require symlinking.

<tt>/etc/apache2/mods-enabled/gsw.load</tt> is used to force the module to be loaded by Apache 2:
<pre>
LoadModule gsw_module /usr/lib/apache2/modules/mod_gsw.so
</pre>

<tt>/etc/apache2/mods-enabled/gsw.conf</tt> is used to configure the adaptor with information about the web applications for which it will provide access:
<pre>
<IfModule gsw_module>
ShowApps on
App Name=SimpleDemo Instance=1 Host=127.0.0.1:9001
</IfModule>
</pre>

----

[[Category:GNUstepWeb]]

GSWeb application deployment

2008-01-19T18:06:08Z

Comrade: Ubuntu 7.10 quick start configuration info

It's recommended to use the new [[Apache2Adaptor]] to serve your dynamic pages using Apache 2.

If using the new Apache2Adaptor, disregard instructions for the older adaptors that use libplist.

Different platforms use different configuration styles for Apache 2. Ensure you identify how it works on your platform.

=== Ubuntu 7.10 ===
To use a new Apache module, configuration files must be updated in the /etc/apache2/mods-enabled directory. The relevant files may already be installed in /etc/apache2/mods-available directory, and only require symlinking.

/etc/apache2/mods-enabled/gsw.load is used to force the module to be loaded by Apache 2:
<pre>
LoadModule gsw_module /usr/lib/apache2/modules/mod_gsw.so
</pre>

/etc/apache2/mods-enabled/gsw.conf is used to configure the adaptor with information about the web applications for which it will provide access:
<pre>
<IfModule gsw_module>
ShowApps on
App Name=SimpleDemo Instance=1 Host=127.0.0.1:9001
</IfModule>
</pre>

----

[[Category:GNUstepWeb]]

Creating A Simple GSWeb Application

2008-01-19T17:50:40Z

Comrade: Created mandatory files section and placed demo code

== Introduction ==

[[GNUstepWeb]] is a framework for creating web-based applications using Objective-C. This guide aims to provide an overview of what is required in the creation and design of a very simple web application.

It is assumed you are familiar with GNUstep, and have a working GNUstep installation, including the [[GDL2]] and [[GSWeb]] frameworks. Pre-requisites for [[GSWeb application deployment]] should also be in place.

== File Components ==

In building your web application you will need to create a number of files. From scratch, the following should be a rough guide to getting it working. These include the Makefile, some mandatory "plumbing" code in Objective-C, [[GSWComponent]]s to provide the pages and subpage elements of the web application, and run-time resources.

=== The Makefile ===

For a web application, a special makefile is needed: luckily it's very similar to makefiles you may have used for other kinds of project. There is currently no out-of-the-box way to have these files built for you, so you'll have to do it manually.

'''GNUmakefile'''

Initial makefile includes needed to set up the make environment should be:
<pre>
include $(GNUSTEP_MAKEFILES)/common.make
include $(GNUSTEP_MAKEFILES)/Auxiliary/gsweb_wo.make
</pre>

Note that the second include forces GNUstepWeb to use Apple's WebObjects naming conventions. Dropping the _wo in the included filename will enable GSW naming conventions. It is useful to decide which convention you plan to use in the application early on because changing later will involve changing the naming convention of class names in many files in your project.

The key variables used in a web application's makefile are:
;GSWAPP_NAME:used to define the project's name in the makefile, replace the {PROJECTNAME} with the name in the variables listed below
;{PROJECTNAME}_HAS_GSW_COMPONENTS:used to indicate that [[GSWComponent]]s are present in the project. Normally, this is set to <TT>YES</TT>
;{PROJECTNAME}_PRINCIPAL_CLASS:used to identify the main class of the web application
;{PROJECTNAME}_RESOURCE_FILES:used to indicate the list of files that are needed in the runtime bundle
;{PROJECTNAME}_OBJC_FILES:contains the list of Objective-C files needed to compile the web application
;{PROJECTNAME}_COMPONENTS:lists the names of the components that will be used to create pages and other elements in the web application

The final makefile includes needed to set up the make environment should be:
<pre>
-include GNUmakefile.preamble
include $(GNUSTEP_MAKEFILES)/gswapp.make
-include GNUmakefile.postamble
</pre>
The preamble and postamble files are optional includes and will not error if they don't exist. It's good practice to have these in place to allow compile-time modifications during the development process and also for others if you distribute the code.

A worked-out example of a simple GNUmakefile for a GSWeb application is:

<pre>
include $(GNUSTEP_MAKEFILES)/common.make
include $(GNUSTEP_MAKEFILES)/Auxiliary/gsweb_wo.make

GSWAPP_NAME = SimpleDemo
SimpleDemo_HAS_GSW_COMPONENTS = YES
SimpleDemo_PRINCIPAL_CLASS = SimpleDemo
#SimpleDemo_RESOURCE_FILES = Resources/SimpleDemo.eomodeld
SimpleDemo_OBJC_FILES = \
SimpleDemo.m \
Session.m \
SimpleDemo_main.m \
Main.m \
Details.m

SimpleDemo_COMPONENTS = \
Main.wo Details.wo

-include GNUmakefile.preamble
include $(GNUSTEP_MAKEFILES)/gswapp.make
-include GNUmakefile.postamble
</pre>

The name of the project is SimpleDemo, and it contains GSWComponents (the basic building blocks of GSWeb), its principal class is SimpleDemo, there are no resource files for the runtime (there is an entry, but it's hashed-out), there are five Objective-C source files, and two components. You can see that the syntax allows you to break lines using the backslash '''\''' character as the last on the line to assist readability, especially for long lists of values, like the OBJC_FILES.

For more information as to customising this file, as well as setting up compiler options for third party libraries and includes, see the GNUstep makefile manual.

=== Mandatory code ===

GNUstepWeb expects a small amount of glue code and several classes to be present at runtime. Initial implementation of a web application may leave these in boiler-plate form, but most real-world projects end up adding significant extra functionality through the extension mechanisms they offer.

The mandatory code is as follows:
;main function:the runtime jumps to the beginning of the main function, which is used for initialisation of the the web application and can be used for initialisation of other resources such as C libraries etc
;Session class definition:used for per-session initialisation in the web application, in addition to holding instance variables and methods for each session. This class should be literally named Session.
;GSWApplication or WOApplication-derived class definition:used for web application instance-wide initialisation, and it may hold instance variables and methods across the entire instance.

Some worked out examples for the SimpleDemo web application follow. First SimpleDemo_main.m
<pre>
// SimpleDemo_main.m

#import <WebObjects/WebObjects.h>

int main (int argc, const char *argv[])
{
int rc;
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
rc = WOApplicationMain(@"SimpleDemo", argc, argv);
[pool release];
return rc;
}
</pre>
This creates an autorelease pool and begins the web application by invoking the application object.

Next Session.h:

<pre>
// Session.h from SimpleDemo

#import <WebObjects/WebObjects.h>

@interface Session: WOSession

// fill me with session instance variables

@end
</pre>

And Session.m:
<pre>

// Session.m from SimpleDemo
#import "Session.h"

@implementation Session

- (id) init
{
[super init];
[self setStoresIDsInCookies: YES];
[self setStoresIDsInURLs: NO];
return self;
}

@end
</pre>

The Session.m code above implements a small change in the normal behaviour of GNUstepWeb, forcing it to store session identifiers in cookies and not in the URL. There are good reasons not to do this in practice for some real web applications, but it does show the Session object may be used to change behaviour on a per-session basis.

Now for the application object, in two parts, SimpleDemo.h:

<pre>
// SimpleDemo.h

#import <WebObjects/WebObjects.h>

@interface SimpleDemo: WOApplication

@end
</pre>

And SimpleDemo.m:
<pre>
// SimpleDemo.m

#import "SimpleDemo.h"

@implementation SimpleDemo

@end
</pre>

The application can run quite successfully with very little other than this boilerplate code. Of course, real functionality requirements may mean creating or overriding methods in these classes (especially the -init methods), creation of new instance variables and so on.

=== Components ===

GSWeb uses a directory for every component. A component can represent a whole web page or just a part of it. It is easy to re-use pieces needed multiple times.
A component contains three files they contain the HTML, the connections or bindings of your objects and additional information like the used encoding. Those files are suffixed .html, .wod and .woo.
A more in-depth description of [[GSWComponent|Components]] is available.

===The application dictionary===

=== Interface files ===

----

[[Category:GNUstepWeb]]
[[Category:Development]]

Creating A Simple GSWeb Application

2008-01-19T17:09:20Z

Comrade: Updated makefile section with common variables and includes

Pixen.app

2007-02-14T11:59:40Z

Comrade: corrected pixen link

{{stub}}
{{Application|
shortdescription = Graphics editing software for small-scale pictures for GNUstep. |
currentversion = [http://download.gna.org/gsimageapps/Pixen-0.1.tar.bz2 0.1] |
releasedate = Dec 15, 2004 |
license = MIT |
overview = < ... > |
features = < ... > |
maintainer = Andy Matushak, Fabien Vallon |
relatedlinks =
* http://home.gna.org/gsimageapps/
* http://opensword.org/pixen/ |
category = [[Category:Graphics Applications]]
}}

GSWeb

2006-12-22T00:53:31Z

Comrade:

#redirect [[GNUstepWeb]]

Creating A Simple GSWeb Application

2006-12-20T22:56:31Z

Comrade: Initial version; GNUmakefile etc more to come

GNUstepWeb

2006-12-20T21:21:36Z

Comrade: A little structure and a link to a new tutorial

GNUstepWeb is a development framework for web applications written in Objective-C which is designed to be source-code compatible with [[WebObjects]] 4.5 - a product originally developed by NeXT Inc, whose newer versions have been released by Apple and are Java-based.

=== Availability ===
This library is a component of the [[GNUstep]] project in the dev-libs section and is available in the standard ways - such as the [ftp://ftp.gnustep.org/pub/daily-snapshots/dev-libs.current.tar.bz2 GNUstep ftp site].

David Wetzel recommends using his recent branch that can be obtained by executing the following [[SVN]] check out in an empty directory
svn co http://svn.gna.org/svn/gnustep/libs/gsweb/branches/06-02-dwetzel

=== Documentation and Resources ===
Apple has [http://developer.apple.com/documentation/LegacyTechnologies/WebObjects/WebObjects_4.5/webobjects.html legacy WebObjects 4.5 documentation] available. Please note that the official site is [http://www.gnustepweb.org/ gnustepweb.org] is somewhat out of date.

David Wetzel runs a low-volume mailing list called [http://lists.turbocat.net/mailman/listinfo.cgi/gswhackers gswhackers].

=== Tutorials ===
[[Creating A Simple GSWeb Application]] is very easy.

[[Category:GNUstepWeb]]
[[Category:Networking_Frameworks]]

GNUstepWeb

2006-12-20T20:51:09Z

Comrade: Update GSWeb links

GNUstepWeb is a development framework for web applications which is designed to be source-code compatible with [[WebObjects]] 4.5 - a product originally developed by NeXT Inc. Newer versions of Apple's WebObjects are Java-based.

This library is a component of the [[GNUstep]] project in the dev-libs section and is available in the standard ways - such as [[SVN]] and ftp://ftp.gnustep.org/pub/daily-snapshots/dev-libs.current.tar.bz2

The official site is http://www.gnustepweb.org/ but is somewhat out of date.

[[Category:Networking_Frameworks]]

Frameworks

2006-09-16T21:22:41Z

Comrade: Added Narrative plotting framework

A framework, sometimes also called a "kit", is a way to package a logically related set of [[class|classes]], [[protocol|protocols]] and functions together with localized strings, online documentation, and other pertinent files. GNUstep provides the [[Foundation]] and [[AppKit|Application Kit]] frameworks.

Add your extension, framework, library or bundle below to one of the categories. If a category doesn't yet exist, choose a new name as a short description (eg. "Math" or "Science" or "Games"). Simply calling it "Library" is ''not'' a good description ;-) Also, please try to stay ''alphabetically'' ...

See also:
* [[Scripting of frameworks|How to make frameworks scriptable]]
* [[PrefixIndex|Index of prefixes used by different GNUstep-related libraries and frameworks]]

== Core frameworks ==

* [[Base]] - Foundation kit
* [[GUI]] - Application kit

== Extension frameworks (official parts of GNUstep project) ==

=== Audio ===

=== Database ===

* [[GDL2]] - Database frameworks (Enterprise Objects/EO)

=== Development ===

=== Graphics ===

=== Networking ===

* [[GNUstepWeb]] - WebObjects 4.x compatible framework that provides an MVC approach to building web applications and which integrates tightly with [[GDL2]] to provide easy access to database objects.

=== PIM ===

=== Scripting and Binding ===

* [ftp://ftp.gnustep.org/pub/gnustep/libs/ GNUstep Guile] - Extension to make use of the GUILE scripting language.
* [http://www.gnustep.it/jigs/ JIGS] - GNUstep Java interface
* [http://www.gnustep.org/experience/RIGS.html RIGS] - GNUstep Ruby bridge
* [[StepTalk]] - Scripting framework

=== Security ===

=== Text Processing ===

== Other frameworks (not official parts of GNUstep project) ==

=== Audio ===

* [http://musickit.sourceforge.net/ MusicKit] - The MusicKit is an object-oriented software system for building music, sound, signal processing, and MIDI applications. It has been used in such diverse commercial applications as music sequencers, computer games, and document processors. Professors and students in academia have used the MusicKit in a host of areas, including music performance, scientific experiments, computer-aided instruction, and physical modeling.

=== Database ===

=== Development ===

* [[DevelopmentKit]] - computer aided development
* [http://homepage.mac.com/gandreas/ IDEKit] - Framework for programmer editors (I have stated to port it to GNUstep, to know more you can contact me [[user:Qmathe | Quentin Mathé]])
* [[KoKit]] : A framework '''collection''', that extends the functionality of GNUstep's [[Foundation]] and [[AppKit]].
** [[KoKit#KoBase|KoBase]] - A low-lewel framework providing simple to use debugging aids.
** [[KoKit#KoFoundation|KoFoundation]] - Extension to [[Foundation]] framework.
** [[KoKit#KoAppKit|KoAppKit]] - Contains useful [[AppKit]] extensions and widgets.
** [[KoKit#KoCrypt|KoCrypt]] - Provides classes of cryptographic algorithms.
** [[KoKit#KoNet|KoNet]] - A collection of classes that deal with BSD socket programming.
* [http://www.people.virginia.edu/~yc2w/GNUstep/english/ PCRE Parser] - Perl-compatible '''regular expression''' library.
* [http://www.opengroupware.org/ SKYRIX Core] - Various Foundation extensions, classes for processing MIME entities

=== Graphics ===

* [http://www.gnu.org/software/gnu3dkit/gnu3dkit.html 3DKit] - The GNU 3DKit provides multiple Objective-C frameworks which facilitate the design and implementation of '''3D''' applications based on '''OpenGL'''. It tightly integrates with GNUstep and Cocoa.
* [http://home.gna.org/gsimageapps/ CameraKit] : a simple wrapper to [http://gphoto.org/proj/libgphoto2/ libgphoto]
* [http://home.gna.org/gsimageapps/ DiagramKit] : DiagramKit is a framework for manipulating, linking, drawing diagrams.
* [http://savannah.nongnu.org/projects/good GOOD] - GOOD stands for GNUstep Object Oriented Diagramming. It is a library that aims to provide GNUstep developers a way to add '''modern''' diagramming capabilities to their own application.
* [http://maliwan.sourceforge.net/ Maliwan] - GNUstep Generic Graphic Manipulate Framework.
* [http://home.gna.org/gsimageapps/ PDFKit] : PDFKit is a framework that supports rendering of PDF content in GNUstep applications.
* [http://home.gna.org/gsimageapps/ SlideShowKit] : a small kit to include slideshow in your application
* [http://sourceforge.net/projects/narrative Narrative] - an LGPLed object oriented plotting framework for Cocoa and GNUstep

=== Networking ===

* [https://gna.org/projects/gswebkit/ GSWebKit] - The GNUstep Web Kit provides a set of classes to display web content in windows, and implements browser features such as following links when clicked by the user, managing a back-forward list, and managing a history of pages recently visited"
* [[KoKit#KoNet|KoNet]] - A collection of classes that deal with '''BSD socket''' programming. It is part of [[KoKit]].
* [http://netclasses.aeruder.net/ netclasses] - A GNUstep '''socket library'''.
* [http://www.collaboration-world.com/cgi-bin/project/index.cgi?pid=3 Pantomime] : The Pantomime framework supports the major mail protocols: POP3, IMAP, and SMTP.
* [http://www.opengroupware.org/ SKYRIX Core] - Provides a java.io like stream and socket library, a full IMAP4 implementation, a prototypical POP3 and SMTP processors and an Objective-C wrapper for LDAP directory services.
* [http://www.gnustep.org/ SMBKit] - SAMBA library wrapper
* [[KoKit#Tryst|Tryst]] - Provides an implementation of [http://www.apple.com/macosx/features/bonjour/ Bonjour™ (formerly known as Rendezvous™)] for GNUstep

=== PIM ===

* [http://giesler.biz/bjoern/en/sw_addr.html Addresses] - A framework that allows access to the addresses database in a way that is sourcecode-compatible with Apple's AddressBook framework. It also contains a view framework to facilitate the construction of applications that use the contact database.
* [http://www.opengroupware.org/ SKYRIX Core] - Classes for iCalendar/vCard objects
* [http://opengroupware.org/en/projects/syncml/index.html syncml] - SyncML is an XML based standard for data synchronization.

=== Scripting and Binding ===

* [http://camelbones.sourceforge.net/index.php CamelBones] - GNUstep/Cocoa Perl bridge
* [http://pyobjc.sourceforge.net/ Pyobjc] - GNUstep/Cocoa Python bridge

=== Security ===

* [[KoKit#KoCrypt|KoCrypt]] - Provides classes of '''cryptographic algorithms'''. It is part of [[KoKit]].

=== Text Processing ===

* [http://www.apax.net/swpets/objc_p1.html libobjcxerces] - XML (SAX, SAX2) and DOM handling in Objective-C using libXerces.
* [http://www.opengroupware.org/ SKYRIX XML] - provides a SAX2 implementation for Objective-C, DOM on top of SaxObjC, an XML-RPC implementation (without the transport layer), SaxObjC driver bundles for: libical (iCalendar,vCard), expat (XML), plists, pyx, CoreFoundation (XML) )

== Bundles ==

* [[Backend]] - obligatory bundle for GNUstep backed graphics system
* [[Camaelon]] - theme bundle

[[Category:Development]]

Package management

2006-09-13T18:11:13Z

Comrade: Current implementation

Package management tools will be required on GNUstep-only platforms, and are nice-to-have on platforms where GNUstep is only one environment. Having working package management tools makes the environment much more accessable to end users and application developers, by lowering the threshold to having a running environment.

Please add points below as you think of them, it's useful to collect issues and questions in one place.

== Scope for package management within GNUstep ==

Package management tools will need to address some of the following issues:

* how do we ensure the authenticity and integrity of a package?

* how many competing package formats do we really need?

* should a package management tool interact with a (native) package management environment? (ie create synthetic dpkg data on install so that platform package management can be used by the system manager?)

* internationalisation of packages - making sure that installation metadata is separated from end-user information

=== Source packaging ===

* is FTP'ing the existing tar.gz or CVS approach right? (ie no package management?)

=== Binary packaging ===

We need to make sure that users installing binary packages don't get unpleasant surprises:

* how can installers inform end-users before install if the package is not suitable for their platform? (need to get some agreement on metadata)

* how can installers maximise user flexibility in terms of application or framework installation, especially as we can't necessarily control filesystem layout?

Multi-platform packages make sense for some application providers, especially if we can get cross-building working in Project Center.

* should non-flat packages be generated automatically by package creation tools integrated with GNUstep make? (we'd need merge and strip tools at the least)

* should a multi-platform format be server-side strippable to decrease download size? (this could be hard, might be easier to develop strip tools instead)

== Current implementations ==

There is an implementation called (surprise!) Installer.app http://www.etoile-project.org/etoile/mediawiki/index.php?title=Installer in Etoile.

Talk:Development Subprojects

2006-09-13T18:07:12Z

Comrade: Warn about orphan pages

== TODO ==

integrate this with the rest of the wiki or delete it. [[User:Madleser|Madleser]]

We have a lot of orphaned content, some of it interesting and useful including some of these links. Please ensure that if you nuke this page that the links are actually maintained somewhere useful. [[User:Comrade|Comrade]]

DesktopServicesKit

2006-09-12T19:22:23Z

Comrade: Create page

== Proposal for a Desktop Services Framework ==

With Camaelon theming, GNUstep applications may be able to offer an "almost native" experience in alien environments like Windows and MacOS.

To avoid significant and repetitive modifications to applications which may require some support from the native desktop environment or provide services to other applications (classic low-threshhold activities such as handling MIME and file types, all the way through to native file dialogs and gateways into local accessibility services), it may be sensible to begin work on a DesktopServicesKit.

The following is a limited list of common desktop services offered (to one extent or another) by environments like KDE, GNOME, Windows, MacOS, Etoile and ...:
* desktop notifications and information
* file and directory dialogs
* printing services and dialogs
* registration of MIME and file-type handling capabilities
* native application helper launch and termination
* gateway from GNUstep accessibility framework (does it exist yet?) to local platform
* privilege escalations

This would logically be complemented by a rather lighter System Services Framework to deal with native operating system issues such as networking, disk, volume, filesystem and file metadata, capabilities and permissions management, authentication services, etc.

Interface Builder

2006-09-12T18:51:08Z

Comrade: Link to Gorm

GNUstep's IB implementation, called [[Gorm]], attempts to improve on many of the aspects of the OpenStep Interface Builder. There are some features which are available in Gorm which are not available in IB. For more information about this see the Gorm Manual.

More information about Apple's Interface Builder is here: http://developer.apple.com/tools/interfacebuilder/

Writing portable code

2006-09-12T18:48:37Z

Comrade: Messed-up MediaWiki link corrected ;-)

GNUstep opens up some fairly interesting opportunities to target a number of platforms with the same source code, for example porting Mac OS X Cocoa applications to Linux, the BSDs, other Unices and (ultimately) Windows without significant re-engineering effort or degraded end-user functionality.

Some portability gotchas are listed below (please update when you run into a new one!):

== Porting Applications ==

=== Porting from NeXTSTEP (NX*) to GNUstep ===

For this you should have access to an old OPENSTEP installation, or find a friend who has one, otherwise you're simply better off just rewriting the application from scratch. There are some scripts which can be used to convert an application from NeXTSTEP to OPENSTEP located in <tt>/NextDeveloper/OpenStepConversion/ConversionScripts</tt>. They use a scripting language called "tops". I haven't been able, as yet, to locate a version of tops for Linux or any other operating system other than Mac OS X or OPENSTEP/Mach or NeXTSTEP. There are a few conversion applications which basically just use the tops scripts to do the conversion. They are actually two versions of the same program, but the second one doesn't run on NeXT, so here's both. These are:

* [ftp://next-ftp.peak.org/openstep/mach/apps/devtools/Conversion.0.5.NI.tar.gz]
* [ftp://next-ftp.peak.org/openstep/mach/apps/devtools/ConversionII.1.0.I.tar.gz]

You should be able to point it at the project directory you wish to convert and start the conversion. The GUI is very straightforward. You can also run the tops scripts on a Mac simply by saying:

tops -verbose -scriptfile {scriptfilename} {filestoconvert}

All of the files are converted in place. You must run all of the tops scripts in the ConversionScripts directory against the application code. It is considerably simply to use the existing applications. Unfortunately these scripts do not exist on Mac OS X, otherwise porting the Conversion application might be useful.

When you start the scripts, if you're running them on black hardware you should go get a cup of coffee and watch a movie with your wife or go code something else for a while. The conversion will take a good long while on an older machine. I haven't timed it on the Mac, though. Once this is done, there is still a long way to go. Read on.

OPENSTEP4.2/Mach had a class called NSCStringText. This class was primarily for apps which were converted from NeXTSTEP to use as a stop-gap measure in OpenStep. This is one of the main reasons why it isn't in GNUstep. You will need to make sure that any classes modified by the scripts to use NSCStringText will use NSText and it's related classes as appropriate. OPENSTEP4.2/Mac also had some other extensions on the OpenStep standard such as NXStreams. You will also need to convert any and all instances of NXStream to use NSData instead in order to make your app work with GNUstep.

If your app is fairly small, you shouldn't be in for a great shock, but if your app is heavily reliant on the old Text object from NeXTSTEP, you have a lot of work ahead. Other gaps which the scripts might leave are problems with NSUserDefaults which it can't fix on it's own.

=== Porting from Cocoa or OPENSTEP (NS*) to GNUstep ===

Porting from Cocoa or OPENSTEP to GNUstep has different aspects. First there is the compatibility of the basic Foundation Kit and Application Kit. We support a lot of classes, but not all of them and the same is true for specific methods, specifically newly introduced classes and methods in Cocoa may still be missing as GNUstep started out aiming at OpenStep compatibility.

Second you have all the additional frameworks and libraries programmers on Mac OS X take for granted, for some of them free replacements exists, for most they are still missing. Mac OS X developers should try and avoid CoreFoundation as this will complicate your dependency situation on non-Mac hosts, even if that part of CoreFoundation has actually been ported. GNUstep Base and the FoundationKit offer many parts of the CoreFoundation functionality in a natural [[Objective-C]] manner. To be a bit more specific:

* don't use Core* (CoreFoundation, CoreSound, CoreAnimation, ...)
* don't use KeyChain
* don't use Carbon
* don't use Quartz
* don't use QuickTime
* don't use WebKit (GCC 4.1 and up support ObjC++, but currently, there exists no WebKit port for GNUstep)
* don't use altivec features or the vecLib.framework (a collection of functions for vector manipulation, an Apple specific extension)
* don't use anything else we do not provide

If you committed none of these portability evils, the rest is relatively straightforward:

# [[Writing Makefiles|Write a new GNUstep make file]] for the project (very easy, still there is currently no automatic way to do so).
# Make sure the Nib files are readable by GNUstep. Make certain that they are 10.2.x or later nibs so that they can be read by GUI. Another option is to load them into Gorm and convert them into .gorm files. If they're from OPENSTEP or Mac OS X 10.1 or earlier, see [[#Porting_.nib_files_from_OPENSTEP_or_Mac_OS_X_10.1_and_earlier|below]].
# Provide an Info.plist.

=== Porting from GNUstep to Cocoa ===

This should be an easy transition since GNUstep implements most of Cocoa, except for the very Apple specific classes such as the scripting extensions. Since Gorm does not yet save .nib files, you will need to create the interfaces using IB. Also there is a gorm reading/parsing framework for Cocoa in the works as well, so please stay tuned.

Will will need to:

* Make a Project Builder project for your app or
* an Xcode project for your app

Do the following:

* Open Xcode.
* Choose Application (if your project is an application)
* Enter the name and location you wish the Project to reside at
* Copy your files from your GNUstep application into the new project
* Using the "Add Existing Files" option to add these file to your project.

You should preserve your original directory structure if you want to distribute one package for both GNUstep and Cocoa.

== Stumbling Blocks ==

=== Apple's Cocoa.h ===

It is there to enable pre-compiled headers and speed up compile time thusly. Anyway, it contains just two lines:

#import <Foundation/Foundation.h>
#import <AppKit/AppKit.h>

So you can easily work around this by providing your own or replace your include of <Cocoa/Cocoa.h> with just the above, which will also work on OS-X.

=== Distinguishing Between Cocoa and GNUstep ===

#ifdef GNUSTEP
''/* GNUstep code goes here ... */''
#else
''/* OS-X Cocoa native code goes here ... */''
#endif

=== Porting .nib files from OPENSTEP or Mac OS X 10.1 and earlier ===

On Mac OS X, this is a simple matter of loading the .nibs into InterfaceBuilder.app and saving them in the new format. Another possibility is using nib2gmodel, the only one when porting from OPENSTEP, and mind you, you need to do the converting ''there''. First, get [http://freshmeat.net/projects/nib2gmodel/ nib2gmodel], follow the included instructions to build and install it. Once that's done you're ready to begin:

Run the nib2gmodel program on your nib:

nib2gmodel mygui.nib mygui.gmodel

This should create the .gmodel as a plist. I recommend that you convert the gmodel to a "normal" plist instead of an XML plist. You can do that by doing this on OS X:

pl < mygui.gmodel -output mygui.ser
pl > mygui.gmodel -input mygui.ser
rm mygui.ser

Now you can either use the gmodel as it is, or you can convert it to a .gorm file.

==== Gmodel to .gorm conversion ====

NOTE: Conversion from gmodel to .gorm is experimental and will probably remain so for a while. It currently works in the majority of cases, but there are still improvements which need to be made.

Conversion to a .gorm file is relatively straightforward:

* Start Gorm.app.
* Choose Gorm->Document->Open and find the gmodel you wish to load.
* Gorm will prompt you to either define the superclass for classes it doesn't know about or to parse the headers.

After you've defined all of the unknown classes, Gorm should complete the conversion. Once this is done you should save the result to make sure you don't loose your work.

=== Xcode conversion ===

* how to convert Xcode project to GNUstep project (creating a GNUstep [http://www.gnustep.it/nicola/Tutorials/WritingMakefiles/index.html Makefile] or [[ProjectCenter]])

* PBTOMAKE. [http://www.macdevcenter.com/pub/a/mac/2004/04/20/xcodetounix.html xcodetounix] (download at [http://members.bellatlantic.net/%7Evze35xda/software.html]) is a tool for converting Xcode and Project Builder files to generic Unix Makefiles. It would probably be a good start for converting to a GNUstep makefile.

== Notes ==

=== Do not rely on tools available in development environment ===

All the world is not Linux or FreeBSD or Windows. System constants may be different on different platforms. Paths to command-line tools, the parameters they accept and locations of temporary directories may be different to what you are used to on your platform.

* [[Foundation|GNUstep Base]] and the [[Foundation|FoundationKit]] offer some of this functionality "for free".
* Try not to hard code paths and so on into your code, use macros (not recommended), or even better an abstraction mechanism.
* Avoid hard-coding system constants, or platform-specific ones where POSIX or commonly-accepted ones exist (and we're not talking about glibc here :-)
* Try to avoid advanced features of the linker, such as weak symbols, which may not be present on non-ELF systems. While this will work perfectly on most systems, it is not portable to all systems, most notably Windows.

=== When platform-specific code cannot be avoided ===

There are cases where you may need to write platform-specific code, especially in the case of desktop applications and services which make use of facilities not standardised by POSIX or by the FoundationKit and AppKit specifications, at least use [[Identifying the target platform|standard platform macros]].

These platform-specific, or even desktop-specific requirements could be re-used by other projects - and even enhance desktop-integration efforts for GNUstep applications - by abstracting out common code into currently hypothetical [[PlatformKit]] and [[DesktopServicesKit]] frameworks.

[[Category:Project procedures]]

Writing portable code

2006-09-12T18:47:16Z

Comrade: Added link to IdentifyingTheTargetPlatform and discussed platform specific code possibilities

GNUstep opens up some fairly interesting opportunities to target a number of platforms with the same source code, for example porting Mac OS X Cocoa applications to Linux, the BSDs, other Unices and (ultimately) Windows without significant re-engineering effort or degraded end-user functionality.

Some portability gotchas are listed below (please update when you run into a new one!):

== Porting Applications ==

=== Porting from NeXTSTEP (NX*) to GNUstep ===

For this you should have access to an old OPENSTEP installation, or find a friend who has one, otherwise you're simply better off just rewriting the application from scratch. There are some scripts which can be used to convert an application from NeXTSTEP to OPENSTEP located in <tt>/NextDeveloper/OpenStepConversion/ConversionScripts</tt>. They use a scripting language called "tops". I haven't been able, as yet, to locate a version of tops for Linux or any other operating system other than Mac OS X or OPENSTEP/Mach or NeXTSTEP. There are a few conversion applications which basically just use the tops scripts to do the conversion. They are actually two versions of the same program, but the second one doesn't run on NeXT, so here's both. These are:

* [ftp://next-ftp.peak.org/openstep/mach/apps/devtools/Conversion.0.5.NI.tar.gz]
* [ftp://next-ftp.peak.org/openstep/mach/apps/devtools/ConversionII.1.0.I.tar.gz]

You should be able to point it at the project directory you wish to convert and start the conversion. The GUI is very straightforward. You can also run the tops scripts on a Mac simply by saying:

tops -verbose -scriptfile {scriptfilename} {filestoconvert}

All of the files are converted in place. You must run all of the tops scripts in the ConversionScripts directory against the application code. It is considerably simply to use the existing applications. Unfortunately these scripts do not exist on Mac OS X, otherwise porting the Conversion application might be useful.

When you start the scripts, if you're running them on black hardware you should go get a cup of coffee and watch a movie with your wife or go code something else for a while. The conversion will take a good long while on an older machine. I haven't timed it on the Mac, though. Once this is done, there is still a long way to go. Read on.

OPENSTEP4.2/Mach had a class called NSCStringText. This class was primarily for apps which were converted from NeXTSTEP to use as a stop-gap measure in OpenStep. This is one of the main reasons why it isn't in GNUstep. You will need to make sure that any classes modified by the scripts to use NSCStringText will use NSText and it's related classes as appropriate. OPENSTEP4.2/Mac also had some other extensions on the OpenStep standard such as NXStreams. You will also need to convert any and all instances of NXStream to use NSData instead in order to make your app work with GNUstep.

If your app is fairly small, you shouldn't be in for a great shock, but if your app is heavily reliant on the old Text object from NeXTSTEP, you have a lot of work ahead. Other gaps which the scripts might leave are problems with NSUserDefaults which it can't fix on it's own.

=== Porting from Cocoa or OPENSTEP (NS*) to GNUstep ===

Porting from Cocoa or OPENSTEP to GNUstep has different aspects. First there is the compatibility of the basic Foundation Kit and Application Kit. We support a lot of classes, but not all of them and the same is true for specific methods, specifically newly introduced classes and methods in Cocoa may still be missing as GNUstep started out aiming at OpenStep compatibility.

Second you have all the additional frameworks and libraries programmers on Mac OS X take for granted, for some of them free replacements exists, for most they are still missing. Mac OS X developers should try and avoid CoreFoundation as this will complicate your dependency situation on non-Mac hosts, even if that part of CoreFoundation has actually been ported. GNUstep Base and the FoundationKit offer many parts of the CoreFoundation functionality in a natural [[Objective-C]] manner. To be a bit more specific:

* don't use Core* (CoreFoundation, CoreSound, CoreAnimation, ...)
* don't use KeyChain
* don't use Carbon
* don't use Quartz
* don't use QuickTime
* don't use WebKit (GCC 4.1 and up support ObjC++, but currently, there exists no WebKit port for GNUstep)
* don't use altivec features or the vecLib.framework (a collection of functions for vector manipulation, an Apple specific extension)
* don't use anything else we do not provide

If you committed none of these portability evils, the rest is relatively straightforward:

# [[Writing Makefiles|Write a new GNUstep make file]] for the project (very easy, still there is currently no automatic way to do so).
# Make sure the Nib files are readable by GNUstep. Make certain that they are 10.2.x or later nibs so that they can be read by GUI. Another option is to load them into Gorm and convert them into .gorm files. If they're from OPENSTEP or Mac OS X 10.1 or earlier, see [[#Porting_.nib_files_from_OPENSTEP_or_Mac_OS_X_10.1_and_earlier|below]].
# Provide an Info.plist.

=== Porting from GNUstep to Cocoa ===

This should be an easy transition since GNUstep implements most of Cocoa, except for the very Apple specific classes such as the scripting extensions. Since Gorm does not yet save .nib files, you will need to create the interfaces using IB. Also there is a gorm reading/parsing framework for Cocoa in the works as well, so please stay tuned.

Will will need to:

* Make a Project Builder project for your app or
* an Xcode project for your app

Do the following:

* Open Xcode.
* Choose Application (if your project is an application)
* Enter the name and location you wish the Project to reside at
* Copy your files from your GNUstep application into the new project
* Using the "Add Existing Files" option to add these file to your project.

You should preserve your original directory structure if you want to distribute one package for both GNUstep and Cocoa.

== Stumbling Blocks ==

=== Apple's Cocoa.h ===

It is there to enable pre-compiled headers and speed up compile time thusly. Anyway, it contains just two lines:

#import <Foundation/Foundation.h>
#import <AppKit/AppKit.h>

So you can easily work around this by providing your own or replace your include of <Cocoa/Cocoa.h> with just the above, which will also work on OS-X.

=== Distinguishing Between Cocoa and GNUstep ===

#ifdef GNUSTEP
''/* GNUstep code goes here ... */''
#else
''/* OS-X Cocoa native code goes here ... */''
#endif

=== Porting .nib files from OPENSTEP or Mac OS X 10.1 and earlier ===

On Mac OS X, this is a simple matter of loading the .nibs into InterfaceBuilder.app and saving them in the new format. Another possibility is using nib2gmodel, the only one when porting from OPENSTEP, and mind you, you need to do the converting ''there''. First, get [http://freshmeat.net/projects/nib2gmodel/ nib2gmodel], follow the included instructions to build and install it. Once that's done you're ready to begin:

Run the nib2gmodel program on your nib:

nib2gmodel mygui.nib mygui.gmodel

This should create the .gmodel as a plist. I recommend that you convert the gmodel to a "normal" plist instead of an XML plist. You can do that by doing this on OS X:

pl < mygui.gmodel -output mygui.ser
pl > mygui.gmodel -input mygui.ser
rm mygui.ser

Now you can either use the gmodel as it is, or you can convert it to a .gorm file.

==== Gmodel to .gorm conversion ====

NOTE: Conversion from gmodel to .gorm is experimental and will probably remain so for a while. It currently works in the majority of cases, but there are still improvements which need to be made.

Conversion to a .gorm file is relatively straightforward:

* Start Gorm.app.
* Choose Gorm->Document->Open and find the gmodel you wish to load.
* Gorm will prompt you to either define the superclass for classes it doesn't know about or to parse the headers.

After you've defined all of the unknown classes, Gorm should complete the conversion. Once this is done you should save the result to make sure you don't loose your work.

=== Xcode conversion ===

* how to convert Xcode project to GNUstep project (creating a GNUstep [http://www.gnustep.it/nicola/Tutorials/WritingMakefiles/index.html Makefile] or [[ProjectCenter]])

* PBTOMAKE. [http://www.macdevcenter.com/pub/a/mac/2004/04/20/xcodetounix.html xcodetounix] (download at [http://members.bellatlantic.net/%7Evze35xda/software.html]) is a tool for converting Xcode and Project Builder files to generic Unix Makefiles. It would probably be a good start for converting to a GNUstep makefile.

== Notes ==

=== Do not rely on tools available in development environment ===

All the world is not Linux or FreeBSD or Windows. System constants may be different on different platforms. Paths to command-line tools, the parameters they accept and locations of temporary directories may be different to what you are used to on your platform.

* [[Foundation|GNUstep Base]] and the [[Foundation|FoundationKit]] offer some of this functionality "for free".
* Try not to hard code paths and so on into your code, use macros (not recommended), or even better an abstraction mechanism.
* Avoid hard-coding system constants, or platform-specific ones where POSIX or commonly-accepted ones exist (and we're not talking about glibc here :-)
* Try to avoid advanced features of the linker, such as weak symbols, which may not be present on non-ELF systems. While this will work perfectly on most systems, it is not portable to all systems, most notably Windows.

=== When platform-specific code cannot be avoided ===

There are cases where you may need to write platform-specific code, especially in the case of desktop applications and services which make use of facilities not standardised by POSIX or by the FoundationKit and AppKit specifications, at least use [[standard platform macros|Identifying the target platform]].

These platform-specific, or even desktop-specific requirements could be re-used by other projects - and even enhance desktop-integration efforts for GNUstep applications - by abstracting out common code into currently hypothetical [[PlatformKit]] and [[DesktopServicesKit]] frameworks.

[[Category:Project procedures]]

Application News

2006-02-22T19:40:12Z

Comrade: Etoile: I can't do accents, sorry; also not really an app, but it is a release

{| border="1" cellpadding="2"
! Date !! Application and Link !! Version
|-
| 22. Feb 2005 || [http://www.etoile-project.org Etoile] || 0.1
|-
| 15. Feb 2005 || [[KoKit#Tryst|Tryst]] || 107pre5
|-
| 15. Feb 2005 || [[KoKit#KoBase|KoBase]] || 0.3.2
|-
| 09. Feb 2006 || [http://mail.rochester.edu/~asveikau/grouch/ Grouch] || (currently snapshot only)
|-
| 08. Feb 2006 || [http://notebook.cowgar.com/ NoteBook] || 0.3
|-
| 25. Jan 2006 || [http://gnustep.org/experience/Gorm.html Gorm] || 1.0.4
|-
| 15. Jan 2006 || [http://www.gnustep.org/experience/ProjectCenter.html ProjectCenter] || 0.4.3
|-
| 15. Jan 2006 || [http://sourceforge.net/projects/fortytwo/ 42] || 0.1.0
|-
| 08. Jan 2006 || [http://www.random-ideas.net/Software/WildMenus-jd.tar.gz WildMenus] || modified by Jiva DeVoe
|-
| 04. Jan 2006 || [http://sourceforge.net/projects/dimvisual/ DIMVisual] || 0.2
|}

== Older News ==
[[Application_News_2005|2005]],
[[Application_News_2004|2004]],
[[Application_News_2003|2003]],
[[Application_News_2002|2002]]

KoKit

2006-02-01T16:35:19Z

Comrade: spelling change

KoKit is a framework collection, that extends the functionality of GNUstep's [[Foundation]] and [[AppKit]]. Basically it's a collection of classes we use repeatedly, so instead of adding the source again and again, we decided to create KoKit.

It currently consists of the following frameworks:

* '''KoBase''' is the low-level framework in the KoKit framework collection. It provides some simple to use debugging aids, instance counting to discover and track memory leaks, and functions for easy C string manipulation.

* '''KoFoundation''' is an extension to GNUstep's [[Foundation]] framework. It adds additional containers, such as LIFO (stack) and FIFO (queue), a signal handler and more.

* '''KoAppKit''' is an extension to GNUstep's [[AppKit]] framework. It adds a collection of useful extensions and widgets that make GUI development a bit easier.

* '''KoCrypt''' provides a collection of classes of cryptographic algorithms and categories for quick and easy access.

* '''KoNet''' is a collection of classes that deal with BSD socket programming.

----

[[Image:Tryst.jpg|right|thumbnail|Example screenshot of a net service browser (TBrowser.app).]]

* '''Tryst''' is a ''proof of concept'' implementation of [http://www.apple.com/ Apple]'s [http://www.apple.com/macosx/features/bonjour/ Bonjour] (formerly known as Rendezvous) for GNUstep. Bonjour allows you to register a network service, such as a printer or file server, so that it can be found by name or browsed for by service type and domain. Using Tryst, applications can discover what services are available on the network, along with all necessary access information such as name, IP address, and port number for a given service.

[[Category:Frameworks]]

Creating document based applications

2005-11-29T10:26:06Z

Comrade: Small language changes and punctuation update

Note: First version; subject to further revisions and changes.
--[[User:Quineska|ChrisArmstrong]] 07:09, 7 Jul 2005 (CEST)

== Introduction ==

[[OpenStep]] supports document-based applications, simplifing the process of creating applications whose behaviour is familiar to many users. [[GNUstep]] also provides this functionality to the developer. This guide aims to provide an overview of what is required in the creation and design of such an application.

It is assumed you are familiar with GNUstep, and have some understanding as how to create [[Gorm]]'s interface files (often referred to as nibs), as well as some understanding of how they work.

Importantly, such applications have certain components that are required, and should be considered as part of their design. When programming, classes that will be used as part of the [[AppKit]] are:

==== NSDocument ====

This class is central to the OpenStep document based model. These application's declare a new instance of a subclass of NSDocument for each “document” that is opened. You will subclass NSDocument to implement this.

Each instance of your NSDocument subclass may have one or more windows associated with it. These are used as an interface for loading and saving a representation of your document type. Each window will have an “NSWindowController” instance associated with it, where NSDocument maintains a list of these.

==== NSDocumentController ====

This class acts a controller. It maintains a list of documents (instances of your NSDocument subclass) and is responsible for loading and instantiating new documents. It is usually not necessary to implement a subclass of this, but often it may be useful to implement special functionality (especially related to opening and creating documents at an application level).

==== NSWindowController ====

As mentioned above, NSWindowController instances are individually associated with one NSWindow instance, in such a way that a document maintains a list of window controllers that are reponsible for rendering the views associated with a document.

You will most likely not have to subclass NSWindowController. Instead, you associate a nib file (the Gorm output) with the subclass of NSDocument, and NSDocumentController will load this nib file for each document that is created or loaded.

For example, a text based application that is used for the editing of plain text files, may subclass NSDocument with a TextDocument class. Each instance of this class would have an NSWindowController instance associated with it, which in turn manages a window instance that is instantiated from a nib file. The NSDocumentController instance, as managed and instantiated by GNUstep, would be responsible for loading and saving documents in your application. It even prompts the user to save their documents when they try to quit the application.

== File Components ==

In building your application you will need to create a number of special files. From scratch, the following should be a rough guide to getting it working. These include the Makefile, your application's property list and the interface files.

=== The Makefile ===

For this type of application, no special makefile is needed: it just has to be a normal application. Project Builder should be able to spit out the required makefile and Gorm files that are needed for a generic application. I believe it is also capable of providing support for document-based applications. Otherwise use the following as a template:

'''GNUmakefile'''

include $(GNUSTEP_MAKEFILES)/common.make 
APP_NAME = DocumentApp 
DocumentApp_OBJC_FILES = 
MyDocument.m 
main.m 
DocumentApp_RESOURCES = \ 
Resources/Info-gnustep.plist \ 
Resources/DocumentApp.gorm \ 
Resources/MyDocument.gorm 
-include GNUmakefile.preamble 
include $(GNUSTEP_MAKEFILES)/application.make 
-include GNUmakefile.postamble 

For more information as to customising this file, as well as setting up compiler options for third party libraries and includes, see the GNUstep makefile manual.

===The application dictionary===

For those that have edited this file in their project before, it is a dictionary with various values entered. For our purposes, we need an array within the main dictionary, called "NSTypes". This is a array of unnamed dictionaries, with one dictionary for each type.

I have provided an example for this file below. ProjectBuilder creates one as well. Please note that "TextEdit" does exist as an example application from NEXT I think, and again on MacOS X but I have constructed a much simpler version, used only for plain text files.

Taking a look at the single dictionary entry in the NSTypes array, the following key-value pairs are needed:
* '''NSDocumentClass:''' This is (string) the subclass name you use in your code, the "objective-c name" of your document subclass. This is used by NSDocumentController's default implementation to create instances of your document type.
* '''NSName:''' The generic file type (string). This is completely arbitrary, and can be anything you like. For the purpose of conventions, it may be more appropriate not to use the "NS" or "GS" prefix (the latter of which I not sure), and instead use either your own, or no prefix at all.
* '''NSHumanReadableName:''' The human readable name of your document type (string)? TODO: explain where this is used.
* '''NSUnixExtensions:''' An array of strings, each containing a file extension connected to this document type on "unix" platforms. TODO: explain how "unix" is interpreted by GNUstep.
* '''NSDOSExtensions:''' An array of strings, each containing a file extenstion connected to this document type on "DOS" platforms (could be loosely interpreted as any MS platforms GNUstep runs on, i.e. Windows 2000/XP).
* '''NSRole:''' A string, either "Viewer" or "Editor", depending on how your document operates on this file type.
* '''NSIcon:''' A icon name associated with this document type. TODO: Investigate how this works.

'''Info-gnustep.plist'''
{
ApplicationDescription = "A simple text editor for GNUstep.";
ApplicationName = TextEdit;
ApplicationRelease = 0.10;
Authors = ( "Christopher Armstrong" );
Copyright = "Copyright (C) 2005 Christopher Armstrong";
CopyrightDescription = "Released under GPL.";
FullVersionID = 0.10;
NSExecutable = TextEdit;
NSMainNibFile = TextEdit.gorm;
NSPrincipalClass = NSApplication;
NSRole = Application;
NSTypes = (
{
NSDocumentClass = "TextDocument";
NSName = "GSTextDocumentType";
NSHumanReadableName = "Text Document";
NSUnixExtensions = ( "txt", "" );
NSDOSExtensions = ( "txt" );
NSRole = Editor;
}
);
}

For more information on property list files, consult [[Property Lists]].

=== Interface files ===

Two interface files are needed: one for your main application, and another that will be instantiated with each instance of your document subclass. These both should be listed as resources in your makefile, (as shown the GNUmakefile example above). It may be helpful to name the document nib file after your class.

==== Application Interface File ====

The application one should just be a menu (though it could be more if necessary). When constructing it, take the following into account:

* '''Use an "Application" template''': Use a standard Gorm template for an Application.
* '''Delete the NSWindow instance''': In the "Objects" pane, remove the NSWindow instance by going File->Delete (unless you need a main window, which is beyond the scope of this document).
* '''Set NSOwner's class to "NSDocumentController"''': This is the custom class option of NSOwner in the property inspector. This ensures that the openDocument:, newDocument: messages, as sent to NSFirst, get picked up by NSDocumentController. Do not instantiate it (I believe you can't anyway).
* '''[Optional] Subclass NSDocumentController''':If you intend to subclass NSDocumentController, subclass it in the Classes pane. To make sure that this class is instantiated and used, make sure you instantiate it in Gorm or in your main.m file, and then set NSOwner to be of your custom subclass type.
* '''Add a "Document" menu''': Drag a Document menu from the palette onto your main menu. This already has the proper outlet and action linkage for each relevant message to be directed to NSFirst. Generic messages (such as openDocument:, not associated with any document instance) are forwarded to the shared instance of NSDocumentController (see it's reference documentation). When a document is active, more specific messages (such as close: or saveDocument:) are forwarded to the relevant document instance of your NSDocument subclass.
* '''[Optional] Add other menus''': Add any appropriate menus such as "Info" and "Format" which may be relevant to your application.

==== Document Interface File(s) ====

The document interface file is a window containing the view(s) required for the implementation of one instance of your document type. For example, in the case of a TextDocument type, a window instance with a NSTextView drawn on it is used for each document window. This interface file is instantiated every time a person creates a new document (the newDocument: message is sent to NSDocumentController) or opens an existing document (openDocument:).

You will need to:
* '''Subclass NSDocument''' with your document type in Gorm. This is done in a couple of ways, see [[Gorm_Manual#Custom_classes|custom classes]]. It is up to you whether or not you let Gorm generate the class files, but make sure you add the appropriate outlets to your class in the source files (otherwise, I think your your program may segfault).
* '''Set NSOwner:''' Set your subclass as NSOwner's Custom class using the Property Inspector. ''DO NOT INSTANTIATE IT.''

Another thing that you may want to consider is custom outlets. If you place certain views or controls on your window (including the window itself), you may want to refer to them directly in your code, e.g. the NSTextView in our TextEdit example is accessed directly, so that we can save it's contents to a file. To enable this, we add outlets to our class (see [[Gorm_Manual#Custom_classes|custom classes]]). We then connect NSOwner to the appropriate controls/views, and select the outlets in the Connections Property Inspector (see [[Gorm_Manual#Editing_the_interface|editing the interface]]).

== Code ==

Various things need to be done at a code level, to ensure that your NSDocument subclass is properly instantiated. This section aims to tell you what is necessary.

=== NSDocument subclass ===

When creating your subclass, you may have chosen to have Gorm create the class files. If not, you should create two files for your subclass: a header (.h) file and an implementation file (.m). The header file should take the following layout (we're using the TextEdit example again):

#ifndef TEXTDOCUMENT_H
#define TEXTDOCUMENT_H 
#include <AppKit/AppKit.h> 
@class NSDocument; 
/* The document type string, as specified in the property list [[#The_application_dictionary|NSTypes array]] */ 
NSString * GSTextDocumentType = "GSTextDocumentType";
@interface TextDocument : NSDocument
{
@protected
/* Outlets we added in our Gorm nib file */
id * textView;
}
/* Basic methods used for loading and saving document data (respectively). */
- (BOOL) loadDataRepresentation:(NSData*)representation ofType:(NSString*)type;
- (NSData*) dataRepresentationOfType: (NSString*)type; 
/* Information and events handling of GUI related changes */
- (NSString*) windowNibName;
- (void) windowControllerDidLoadNib:(NSWindowController*)windowController; 
@end 

Firstly, take note that we inherit from NSDocument. As a result, we need to override some methods for a basic (but working) implementation.

==== loadDataRepresentation:ofType: and dataRepresentationOfType: ====

The methods, loadDataRepresent:ofType: and dataRepresentationOfType: are used by NSDocumentController to load and save our files. The first method is called when the user trys to open a document (NSDocumentController gets the file name and copies it's data using an open panel). The method is passed the raw data in this file, as well as a string representing its type. It is important to note that this type string is the same one used in your property list. It is used by NSDocumentController to tell you what type it thinks you should open the data with. If this is not possible, or if there is an error trying to parse the data, your method returns FALSE/NO. Otherwise, you should store a local, meaningful representation of the data, which you can insert into your document window a little later (and return TRUE/YES).

For example, in terms of the TextEdit example:
- (BOOL) loadDataRepresentation:(NSData*) representation ofType:(NSString*)type
{
/*Check type information */
if ([representation equalTo:GSTextDocumentType]==NO)
return NO;
/* Clean out our old representation if it still exists */
if (fileContents) RELEASE(fileContents); 
/* Allocate room for the new data, and try to initialise a string with it. */
self->fileContents = [NSString alloc];
fileContents = [fileContents initWithBytes: [representation bytes]
length: [representation length]
encoding: NSASCIIStringEncoding]; 
/* If this can't be done, return NO */
if (!fileContents)
return NO; 
/* Otherwise, set our TextView to the string data. */
[self->textView setString: fileContents];
return YES;
}

If this is not sufficient, or if your program can open the data in a more efficient manner, it may be worth looking into overriding -initWithContentsOfFile:ofType: and -initWithContentsOfURL:ofType:. Again, see the GUI manual for more details.

dataRepresentationOfType: is used to save the data. Your method is expected to return an instance of NSData that contains what should be saved to a file, for the type specified. Again, the ''type'' variable should be checked to ensure that you can write data of that type. Return nil if the file cannot be saved as that type.

For example:

- (NSData*) dataRepresentationOfType:(NSString*)type
{
if ([type equalTo:GSTextDocumentType]==NO)
return nil; 
NSData stringData = [[textView string] dataUsingEncoding:NSASCIIStringEncoding];
return stringData;
}

If a more sophisticated save implementation is needed, consult the documentation for information on the writeTo* methods.

==== windowNibName ====

This method must be overriden to return the a string of the name of your nib file (without the file extension). More complex implementations will use other methods to load the interface files. TODO: information on what methods need to be overriden.

==== windowControllerDidLoadNib: ====

Use this method to add code that should be run as soon as ''windowController'' has been initialised. Your document may have many window controllers; each window controller taking possession of one window.

In the TextEdit example, this method is used to copy the ''fileContents'' variable to the text view. It otherwise initialises the document window.

Also note that you can override windowControllerWillLoadNib: to perform pre-interface loading initialisation.

==== makeWindowControllers ====

This is an optional method to override, which must be used if you have multiple window controllers per document. It is responsible for creating each window controller from it's interface file and then adding it to the document. Use the addWindowController: method.

==== Other considerations ====

* You need a way to notify NSDocument that your document has changed, so that NSDocumentController can enable the menu item to allow saving. This is done by a call to the updateChangeCount: method. For example, the TextDocument class adds itself as a delegate to the textView, for any notification of changes. It then calls updateChangeCount: in the delegate's method.

* You may also wish to add a close: method (not the close method already in NSDocument, see below) to respond to the menu item permitting your document to close. This could perform cleanup operations before a call to [self close] is made e.g.

- (void) close:(id)sender /* Note this is not the method found in NSDocument (they differ by a parameter) */
{
[self close];
}

=== NSDocumentController ===

This class can optionally be subclassed, to implement some specific functionality. For example, programs handling multiple document types may override newDocument: to create a window so that the user can select which document type to create.

You should use separate implementation files and add the .m file to GNUmakefile.

=== NSWindowController ===

This class can also be optionally subclassed, to implement functionality specific to a window controller for a document type. You may need to override makeWindowControllers: in the NSDocument subclass in order to make sure your specific window controller is instantiated.

You should use separate implemenation files and add the .m file to GNUmakefile.

== Optional Additions ==

=== Custom NSDocumentController and NSWindowController implementations ===

See [[#NSWindowController|NSWindowController]] and [[#NSDocumentController|NSDocumentController]].

----

[[Category:Development]]

Talk:Window Maker

2005-11-22T12:15:15Z

Comrade: Agree

I was going to add:

"This said, questions specifically regarding Window Maker should be directed towards the developers of Window Maker (GNUstep and Window Maker collaborate, but they are separate projects). "

so we don't keep getting Window Maker specific questions. What do people think?

<hr />

Agree - don't think this is contentious at all.

-Peter

Talk:Glossary

2005-11-14T19:36:50Z

Comrade:

There may be a call to mention both Instance and Class variables due to the fundamental different roles they play in class-instance style of object oriented programming. Additionally, they're implemented in fairly wildly different ways.
<pre>-Peter</pre>

Class variable

2005-11-14T14:46:15Z

Comrade: Description of class variable analog

The Objective-C dialect which is implemented by the GNU Compiler Collection (gcc) does not explicitly support the concept, widely used in some other object-oriented languages, of class variables.

Class variables are shared values or properties of a specific class. This is useful when encapsulating more complex class and instance behaviour which requires the class to keep track, say of numbers of instances created or other more complex behaviours.

A way of implementing class variables is to declare static variables in the class's [[Implementation]] section, and define class accessor methods if the values need to be changed externally. Note that these statics are not true class variables and will not be inherited by subclasses, and will not be visible outside of the source file's scope.

Compare with the concept of an [[Instance variable]].

Instance variable

2005-11-14T14:25:47Z

Comrade: Clarifying that instance variables do not share values between instances

Each instance of a class may have a local copy of one or more variables which are known as instance variables, and which may contain unique properties or values associated with that instance. These variables are not shared between instances of a class.

Instance variables are declared in the class's [[Interface]] and become part of any objects which are members of, or inherit from, the class.

Instance variables are also referred to as ivars.

Compare with the concept of a [[Class variable]].

Event

2005-11-14T14:11:55Z

Comrade: Actually, keys are stroked. English is very silly, I think. Other changes to clarify and remove "it" where possible.

Events are occurrences that the system recognizes, such as mouse clicks or keystrokes.

When an event is received by an [[application]], the [[Responder|first responder]] in the [[Responder|responder chain]] is given the chance to deal with it. If the first responder doesn't know what to do with it, the event is passed on, up the responder chain. If no responder deals with the event, it is ignored.

Identifying the target platform

2005-11-10T20:23:34Z

Comrade: Add "standard" macros and a tip for Makefiles

A common problem is identifying the target platform at compile-time so that specific code can be used, perhaps to work around a quirk, or to access a non-standard feature of the target platform.

== Standard compiler platform macros ==

The following table is a partial extract of [[http://predef.sourceforge.net/preos.html Pre-defined C/C++ Compiler Macros]], part of a useful resource to compiler macro definitions.

Please update the table carefully with your platform or corrections:

{| border="1" cellpadding="2"
|+Platform macros
|-
! Platform !! Defined macro !! Other notes
|-
! FreeBSD
| __FreeBSD__ || Consider using the BSD macro
|-
! Linux
| linux or __linux ||
|-
! MacOS X
| __MACOSX__ or __APPLE__ ||
|-
! NetBSD
| __NetBSD__ || Consider using the BSD macro
|-
! OpenBSD
| __OpenBSD__ || Consider using the BSD macro
|-
! Solaris
| sun or __sun || SunOS versions < 5 will not have __SVR4 or __svr4__ defined
|-
! Windows
| _WIN32 or __WIN32__ ||
|}

You can use #if wrappers like:

<pre>
#if defined (__FreeBSD__)
...
#elif defined (__linux) || defined (linux)
...
#else
...
#endif
</pre>

== Using GNUStep-Make's support ==

Chris Vetter shared a tip on the use of your GNUmakefile.preamble with the following line:

<pre>
ADDITIONAL_OBJCFLAGS += -D$(GNUSTEP_HOST_OS)
</pre>

and then the #if wrappers will look like:

<pre>
#if defined (freebsd)
...
#elif defined (netbsdelf)
...
#else
...
#endif
</pre>

Snippets

2005-11-10T19:44:52Z

Comrade: Add a snippet to help identify the target platform

This page links to sample code and snippets with tips & tricks.

== Objective-C and OOP Concepts ==

== Foundation Kit ==
* [[NSArray]]

== Application Kit ==
* [[NSDocument]]
* [[NSTableView]]
* [[NSTextField]]
* [[NSView]]

== Makefiles and compiler environment ==
* [[Identifying the target platform]]

Main Page

2005-09-06T21:18:44Z

Comrade: DeSPAM. Sigh.

{| style="border:1px solid black; background-color:lavender; padding:10pt;"
|+
| '''GNUstep''' is a [[Portability|cross-platform]], object-oriented set of [[Frameworks|frameworks]] for desktop application [[Development tools|development]]. The set of frameworks, based on [[OpenStep]] (now [[Cocoa]]), enables developers to rapidly build sophisticated software by employing a large library of reusable software components. GNUstep is already used [[GNUstep in production|in production]] environments at several organizations.
|}

== About GNUstep ==

'''[http://www.gnustep.org GNUstep home page]'''

[[Blogs]] - Blogs concerning GNUstep

[[Project development|Contact and Project development]]

[[Architecture]]

[[FAQ]]

[[Application News ]]

== Users ==
[[GNUstep_Installation_Process|GNUstep Installation Process]]

[[Internationalisation]]

[[GNUstep environments]]

[[Wish list]]

[[Artworks]]

== Developers ==

[[Development Subprojects]] ([[Themability]], [[Portability]], [[Package management]], [[I18n]], ...)

[[Development tools]]

[[Applications]]

[[Frameworks]]

[[Installation process]]

[[Scripting]]

[[Programming topics]] and [[Snippets]]

== [[Glossary]] ==

== About Wiki ==

[http://www.possibility.com/epowiki/Wiki.jsp?page=HowToOrganizeWiki How To Organize Wiki]

[http://meta.wikimedia.org/wiki/MediaWiki_development Wiki Dev Doc]

[http://meta.wikimedia.org/wiki/MediaWiki_User%27s_Guide User'sGuide]

[http://meta.wikimedia.org/wiki/MediaWiki_FAQ FAQ]

[http://wikipedia.sourceforge.net WikiPedia]

Deployment on Windows

2005-07-16T14:02:03Z

Comrade: Language cleanup

==Preparation of your MinGW GNUstep environment==

These directions seem to work but have been tested only on Lloyd Dupont's development machine so far - this has yet to be tested on a test machine without anything installed. (Please update this once someone's tested this!)

First-off, it is recommended you build GNUstep from CVS yourself using [http://www.gnustep.org/resources/documentation/User/GNUstep/README.MinGW the MinGW README] or following the instructions for [[Installation on Windows]].

It's a relatively long but painless process.

Note: the installer "GNUstep-base-1.10.1-gui-0.9.4.exe" contains slightly buggy DLLs - please use a current CVS version!

==Making sure that DLLs are available to your application==

Once GNUstep is built, you'll need to do three things to deploy your application:

1. Make sure that all the dependency DLLs that are installed in the MinGW GNUstep environment are in your application's directory or in the PATH (see [[Installation on Windows]] step 11 and 14: libintl, libiconv, etc)

2. Make sure that all the DLLs in <GNUstep>/System/Tools are in your application's directory or in the PATH

3. The content of <GNUstep>/System directory (with the exception of <GNUstep>/System/Tools) should be pointed to by one of the following environment variables:

GNUSTEP_SYSTEM_ROOT
GNUSTEP_NETWORK_ROOT
GNUSTEP_LOCAL_ROOT

Hint: make all three variables point to the same directory to avoid all suprises. You don't need System/Tools in these as you have already copied the DLLs.

The three variables are intended to support a more complex GNUstep environment than you may need for a single application deployement.

If you don't want to mess with system environment variables or want to have multiple (side by side) installations, you could set these variables at application startup time with:

[NSProcessInfo initializeWithArguments: __argv
count: __ argc
environment: (char**){
"GNUSTEP_SYSTEM_ROOT=C:\AppLocalGSPath",
"GNUSTEP_NETWORK_ROOT=C:\AppLocalGSPath",
"GNUSTEP_LOCAL_ROOT=C:\AppLocalGSPath",
NULL} ];

It is important to call this method early before any other part of the application triggers caching of incorrect GNUstep environment variables.

Warning: simply using putenv might fail if, for some reason, the class NSProcessInfo has already been initialized - it will have cached the environment variables.

Voila! Your GNUstep-based application can now be shipped without the user having to know about or install GNUstep - and you don't have the risk of an untested version of GNUstep being loaded by your application either.

Happy GSCoding ;-)

''based on a mail from Lloyd Dupont''

User:Aa

2005-07-11T14:33:42Z

Comrade: This user is some kind of spammer, can it be blocked?

This user is some kind of spammer, can it be blocked?

DBModeler

2005-07-10T07:49:40Z

Comrade: Create DBModeler application page

== About DBModeler.app ==

DBModeler.app is based loosely on EOModeller.app and is used to create EOModels - definitions of mappings between the tables, columns and rows of a relational database to objects within a GNUstep program that uses GDL2 (GNUstep's EOF implementation).

Existing EOModels may be opened and modified, new ones may be created manually, or even "reverse-engineered" from an existing database if DBModeler is able to connect to an existing database.

The resulting EOModels can be used to allow simple database connectivity in GNUstep applications, tools, or within GNUstep Web applications without significant additional coding effort.

== Current status ==

GDL2 contains DBModeler.app in CVS. It is currently functional for basic EOModel creation, and new features are still being added.

[[Image:DBModeler-snapshot.png|Snapshot of DBModeler.app in operation]]

== Known issues ==

* probably a few ;-)

File:DBModeler-snapshot.png

2005-07-10T07:46:41Z

Comrade: DBModeler.app in operation

DBModeler.app in operation

Application wish list

2005-07-09T23:08:45Z

Comrade: /* DatabaseModeller.app */

What applications do you want for GNUstep? Add below:
(Please check [All GNUstep Applications] before adding)

Old NeXTSTEP/OPENSTEP apps: http://www.levenez.com/NeXTSTEP/meApps.html

__Frontend for different platform to www.granddictionnaire.com__

-------------------------------

== Keyboard switcher application ==

== Web browser ==

Seems to be a popular request :).

* Could [http://www.mozilla.org/projects/camino/ Camino] (formerly known as Chimera) be the one (after backporting)?
* [http://www.apple.com/safari/ Apple's Safari] web browser uses KHTML and KJS software from the KDE open source project, updated and re-released [http://developer.apple.com/darwin/projects/webcore/index.html here], but needs Objective-C++ support in GCC.
-- Hasan --

* I could port [http://ibn.com/~hdiwan/orchidWeb.html OrchidWeb] to GNUStep. I'd just need enough examples on developing the views from code to {do it.
Apparently, camino is written in Objective-C++, which GCC can't compile (although Apple is supposed to have contibuted the patch). Until gcc can compile mixed obj-c and c++, it can't be ported. There is a thread about this at [http://linuxfr.org/2003/03/10/11647.html] (it's in french).
* This seems very close... Stefan has began porting [http://mac.wms-network.de/gnustep/WebCore/blog/ Webcore to GNUstep]. Still some way to go, but a great breaktrough. This seems to be the most probable answer to the web browser request.

== Project Management app ==

Something like [http://mrproject.codefactory.se/screenshots.php MrProject]. It has to be simple, not overbloated as MS Project.

== Google.app ==

* Complete with ApplicationServices
* WebBrowser integration
* Using proper NS* classes for HTML retrieval
* Ability to select which Google server (www.google.ca, www.google.co.jp)
* Google News, Google Groups, Google Images too.

== DMG.app? ==

* Installer/extractor/viewer for DMG images.
* Create DMG packages
* Useful for OSX source packages

''Note:'' The DMG format is Apple proprietary and undocumented. Basically, DMG support is only available under OSX and its unlikely to change.

== Blender ==

Blender has recently (since October 2002) gone GPL. Consisting of porting the Blender GUI/WM abstract library GHOST, using NSOpenGLContext, or a CoreGraphics implementation one day. Objective-C++ might be needed for implementing GHOST, but probably can be worked around easily enough. There is an OSX port, probably using CoreGraphics.

[http://www.blender.org/ Blender Foundation Homepage]

Most of Blender is written in C++ doesn't seem to use CoreGraphics but Apple's GL.

== CSS/html editor ==

A cool html/css editor - emphasis on the css structural side.

Object oriented properties application to CSS element definitions, and insert those properties into HTML in web pages. Don't worry about WYSIWIG - that's what web browsers are for, displaying web pages. Just make a object-oriented CSS/HTML editor.

Maybe port [http://www.w3.org/People/Berners-Lee/WorldWideWeb.html Nexus] for that?

== OmniGraffle clone ==

(I don't really know what this is, but people have said they want one. Someone please add a description! :)

This is for diagram, UML ....
I 'm thinking to write it. But not *right now*.
It will have probably a Gorm-feel

[http://www.omnigroup.com/applications/omnigraffle/ OmniGraffle] was a clone of Lighthouse Design's Diagram.app, which was a re-working of the NeXT Developer Example Sketch.app, adding rubber-banding / angular connection lines.

== OmniOutliner clone ==

This is a really cool app which can be used for anything. Mostly i think it is used to organise your minds while being creative (some kind of knowledge manager).

The inspiration for this was Jayson Adams' Millennium Software's NoteBook.app, which lives again as the (commercial) program [http://www.aquaminds.com/ NoteTaker].

== A text editor ==

A simple text editor that can read and write plain or rich text, including both simple word processing functionality (nothing too splashy, like frames) and optional programming features (like syntax highlighting -- not just coloring; controllable tabs; tab v. space indentation, multiple language support). Programming features could be provided by a bundle, but it would be good to for the app to be designed with that bundle in mind.

This editor which is to guarantee me world domination includes a split view where the other pane locates and displays the corresponding end-tag/start-tag when programming.

Ink is not that editor. :)

[http://www.softpanorama.org/Editors/index.shtml Softpanorama] seems to give a good overview of editors

''We have to distinguish between a text editor as programming tool (CodeEditor.app) and a text editor as a word processor (WordProcessor.app?). '' They are two different approaches to text editing and text processing.

Source code editing view and associated inspector panels and preferences should be provided as a framework, so the SourceView should be reused in other apps. CodeEditor should be only some default wrapper for that framework.

WordProcessor.app sould be an application that extends NSText system. (With easy-to-use paragraph style editing)

How about interfacing with [http://www.scintilla.org Scintilla]?
-- Hasan --

== A simple DTP application ==

A simple frame-based application for desktop publishing. Something like [http://www.calamus.net/ Calamus] ([http://www.calamus.net/man/index_us.htm here] is the documentation of tools and modules). Nothing fancy, just application that can lay out frames, control text flow, use paragraph styles and master pages.

I'd rather see TeXView.app come back myself.... I think it's far more feasible (doing a decent page layout app is _hard_ just as Donald E. Knuth). Perhaps better still would be to take advantage of LyX's ``GUI-independence'' and provide a GNUstep front-end for it, http://www.lyx.org .

No, nothing like LyX or TeX. I have in mind a ''visual'' page layout editing tool with features as described above (similar to PageMaker). LyX and TeX are a bit different approaches and should be alternatives to Frame based DTP application.

- Stefan

I think a heavy-weight drawing package w/ page layout features would be a better solution here (this is the workflow I'm using on my NeXT Cube now), then it could be tied into an XML-based workflow in a fashion like to Apple's new Keynote, perhaps in a fashion like to Pages-by-Pages. To describe my workflow a bit---I now use Altsys Virtuoso on my NeXT Cube w/ Omega (Unicode-aware TeX variant) for most of my page layout. IME, if a document gets too large to manage w/ Altsys Virtuoso, it might as well go into TeX... Not that I'd mind seeing a replacement for PasteUp.app, I just think that a drawing program is more immediately important / useful.

For simple DTP utility, I'd dearly love to see a re-creation of [http://members.aol.com/willadams/gnustep/apps/type/touchtype.html TouchType.app]

- William

Maybe you should take a look at [http://www.texmacs.org/ TeXmacs]. Looks promising and is in great need of a GNUstep frontend.

- david.

Interesting. I'd seen TeXMacs mentioned on comp.text.tex quite often, but hadn't realized it had gotten as far as it had. Interesting counterpoint to LyX.
- William

One really interesting thing would be to have a fame class which would useful enough so it could be used to put together a simple DTP Application but which would be flexible enough that it could be available to any application - the text control is a standard control for windows managers like MS Windows or Gnome. If there were an equivalent "flowing graphic control", you'd have a powerful building block indeed (note that in MS windows, the text control is actually poor enough that no credible application can built around besides notepad).
Also, for a programming text editor, scintilla is great. One thing to consider is that for DTP/HTML editor, what you would want would be a *superset* of the scintilla interface. It would be great to add all the different features in such a way that you didn't have interfaces duplicating each other's functionalities.

-- JosephSolbrig

== Painting app (photoshop) ==

Bitmap drawing app.

Think Photoshop, not Gimp

In fact, forget that. Something new.

Something usable - can do Photoshop, but easy to learn. The Gimp can nearly do photoshop, but who can use it?

It would be great if it consisted of two parts - a very small very useful image viewer/manager (eg gqview) and the actual editor plugin (the big part). So installing image-core would give a very small useful app, then adding image-edit would make it into photoshop.

When opening an image file eg by clicking on it or running image-core thefile.jpg then only the core apps should start, so it starts real quick. If i right-click and choose edit or something .. THEN the other stuff is pulled in.

Or whatever. Just an idea. But makes development path cool. Could also have a vector plugin, or whatever.

Maybe we should wait, when (if?) gimp gets 'gegl'ed (http://gegl.org).
then having a decent photoshop like app would be as simple as writing a gui for the gegl foundation.
+ gives us a nice featureset + plugins!

Maliwan project is aiming to achieve the same goal of GEGL. Right now GEGL isn't even half complete but we can still reimplement it base on GEGL's design. lastlife is waiting for you in irc if you want to discuss the idea. Maliwan is planned to be the heart of the BluTulip which is the actual application.

== Calendar ==

check SKYRIX libs (Opengroupware).
http://www.opengroupware.org/cvsweb/cvsweb.cgi/OpenGroupware.org/SOPE/skyrix-core/NGiCal/

== CVS app ==

Port CVL

== Task management app ==

Chronographer (lobbying by ludovic) + libical
or
~TaskManager (lobbying by Fabien) + libical

Check SKYRIX libs (Opengroupware)

== ICQ ==

and other instant messengers.
check http://freshmeat.net/projects/fireapp/

== DatabaseModeller.app ==

See [[DBModeler]], currently a work in progress.

== Database management ==

A desktop software (Like [http://www.flex.ro/pgaccess/ PgAccess] for example) to manage database. This program could use the GDL2 (Gnustep Database Library). It could be a good exercice and demonstration of this very good library.

== Video conferencing software ==

There's [http://www.gnomemeeting.org/ Gnomemeeting] (excellent piece of software), but I don't like Gnome too much (all those dependencies).

Update: Gnomemeeting 0.9.6 is supposed to work without Gnome libs (limited functionality).

== CronniX - A cron front end ==

http://www.koch-schmidt.de/cronnix/

That won't be easily portable, as different OSs use a different cron setup. Eg. BSD has (and uses) both, /etc/crontab __and__ /var/cron/tabs/<username> ...

== PfaEdit - A font editor ==

(This is now called FontForge)

http://pfaedit.sourceforge.net

Actually, Cenon (see above) is able to do some limited font editing. Not to knock pfaedit, I use it a lot and think it's a way cool program. Wonder if the two could be merged somehow.

== GuileServices / StepTalk Services ==

On NeXTSTEP there was an application (service?) called [TickleServices|http://www.doubleu.com/TickleServices.html] that allowed you to write your own services in the Tcl language. Something along these lines, but using guile/steptalk would be a nice addition to gnustep.

== Printer.app ==

An application/framework for managing printers, printer properties and print queues. (CUPS frontend?)

== DivX/XViD/DVD/VCD Player ==

I see that there was at least an attempt to port mplayer at one point but it seems to be dead. Maybe VLC (http://www.videolan.org/) which does have an OSX version, could be ported.

== Abiword (Word Processor) ==

A port of the Cocoa version of [AbiWord|http://www.abisource.com] would be great, considering a word processor is a pretty vital application, and that Abiword is a pretty good one.

== Spreadsheet ==

A spreadsheet application would be great for GNUstep. A clone of Lotus Improv or Lighthouse Design's Parasheet would be a nice thing for GNUstep to have.

== Pixen (Pixel Art Tool) ==

[Pixen|http://www.opensword.org] is a decent, open source pixel art tool and there aren't alot of free or professional programs like it. There is also a compliment tool by the same guys for mapping called Reptile.

We're working on a GNUstep port now, in fact.

== Growl! (Global notification system) ==

[http://growl.info/ Growl!] uses distributed notification center to display a graphic message on screen. Every application can send messages to it, for example, when new emails arrive, buddies sign in the instant messager, a task end, etc. It is very easy to implement.

== Digital Librarian-like ==

I would really, really like a Digital Librarian for GNUstep. Basically, imagine an application that manage your documents the same way iTunes manage your music or iPhoto your photos... (to take well-known OSX apps as example ;-)

It would provide 1) automatic management of the documents by projects/ideas/whatever metadata 2) index your documents to let you search quickly in it 3) handles bibliography
As a postgrad student I have a LOT of articles in PDF/PS/DVI/html on my hard drive, and such an application would be really nice to help managing that.

A Digital Librarian screenshot: http://www.levenez.com/NeXTSTEP/Librarian.jpg
A screenshot of Vertex Librarian, a similar program for NeXTSTEP: http://www.levenez.com/NeXTSTEP/VertexLibrarian.jpg

== nib2gmodel/nib2gorm without OPENSTEP/MacOSX ==

I want;but I heard it is so hard to implementation. :-(

== iTunes/Rhythmbox clone ==

It would be nice to see a music or video player with real music/media management like [http://www.gnome.org/projects/rhythmbox/ Rhythmbox] or [http://www.apple.com/itunes/ iTunes]. iTunes has started to support management of movies and videoclips, so maybe media management is the way to go?

Application wish list

2005-07-09T23:07:51Z

Comrade: Updated to reference DBModeler.app

What applications do you want for GNUstep? Add below:
(Please check [All GNUstep Applications] before adding)

Old NeXTSTEP/OPENSTEP apps: http://www.levenez.com/NeXTSTEP/meApps.html

__Frontend for different platform to www.granddictionnaire.com__

-------------------------------

== Keyboard switcher application ==

== Web browser ==

Seems to be a popular request :).

* Could [http://www.mozilla.org/projects/camino/ Camino] (formerly known as Chimera) be the one (after backporting)?
* [http://www.apple.com/safari/ Apple's Safari] web browser uses KHTML and KJS software from the KDE open source project, updated and re-released [http://developer.apple.com/darwin/projects/webcore/index.html here], but needs Objective-C++ support in GCC.
-- Hasan --

* I could port [http://ibn.com/~hdiwan/orchidWeb.html OrchidWeb] to GNUStep. I'd just need enough examples on developing the views from code to {do it.
Apparently, camino is written in Objective-C++, which GCC can't compile (although Apple is supposed to have contibuted the patch). Until gcc can compile mixed obj-c and c++, it can't be ported. There is a thread about this at [http://linuxfr.org/2003/03/10/11647.html] (it's in french).
* This seems very close... Stefan has began porting [http://mac.wms-network.de/gnustep/WebCore/blog/ Webcore to GNUstep]. Still some way to go, but a great breaktrough. This seems to be the most probable answer to the web browser request.

== Project Management app ==

Something like [http://mrproject.codefactory.se/screenshots.php MrProject]. It has to be simple, not overbloated as MS Project.

== Google.app ==

* Complete with ApplicationServices
* WebBrowser integration
* Using proper NS* classes for HTML retrieval
* Ability to select which Google server (www.google.ca, www.google.co.jp)
* Google News, Google Groups, Google Images too.

== DMG.app? ==

* Installer/extractor/viewer for DMG images.
* Create DMG packages
* Useful for OSX source packages

''Note:'' The DMG format is Apple proprietary and undocumented. Basically, DMG support is only available under OSX and its unlikely to change.

== Blender ==

Blender has recently (since October 2002) gone GPL. Consisting of porting the Blender GUI/WM abstract library GHOST, using NSOpenGLContext, or a CoreGraphics implementation one day. Objective-C++ might be needed for implementing GHOST, but probably can be worked around easily enough. There is an OSX port, probably using CoreGraphics.

[http://www.blender.org/ Blender Foundation Homepage]

Most of Blender is written in C++ doesn't seem to use CoreGraphics but Apple's GL.

== CSS/html editor ==

A cool html/css editor - emphasis on the css structural side.

Object oriented properties application to CSS element definitions, and insert those properties into HTML in web pages. Don't worry about WYSIWIG - that's what web browsers are for, displaying web pages. Just make a object-oriented CSS/HTML editor.

Maybe port [http://www.w3.org/People/Berners-Lee/WorldWideWeb.html Nexus] for that?

== OmniGraffle clone ==

(I don't really know what this is, but people have said they want one. Someone please add a description! :)

This is for diagram, UML ....
I 'm thinking to write it. But not *right now*.
It will have probably a Gorm-feel

[http://www.omnigroup.com/applications/omnigraffle/ OmniGraffle] was a clone of Lighthouse Design's Diagram.app, which was a re-working of the NeXT Developer Example Sketch.app, adding rubber-banding / angular connection lines.

== OmniOutliner clone ==

This is a really cool app which can be used for anything. Mostly i think it is used to organise your minds while being creative (some kind of knowledge manager).

The inspiration for this was Jayson Adams' Millennium Software's NoteBook.app, which lives again as the (commercial) program [http://www.aquaminds.com/ NoteTaker].

== A text editor ==

A simple text editor that can read and write plain or rich text, including both simple word processing functionality (nothing too splashy, like frames) and optional programming features (like syntax highlighting -- not just coloring; controllable tabs; tab v. space indentation, multiple language support). Programming features could be provided by a bundle, but it would be good to for the app to be designed with that bundle in mind.

This editor which is to guarantee me world domination includes a split view where the other pane locates and displays the corresponding end-tag/start-tag when programming.

Ink is not that editor. :)

[http://www.softpanorama.org/Editors/index.shtml Softpanorama] seems to give a good overview of editors

''We have to distinguish between a text editor as programming tool (CodeEditor.app) and a text editor as a word processor (WordProcessor.app?). '' They are two different approaches to text editing and text processing.

Source code editing view and associated inspector panels and preferences should be provided as a framework, so the SourceView should be reused in other apps. CodeEditor should be only some default wrapper for that framework.

WordProcessor.app sould be an application that extends NSText system. (With easy-to-use paragraph style editing)

How about interfacing with [http://www.scintilla.org Scintilla]?
-- Hasan --

== A simple DTP application ==

A simple frame-based application for desktop publishing. Something like [http://www.calamus.net/ Calamus] ([http://www.calamus.net/man/index_us.htm here] is the documentation of tools and modules). Nothing fancy, just application that can lay out frames, control text flow, use paragraph styles and master pages.

I'd rather see TeXView.app come back myself.... I think it's far more feasible (doing a decent page layout app is _hard_ just as Donald E. Knuth). Perhaps better still would be to take advantage of LyX's ``GUI-independence'' and provide a GNUstep front-end for it, http://www.lyx.org .

No, nothing like LyX or TeX. I have in mind a ''visual'' page layout editing tool with features as described above (similar to PageMaker). LyX and TeX are a bit different approaches and should be alternatives to Frame based DTP application.

- Stefan

I think a heavy-weight drawing package w/ page layout features would be a better solution here (this is the workflow I'm using on my NeXT Cube now), then it could be tied into an XML-based workflow in a fashion like to Apple's new Keynote, perhaps in a fashion like to Pages-by-Pages. To describe my workflow a bit---I now use Altsys Virtuoso on my NeXT Cube w/ Omega (Unicode-aware TeX variant) for most of my page layout. IME, if a document gets too large to manage w/ Altsys Virtuoso, it might as well go into TeX... Not that I'd mind seeing a replacement for PasteUp.app, I just think that a drawing program is more immediately important / useful.

For simple DTP utility, I'd dearly love to see a re-creation of [http://members.aol.com/willadams/gnustep/apps/type/touchtype.html TouchType.app]

- William

Maybe you should take a look at [http://www.texmacs.org/ TeXmacs]. Looks promising and is in great need of a GNUstep frontend.

- david.

Interesting. I'd seen TeXMacs mentioned on comp.text.tex quite often, but hadn't realized it had gotten as far as it had. Interesting counterpoint to LyX.
- William

One really interesting thing would be to have a fame class which would useful enough so it could be used to put together a simple DTP Application but which would be flexible enough that it could be available to any application - the text control is a standard control for windows managers like MS Windows or Gnome. If there were an equivalent "flowing graphic control", you'd have a powerful building block indeed (note that in MS windows, the text control is actually poor enough that no credible application can built around besides notepad).
Also, for a programming text editor, scintilla is great. One thing to consider is that for DTP/HTML editor, what you would want would be a *superset* of the scintilla interface. It would be great to add all the different features in such a way that you didn't have interfaces duplicating each other's functionalities.

-- JosephSolbrig

== Painting app (photoshop) ==

Bitmap drawing app.

Think Photoshop, not Gimp

In fact, forget that. Something new.

Something usable - can do Photoshop, but easy to learn. The Gimp can nearly do photoshop, but who can use it?

It would be great if it consisted of two parts - a very small very useful image viewer/manager (eg gqview) and the actual editor plugin (the big part). So installing image-core would give a very small useful app, then adding image-edit would make it into photoshop.

When opening an image file eg by clicking on it or running image-core thefile.jpg then only the core apps should start, so it starts real quick. If i right-click and choose edit or something .. THEN the other stuff is pulled in.

Or whatever. Just an idea. But makes development path cool. Could also have a vector plugin, or whatever.

Maybe we should wait, when (if?) gimp gets 'gegl'ed (http://gegl.org).
then having a decent photoshop like app would be as simple as writing a gui for the gegl foundation.
+ gives us a nice featureset + plugins!

Maliwan project is aiming to achieve the same goal of GEGL. Right now GEGL isn't even half complete but we can still reimplement it base on GEGL's design. lastlife is waiting for you in irc if you want to discuss the idea. Maliwan is planned to be the heart of the BluTulip which is the actual application.

== Calendar ==

check SKYRIX libs (Opengroupware).
http://www.opengroupware.org/cvsweb/cvsweb.cgi/OpenGroupware.org/SOPE/skyrix-core/NGiCal/

== CVS app ==

Port CVL

== Task management app ==

Chronographer (lobbying by ludovic) + libical
or
~TaskManager (lobbying by Fabien) + libical

Check SKYRIX libs (Opengroupware)

== ICQ ==

and other instant messengers.
check http://freshmeat.net/projects/fireapp/

== DatabaseModeller.app ==

See [DBModeler], currently a work in progress.

== Database management ==

A desktop software (Like [http://www.flex.ro/pgaccess/ PgAccess] for example) to manage database. This program could use the GDL2 (Gnustep Database Library). It could be a good exercice and demonstration of this very good library.

== Video conferencing software ==

There's [http://www.gnomemeeting.org/ Gnomemeeting] (excellent piece of software), but I don't like Gnome too much (all those dependencies).

Update: Gnomemeeting 0.9.6 is supposed to work without Gnome libs (limited functionality).

== CronniX - A cron front end ==

http://www.koch-schmidt.de/cronnix/

That won't be easily portable, as different OSs use a different cron setup. Eg. BSD has (and uses) both, /etc/crontab __and__ /var/cron/tabs/<username> ...

== PfaEdit - A font editor ==

(This is now called FontForge)

http://pfaedit.sourceforge.net

Actually, Cenon (see above) is able to do some limited font editing. Not to knock pfaedit, I use it a lot and think it's a way cool program. Wonder if the two could be merged somehow.

== GuileServices / StepTalk Services ==

On NeXTSTEP there was an application (service?) called [TickleServices|http://www.doubleu.com/TickleServices.html] that allowed you to write your own services in the Tcl language. Something along these lines, but using guile/steptalk would be a nice addition to gnustep.

== Printer.app ==

An application/framework for managing printers, printer properties and print queues. (CUPS frontend?)

== DivX/XViD/DVD/VCD Player ==

I see that there was at least an attempt to port mplayer at one point but it seems to be dead. Maybe VLC (http://www.videolan.org/) which does have an OSX version, could be ported.

== Abiword (Word Processor) ==

A port of the Cocoa version of [AbiWord|http://www.abisource.com] would be great, considering a word processor is a pretty vital application, and that Abiword is a pretty good one.

== Spreadsheet ==

A spreadsheet application would be great for GNUstep. A clone of Lotus Improv or Lighthouse Design's Parasheet would be a nice thing for GNUstep to have.

== Pixen (Pixel Art Tool) ==

[Pixen|http://www.opensword.org] is a decent, open source pixel art tool and there aren't alot of free or professional programs like it. There is also a compliment tool by the same guys for mapping called Reptile.

We're working on a GNUstep port now, in fact.

== Growl! (Global notification system) ==

[http://growl.info/ Growl!] uses distributed notification center to display a graphic message on screen. Every application can send messages to it, for example, when new emails arrive, buddies sign in the instant messager, a task end, etc. It is very easy to implement.

== Digital Librarian-like ==

I would really, really like a Digital Librarian for GNUstep. Basically, imagine an application that manage your documents the same way iTunes manage your music or iPhoto your photos... (to take well-known OSX apps as example ;-)

It would provide 1) automatic management of the documents by projects/ideas/whatever metadata 2) index your documents to let you search quickly in it 3) handles bibliography
As a postgrad student I have a LOT of articles in PDF/PS/DVI/html on my hard drive, and such an application would be really nice to help managing that.

A Digital Librarian screenshot: http://www.levenez.com/NeXTSTEP/Librarian.jpg
A screenshot of Vertex Librarian, a similar program for NeXTSTEP: http://www.levenez.com/NeXTSTEP/VertexLibrarian.jpg

== nib2gmodel/nib2gorm without OPENSTEP/MacOSX ==

I want;but I heard it is so hard to implementation. :-(

== iTunes/Rhythmbox clone ==

It would be nice to see a music or video player with real music/media management like [http://www.gnome.org/projects/rhythmbox/ Rhythmbox] or [http://www.apple.com/itunes/ iTunes]. iTunes has started to support management of movies and videoclips, so maybe media management is the way to go?

Property Lists

2005-07-07T10:04:44Z

Comrade: Sentence flow cleanups

NOTE: this document is still a work in progress. No responsibility is accepted for any problems arising from inaccuracies.

== Introduction ==

Property lists are used throughout GNUstep to store defaults, program settings, application meta information, and so on. MacOS X has begun to use XML based property lists, but GNUstep uses the classic property list format.(TODO: history of this style of property list). Support in GNUstep for XML property lists is still limited on some platforms; this situation should improve in the future as libxml platform build issues are resolved within GNUstep.

A property list is a logical tree of arrays, dictionaries, strings and numbers. The arrays and dictionaries may contain other arrays and dictionaries as data elements, and structures may become quite rich and expressive when representing complex data relationships. TODO: limits of embedding array/dictionaries inside each other.

== Dictionary ==

A dictionary is a list of key-value pairs, where each item in the list has a name associated with it (key) and another type (value), which could be another dictionary, an array or often a string. It programmatically corresponds to NSDictionary/NSMutableDictionary. They take the following syntax:

{
KeyName1 = Value1;
AnotherKeyName = "Value2";
Something = ( "ArrayItem1", "ArrayItem2", "ArrayItem3" );
Key4 = 0.10;
KeyFive = { Dictionary2Key1 = "Something"; AnotherKey = "Somethingelse"; };
}

As can be seen, each key-value pair is seperated by a semi-colon. Within the pair, the key is seperated from the value with an "equals" (=) sign. The key name is arbitrary, and not put in inverted commas (""). Shown above are: an unknown type (could be some sort of string - TODO), a string, an array, a number and another dictionary (respectively).

== Array ==

An array is a list of values, each of the same type (often arrays or dictionaries). Programmatically, it uses NSArray/NSMutableArray. It takes a syntax similar to the following:

( Value1, Value2, Value3, Value4 ) 
or 
(
Value1,
Value2,
Value3,
Value4
)

Each value is seperated by commas. By the technical definition of an array, each value is of the same type (but I believe GNUstep permits different types TODO: check this).

== Programming ==

GNUstep permits such property list files (normally having a .plist extension) to be loaded and subsequently used in your applications or tools. FoundationKit - in our case gnustep-base - classes NSDictionary and NSArray are used as representations of the property list data structures. Check the base API documentation for more information on working with these types programmatically.

NSString can be used to turn property lists in string form - either read from a file or constructed programmatically - to an equivalent data structure in memory. Again, see the API documentation for NSString (particularly the propertyList method).

== Other tips ==

* Property lists are much like C programming, where newlines and spaces and tabs are not so important to parsing.
* Some examples of property lists may include:
** ~/GNUstep/System/Defaults/.GNUstepDefaults (this is your defaults file for software; be careful when editing)

[[Category:Development]]

Property Lists

2005-07-07T09:55:57Z

Comrade: Spelling and sentence flow update

NOTE: this document is still a work in progress. No responsibility is accepted for any problems arising from inaccuracies.

== Introduction ==

Property lists are used throughout GNUstep to store defaults, program settings, application meta information, etc. MacOS X uses XML based property lists, but GNUstep uses another property list implementation also (TODO: history of this style of property list). Support for XML property lists is still wanting on some platforms; this situation should improve in the future.

They are composed of a "tree of arrays and dictionary's, which may be embedded inside each other for several layers. TODO: limits of embedding array/dictionaries inside each other.

== Dictionary ==

A dictionary is a list of key-value pairs, where each item in the list has a name associated with it (key) and another type (value), which could be another dictionary, an array or often a string. It programmatically corresponds to NSDictionary/NSMutableDictionary. They take the following syntax:

{
KeyName1 = Value1;
AnotherKeyName = "Value2";
Something = ( "ArrayItem1", "ArrayItem2", "ArrayItem3" );
Key4 = 0.10;
KeyFive = { Dictionary2Key1 = "Something"; AnotherKey = "Somethingelse"; };
}

As can be seen, each key-value pair is seperated by a semi-colon. Within the pair, the key is seperated from the value with an "equals" (=) sign. The key name is arbitrary, and not put in inverted commas (""). Shown above are: an unknown type (could be some sort of string - TODO), a string, an array, a number and another dictionary (respectively).

== Array ==

An array is a list of values, each of the same type (often arrays or dictionaries). Programmatically, it uses NSArray/NSMutableArray. It takes a syntax similar to the following:

( Value1, Value2, Value3, Value4 ) 
or 
(
Value1,
Value2,
Value3,
Value4
)

Each value is seperated by commas. By the technical definition of an array, each value is of the same type (but I believe GNUstep permits different types TODO: check this).

== Programming ==

GNUstep permits such property list files (normally having a .plist extension) to be loaded and subsequently used in your applications or tools. FoundationKit - in our case gnustep-base - classes NSDictionary and NSArray are used as representations of the property list data structures. Check the base API documentation for more information on working with these types programmatically.

NSString can be used to turn property lists in string form - either read from a file or constructed programmatically - to an equivalent data structure in memory. Again, see the API documentation for NSString (particularly the propertyList method).

== Other tips ==

* Property lists are much like C programming, where newlines and spaces and tabs are not so important to parsing.
* Some examples of property lists may include:
** ~/GNUstep/System/Defaults/.GNUstepDefaults (this is your defaults file for software; be careful when editing)

[[Category:Development]]

Development tools

2005-07-06T12:27:13Z

Comrade: Added unit testing frameworks

More abou development tools: http://www.gnustep.org/experience/DeveloperTools.html

== Gorm - Graphical Object Relationship Modeller ==

Gorm stands for "Graphical Object Relationship Modeller" and is GNUstep's easy-to-use interface designer.

With Gorm designing tough and complex graphical interfaces for your applications can be done easily and quickl, using drag & drop, powerful inspectors and teamwork with ProjectCenter.

Gorm allows developers to quickly create and edit graphical application interfaces using a whole lot of GUI elements: windows, menus, buttons, labels, sliders, tables, textfields, browsers, images, altert panels and more. Custom palettes can be dynamically loaded to add additional elements or functionality.

After creating the interface, objects can be linked using mouse operations. Also Gorm features interactive testing of interfaces.

Please see the following wiki sections to learn tips on how to effectively utilize Gorm:

* [[Gorm Manual]]
* [[Gorm FAQ]]
* [[Gorm Installation On Windows]]

Also see the following external links:

* ''' [http://www.gnustep.org/experience/Gorm.html Official Gorm page] '''

* '''[http://packages.debian.org/cgi-bin/search_packages.pl?keywords=gorm&searchon=names&version=all&exact=1&release=all Debian Offical Release]'''

* '''[http://www.freshports.org/devel/gorm FreeBSD Ports]'''

== Project Center ==
''' [http://www.gnustep.org/experience/ProjectCenter.html Project Center] '''

ProjectCenter is GNUstep's integrated developement environment (IDE). It is based in part on NeXT's original Project Builder. It assists you in starting new projects and lets you manage your project files using a intuitive and well ordered graphical user interface.

== Other tools ==

=== Unit Testing ===

GNUstep is blessed with a number of unit test frameworks:

* Traditionally, it has provided a [http://www.gnustep.org/resources/documentation/testdoc_toc.html testing environment] based around Guile, an implementation of Scheme that has been blessed as the preferred GNU scripting language. It has been hard to convince Objective-C programmers to write tests in this language, and the utility of the package has not lived up to expectations.

* GNUstep now also contains a unit testing framework intended as general framework for testing the core GNUstep libraries, called [http://lists.gnu.org/archive/html/gnustep-dev/2005-06/msg00050.html Testsuite]. This may not be suitable for more general unit testing of applications as it's been designed to operate with little of the GNUstep environment actually running. ''Tip: use this if you're describing or fixing bugs or features in base, gui etc.''

* [https://gna.org/projects/etoile Étoilé] contains a port to GNUstep of [http://unitkit.org/ UnitKit 1.1]. This is a straight-forward unit testing environment, suited to the needs of application developers. It also works under X-code on MacOS X.

* [http://www.sente.ch/ Sen:te] have provided a unit testing environment called [http://www.sente.ch/software/ocunit/ OCUnit] which apparently works under GNUstep, although there are comments in the mailing lists about difficulty getting it working.

----

See also:
* [http://ide.roard.com/wakka.php?wiki=Main GNUstep IDE (idea)]
* [[Frameworks#Development|Official Development Frameworks]]
* [[Frameworks#Development_2|Development Frameworks]]

Creating document based applications

2005-07-06T09:58:45Z

Comrade: Add property lists to the developer category

Note: this is a work in progress. Please bear with me as I add further information.
--[[User:Quineska|ChrisArmstrong]] 08:33, 5 Jul 2005 (CEST)

== Introduction ==

OpenStep can provide your application a document-based model. It helps to simplify the process of creating such applications. GNUstep is compatible with this paridgm as well; this document aims to provide an overview of what is required in the creation and design of such an application.

It is assumed you are familiar with GNUstep, and have some understanding as how to create Gorm's nib files, as well as some understanding of how they work.

Importantly, such applications have certain components that are required, and should be considered as part of their design. At a programmatic level, classes that will be used as part of the AppKit are:

==== NSDocument ====

This class is central to the OpenStep document based model. Such an application declares a new instance of a subclass of NSDocument for each “document” that is opened. It will be necessary to subclass NSDocument to implement this.

Each instance of your NSDocument subclass may have one or more windows associated with it. These are used as an interface for loading and saving a representation of your document type. Each window will have an “NSWindowController” instance associated with it, where NSDocument maintains a list of these.

==== NSDocumentController ====

This class acts a controller. It maintains a list of documents (instances of your NSDocument subclass) and is responsible for loading and instantiating new documents. It is usually not necessary to implement a subclass of this, but often it may be useful to implement special functionality (especially related to open documents as a whole).

==== NSWindowController ====

As mentioned above, NSWindowController instances are individually associated with one NSWindow instance, in such a way that a document maintains a list of window controllers that are reponsible for rendering the views associated with a document.

You will most likely not have to subclass NSWindowController. Instead, you associate a nib file (the Gorm output) with the subclass of NSDocument, and NSDocumentController will load this nib file for each document that is created or loaded.

For example, a text based application that is used for the editing of plain text files, may subclass NSDocument with a TextDocument class. Each instance of this class would have an NSWindowController instance associated with it, which in turn manages a window instance that is instantiated from a nib file. The NSDocumentController instance, as managed and instatiated by GNUstep, would be responsible for loading and saving documents in your application. It even prompts the user to save their documents when they try to quit the application.

== Components ==

In building your application you will need to create a number of components. From scratch, the following should be a rough guide to getting it working.

=== The Makefile ===

For this type of application, no special makefile is needed: it just has to be a normal application. Project Builder should be able to spit out the required makefile and Gorm files that are needed for a generic application. Otherwise use the following as a template:

'''GNUmakefile'''

include $(GNUSTEP_MAKEFILES)/common.make 
APP_NAME = DocumentApp 
DocumentApp_OBJC_FILES = 
MyDocument.m 
main.m 
DocumentApp_RESOURCES = \ 
Resources/Info-gnustep.plist \ 
Resources/DocumentApp.gorm \ 
Resources/MyDocument.gorm 
-include GNUmakefile.preamble 
include $(GNUSTEP_MAKEFILES)/application.make 
-include GNUmakefile.postamble 

For more information as to customising this file, as well as setting up compiler options for third party libraries and includes, see the GNUstep makefile manual.

=== The application dictionary - Info-gnustep.plist ===

For those that have edited this file in their project before, it is a dictionary with various values entered. For our purposes, we need an array within the main dictionary, called "NSTypes". This is a array of unnamed dictionaries, with one dictionary for each type.

An entire example of this file, for a "theoretical" TextEdit application (please note that such an application does exist as an example application from Next I think, and again on MacOS X but I have constructed a much simpler version, used only for plain text files).

Taking a look at the single dictionary entry in the NSTypes array, the following key-value pairs are needed:
* '''NSDocumentClass:''' This is (string) the subclass name you use in your code, the "objective-c name" of your document subclass. This is used by NSDocumentController's default implementation to create instances of your document type.
* '''NSName:''' The generic file type (string). This is completely arbitrary, and can be anything you like. For the purpose of conventions, it may be more appropriate not to use the "NS" or "GS" prefix (the latter of which I not sure), and instead use either your own, or no prefix at all.
* '''NSHumanReadableName:''' The human readable name of your document type (string)? TODO: explain where this is used.
* '''NSUnixExtensions:''' An array of strings, each containing a file extension connected to this document type on "unix" platforms. TODO: explain how "unix" is interpreted by GNUstep.
* '''NSDOSExtensions:''' An array of strings, each containing a file extenstion connected to this document type on "DOS" platforms (could be loosely interpreted as any MS platforms GNUstep runs on, i.e. Windows 2000/XP).
* '''NSRole:''' A string, either "Viewer" or "Editor", depending on how your document operates on this file type.
* '''NSIcon:''' A icon name associated with this document type. TODO: Investigate how this works.

'''Info-gnustep.plist'''
{
ApplicationDescription = "A simple text editor for GNUstep.";
ApplicationName = TextEdit;
ApplicationRelease = 0.10;
Authors = ( "Christopher Armstrong <quineska@gamebox.net" );
Copyright = "Copyright (C) 2005 Christopher Armstrong";
CopyrightDescription = "Released under GPL.";
FullVersionID = 0.10;
NSExecutable = TextEdit;
NSMainNibFile = TextEdit.gorm;
NSPrincipalClass = NSApplication;
NSRole = Application;
NSTypes = (
{
NSDocumentClass = "TextDocument";
NSName = "GSTextDocumentType";
NSHumanReadableName = "Text Document";
NSUnixExtensions = ( "txt", "" );
NSDOSExtensions = ( "txt" );
NSRole = Editor;
}
);
}

For more information on property list files, consult [[Property Lists]].

=== Interface file ===

Two interface files are needed: one for your main application, and another that will be instantiated with each instance of your document subclass. These both should be listed as resources in your makefile, (as shown the GNUmakefile example above). It may be helpful to name the document nib file after your class.

==== Application Interface File ====

The application one should just be a menu (though it could be more if necessary). When constructing it, take the following into account:

* Use a standard Gorm template for an application.
* Delete the window instance in the "Objects" pane (unless you need a main window, in which case I don't know how to operate).
* Set NSOwner's class to "NSDocumentController" (this is the custom class option of NSOwner in the property inspector). This ensures openDocument, newDocument, etc. messages, as sent to NSFirst, get picked up by NSDocumentController. Do not instantiate it (I believe you can't anyway).
* If you intend to subclass NSDocumentController, subclass it in the Classes pane. To make sure that this class is instantiated and used, make sure you instantiate it in Gorm or in your main.m file, and set NSOwner to be your subclass.
* Drag a Document menu from the palette onto your main menu. This already has the proper linkage for each relevant message for a document setup to be directed to NSFirst. In the case of generic messages (such as openDocument:, not associated with any document instance), these are forwarded to the shared instance of NSDocumentController (see it's reference documentation). When a document is active, more specific messages (such as close: or saveDocument:) are forwarded to the relevant document instance of your NSDocument subclass.
* Add any appropriate menus such as "Info" and "Format" which may be relevant to your application.

==== Document Interface File ====

[[Category:Development]]

Document based applications

2005-07-06T09:58:18Z

Comrade: Added to category Development

Document based applications use NSDocument and NSDocumentController in their implementation.

[[NSDocument]]

[[Creating document based applications]]

[[Category:Development]]

Property Lists

2005-07-06T09:57:29Z

Comrade: Added to category Development

NOTE: '''If anything below is dead wrong, please fix immediately. It is a work in progress. I am constructing this based on my experience with GNUstep, NOT any reference documentation that may exist. I don't warrant it fit for any purpose whatsoever, nor shall I take any responsibility for any issues or losses or problems etc that may arise from its use. (Christopher Armstrong, --[[User:Quineska|ChrisArmstrong]] 08:38, 6 Jul 2005 (CEST))'''

== Introduction ==

Property lists are used throughout GNUstep to store defaults, program settings, application meta information, etc. MacOS X uses XML based property lists, but GNUstep uses another property list implementation also (TODO: history of this style of property list).

They are composed of a "tree of arrays and dictionary's, which may be embedded inside each other for several layers. TODO: limits of embedding array/dictionaries inside each other.

== Dictionary ==

A dictionary is a list of key-value pairs, where each item in the list has a name associated with it (key) and another type (value), which could be another dictionary, an array or often a string. It programmatically corresponds to NSDictionary/NSMutableDictionary. They take the following syntax:

{
KeyName1 = Value1;
AnotherKeyName = "Value2";
Something = ( "ArrayItem1", "ArrayItem2", "ArrayItem3" );
Key4 = 0.10;
KeyFive = { Dictionary2Key1 = "Something"; AnotherKey = "Somethingelse"; };
}

As can be seen, each key-value pair is seperated by a semi-colon. Within the pair, the key is seperated from the value with an "equals" (=) sign. The key name is arbitrary, and not put in inverted commas (""). Shown above are a (unknown type, could be some sort of string - TODO), a string, an array, a number and another dictionary (respectively).

== Array ==

An array is a list of values, each of the same type (often arrays or dictionaries). Programmatically, it uses NSArray/NSMutableArray. It takes a syntax similar to the following:

( Value1, Value2, Value3, Value4 )

Each value is seperated by commas. By the technical definition of an array, each value is of the same type (but I believe GNUstep permits different types).

== Programming ==

GNUstep permits such property list files (denoted with a .plist extenstion) to be loaded and subsequently used in your applications or tools. NSDictionary and NSArray are used as representations of the above in the Foundation library (gnustep-base).

[[Category:Development]]

Category:Development

2005-07-06T09:56:50Z

Comrade: Reverted - I don't understand categories ;-)

Category:Development

2005-07-06T09:54:43Z

Comrade: Add property lists to the developer category

[[Property Lists]]

Developer Guides

2005-07-06T08:51:24Z

Comrade: Reordered into alpha order, added the Property lists topic

== Coding for portability ==

Writing code that will compile and then run on different platforms can be surprisingly easy. [[Writing portable code]] describes some straight-forward steps to take to make your program easy to port to new platforms.

== Document based application design ==

One of the most common use-patterns of applications on modern platforms is that of document-based applications - applications which can have several active user-controlled contexts.

Some familar examples might be a word processor where the user may have multiple document windows concurrently, or a web browser which allows a user to have a number of different browser windows open at the same time.

[[Document based applications]] provides information and tips on how to code this style of application.

== Using property lists ==

A regular issue that programmers face is storing structured configuration information, and reading it back. GNUstep has a standard mechanism that can be used for this task, amongst others: [[Property lists]].

Developer Guides

2005-07-05T21:26:55Z

Comrade: Added portability section and provided more context

== Document based application design ==

One of the most common use-patterns of applications on modern platforms is that of document-based applications - applications which can have several active user-controlled contexts.

Some familar examples might be a word processor where the user may have multiple document windows concurrently, or a web browser which allows a user to have a number of different browser windows open at the same time.

[[Document based applications]] provides information and tips on how to code this style of application.

== Coding for portability ==

Writing code that will compile and then run on different platforms can be surprisingly easy. [[Writing portable code]] describes some straight-forward steps to take to make your program easy to port to new platforms.

Talk:Document based applications

2005-07-05T21:07:19Z

Comrade: Ideas for page enhancement

For these kinds of programming topics, I'd suggest more explanation about how the application looks like, and perhaps some real-world code, more than just snippets (snippets are good for small things, but not big ideas like this where there are some gotchas). -Comrade